MKL Tweak auf Ryzen Systemen verbessert die Leistung drastisch

MatLab gibt zwar - und das vertehe ich nicht ganz - mittels feature('numCores')

32 physical cores
32 logical cores
32 logical cores were assigend by the OS
is using 32 logical cores wieder

Normalerweise müsste hier ja bei physical cores 16 stehen

Der Benchmarkscript nutzt aber laut Taskmanager 16 Threads.

Unter dem Cluster Profile Manager lässt sich zwar die Anzahl der Workers manuell festlegen und bei der anschließenden Validierung nutzt MatLab auch 100% der CPU, nur eben dieser Benchmarkscript nicht.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: yummycandy und Ned Flanders
Ich habe den Benchmark mal als Vergleich auf meinem i5 8500 laufen lassen:
https://pastebin.com/55Q3pu2N

Vielen Dank fürs Herausfinden dieses tollen "Features", ich habe mich immer gewundert, warum unsere EPYC Workstation so langsam rechnet.
 
  • Gefällt mir
Reaktionen: I'm unknown, yummycandy, ZeroStrat und 2 andere
@scratchedpaint

Merci dafür. Ich schau mal an wie er sich im Vergleich zu den anderen die ich hab verhält, welche alle Matlab 2019 sind. Wenn er nicht auffällig anders ist, nehm ich ihn auf. Ich hatte im Netz die Ergebnisse von einigen anderen gefunden, die angeblich den gleichen Benchmark verwendet haben, aber beim Überprüfen mit gleichen CPUs kam raus, dass die Ergebnisse teilweise sehr große Ausreißer haben. Ich hab mich jetzt dazu entschieden wirklich nur Benchmarks aufzunehmen, die hier aus dem Forum stammen oder die ich selbst gemacht habe.

Aktuell bedeutet dass:

Xeon E5 2650​
Intel 8700k​
Intel 9900k​
Intel 7820x​
AMD 2600x​
AMD 3700x​
AMD 3900x​
AMD 3950x​
AMD 3960x​
AMD 3970x​

+ i7 7700HQ , + Deinen 8500, + Cool Masters TR 1950x + DualXeon 2620 V3.

Der Übersichtlichkeit halber muss dann irgendwann auf die Bremse getreten werden, ich glaub das ist schon ganz passabel mittlererweile.

Gruss,

Ned
 
  • Gefällt mir
Reaktionen: I'm unknown und scratchedpaint
Ich installiere gerade 2019a (2019b geht leider nicht) und teste es nochmal, dann wissen wir mehr ;)
 
  • Gefällt mir
Reaktionen: I'm unknown und Ned Flanders
scratchedpaint schrieb:
Vielen Dank fürs Herausfinden dieses tollen "Features", ich habe mich immer gewundert, warum unsere EPYC Workstation so langsam rechnet.
Und Lob an dich, du hast dich extra dafür und für die Bereitstellung deines Benchmarklaufes hier angemeldet!
 
  • Gefällt mir
Reaktionen: Ned Flanders
Wenn Intel so einen Dreck abzieht, dann muss man doch zusammenstehen :D
Aber danke!
Der 2019er Benchmark wird heute nichts mehr, da gibt es Probleme mit der Lizenz und ich muss mich jetzt erstmal mit der IT rumschlagen....
 
@Ned Flanders Konntest du eigentlich mittlerweile mal nachschauen, wie im Win10 / Server 2019 Task Manager auf dem Dual Socket System mit SMT die Kerne angeordnet sind?
Der Tooltip auf deinem ersten Screenshot aus #79 zeigt ja bei dem einen Kern "CPU 11 (Node 0)" an. Wenn du da noch über die anderen Kerne drüberfährst mit der Maus, sollte ja eigentlich ersichtlich sein, ob nun der eine Sockel nicht verwendet wurde oder eben doch ein logischer Kern pro physischem Kern.
 
Vielleicht spawnt die MKL nur Threads in Anzahl der physialischen Kerne, da HT bei reiner Mathe theoretisch umsonst ist. Und leider unterscheidet sie bei aktivem HT und Multisocket nicht die Sockets.
 
  • Gefällt mir
Reaktionen: Ned Flanders
Das ist meine Vermutung, aber das müsste ja eigentlich auch mal aufgefallen sein. Alternativ gibt es eventuell Windows Energiespareinstellungen, die Vorzugsweise erst eine CPU laufen lassen bevor eine zweite gestartet wird. Das kann ich aber aktuell nicht testen.
 
  • Gefällt mir
Reaktionen: süchtla
Wie wärs mit einem Test auf *nix? Matlab & MKL laufen dort auch nativ und mal schnell eine Live-Distri vom Stick booten ;)
 
@scratchedpaint

Interessant! Das ist genau der Grund warum ich die Daten aus dem Netz nicht mit aufgenommen habe. Viele davon waren bei SVD absolut unglaubwürdig schnell. Das muss eigentlich ein Bug sein, den man mal bei Mathworks einreichen müsste.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: I'm unknown
Ich hab spaßeshalber meinen nochmal ohne HT gebencht. Erstaunlicherweise bin ich über all ein Stückchen schneller, außer beim matrix multiplizieren. Da bin ich langsamer.
Die Optimierung soll mal einer verstehen.
 
Threads bedeuten Overhead beim Verwalten und auch SMT gibt es seitens der CPU nicht für ganz lau. Bei Berechnungen, die durch Sprungvorhersagen und Prefetch derart gut CPU Stalls (Wartezeiten) verhindern werden können, fällt dieser kleine Overhead halt auf.

Man kann aus den Ergebnissen in etwa folgendes ableiten:
1. Eher kleine Problemstellungen wurden verwendet(normalerweise würde man sowas mit Daten testen die ~ 1/2 des Rams einnehmen)
2. Die verwendeten Matritzen sind alle voll besetzt
3. Prefetch, Sprungvorhersage & Co sind beindruckend effektiv.
 
  • Gefällt mir
Reaktionen: süchtla
Kann man wohl so zusammen fassen. Hab leider keine realen Daten mit spärlich besetzen Matrizen da.
 
@süchtla Ich weiß nicht, ob es dir viel bringt, aber wenn du möchtest, ich hab aus Studienzeiten noch selbst programmierte FEM-Tools (u.a. in Matlab) da, da kann ich bei Interesse gerne was raussuchen. Wobei ich, wenn es um Performance geht sowieso nicht Matlab sondern eine kompilierte Sprache verwenden würde - und wenn es nur auto-generierter Code aus dem Matlab C Compiler ist. Da für reine Matrixmultiplikationen aber ja eh die MKL hergenommen wird, ist es dort egal.
 
Selbst programmierte FEM-Tools? Nicht zufällig was für Microstrip-Simulations? :D

Wenn @Ned Flanders seinen AMD ebenfalls nochmal mit was realistischem bencht, wär das doch ganz brauchbar.
 
Ne, das waren zufällig eher Schulungstools zum Verständnis der FEM-Methode, Spannung/Verformung und Wärmeleitung. Außerdem nur 2D. Wobei, wie war das noch gleich... 'the extension to 3D is straightforward'.
 
Zurück
Oben