News Intel MKL 2020.2: Neuer AMD-Workaround schneller als Zen-Kernel

Wadenbeisser schrieb:
Und wenn es keine Probleme gibt belegt es das es dafür keine technischen Gründe gibt.

Oder keiner der bisherigen Tester des Workarounds hat eine der Systemkonstellationen die bei internen Tests zu Problemen führten.
Nur weil ich und meine 10 Freunde trotz Tempo 200 in der Stadt noch niemanden über den Haufen gefahren haben heißt das ja auch nicht, dass Tempo 200 in der Stadt sicher sei.
Auch wenn mit steigender Anzahl Probanden auch die Wahrscheinlichkeit für deine These steigt.
 
@TrueAzrael

Weil reguläre Software ja auch sonst immer zu 100% fehlerfrei läuft?
Müssen wir jetzt eine unbestimmte Zeit warten bis mal sowas auftritt um dann sagen zu können "ich habe es ja gleich gesagt!" und was passiert wenn ein Intel System betroffen ist? Einfach ignorieren?

Es geht hier um die Nutzung standardisierter Befehlssätze die von der Software unterstützt werden.
Sollte Intel da irgendeine extrawurst gebraten haben die zu diesem Standard nicht vollständig kompatibel ist dann hat es unter einer separaten Befehlssatz Abfrage zu laufen, es müsste offen kommuniziert werden oder man müßte es ausschließlich auf die eigenen Produkte beschrenken. Nichts davon hat Intel gemacht.
 
TrueAzrael schrieb:
Oder keiner der bisherigen Tester des Workarounds hat eine der Systemkonstellationen die bei internen Tests zu Problemen führten.

Just FYI, Mathworks hat vier Wochen lang ihre LA-Test Suite auf den Workaround geworfen, mit dem Ergebnis, dass sie ihn für ihre gesamte Produktpalette freigegeben haben.
 
  • Gefällt mir
Reaktionen: Forum-Fraggle
TrueAzrael schrieb:
Ist halt so eine Sache, wenn man im Fehlerfall dem Support gegenüber dann eingestehen muss, dass man einen nicht freigegebenen Workaround nutzt.
Und? Das wäre dann Problem des Nutzers, also warum sollte es den Hersteller kümmern? Wie bei Holt ist das eine Aussage, bei der ich anfange zu bezweifeln, ob sie von einem Menschen kommt. Das ist doch kein Argument dafür, daß Intel eine künstliche Bremse einbauen muß. Bitte erst wieder antworten, wenn etwas sinnvolles kommt.
Holt schrieb:
Für keinen Bug und keine Sicherheitslücke gab es einen Beleg bevor sie gefunden wurden, dies Argument ist also totaler Unsinn.
Ist das jetzt Dein ernst, oder bist fährst Du nun die Klamaukschiene? Bis gerade dachte ich noch man könnte mit Dir vernünftig diskutieren. Daher ist mein abschließender Kommentar: Du fliegst also nicht und fährst kein Auto, denn obwohl beide als sicher gelten, trifft das ja,nicht zu.
 
Sinnfrei schrieb:
Für so etwas ist Intel bereits mehrfach zu relativ hohen Strafen verurteilt worden. Scheinbar waren die aber noch nicht hoch genug.
Wurden sie eben nicht. Die höhste Strafe die in den Medien war wurde aufgehoben. Intel ist vor Gericht gezogen und hat gegen die EU Kommission gewonnen. Das ist das schöne an unabhängigen Gerichten. Die EU Kommission kann Milliarden verlangen und wenn das Gericht es anders sieht können die Steuerzahler auch noch Intels Prozesskosten Tragen.
 
Forum-Fraggle schrieb:
Und? Das wäre dann Problem des Nutzers, also warum sollte es den Hersteller kümmern? Wie bei Holt ist das eine Aussage, bei der ich anfange zu bezweifeln, ob sie von einem Menschen kommt. Das ist doch kein Argument dafür, daß Intel eine künstliche Bremse einbauen muß. Bitte erst wieder antworten, wenn etwas sinnvolles kommt.

Die künstliche Bremse ist auch nicht zu rechtfertigen, allerdings kann ich im Unternehmensumfeld eben nicht einfach x-beliebige Workarounds in Produktivsystemen einbauen. Wenn das eskaliert bin ich meinen Job oder mein Unternehmen los, sofern der Hersteller die Methode nicht deckt. Mehr hab ich gar nicht gesagt.
Wenn Mathlab wie weiter oben erwähnt, von sich aus das für die eigene Software freigibt, dann hab ich ja meinen Hersteller der das deckt, also alles gut.
 
Adzz schrieb:
Das ist das schöne an unabhängigen Gerichten.
Dann bevorzugst du voreingenimmene Gerichte bei denen das Urteil bereits vor dem Prozess fest steht oder sollte es deiner Meinung nach garnicht erst rechtlich verfolgt und sanktioniert werden? Die sarkastische Unternote ist im weiteren Verlauf ja unschwer erkennbar.

Edit: ach ich sollte das Thema wieder ignorieren.....
 
Zuletzt bearbeitet von einem Moderator:
Wurde das Update 3 schon mal getestet?
Ist wohl ein zeitnah nachgeschobener Fix für Update 2: Addressed performance regressions issue introduced in Intel® MKL 2020 Update 2.
 
Falls sich jemand fragt wie das Ganze jetzt mit Apple Silicon M1 auf den neuen Macs aussieht:

Hier mal ein Benchmark

Ich bin über einen der ersten Apple Silicon M1 Benchmarks unter Matlab gestolpert.

Ich hab zum Vergleich mal meinen alten 2600x gegenübergestellt

Matrix size N=20486C AMD Ryzen 2600x8C Apple M1
TestCalculation time [sec]Calculation time [sec]
SVD:
0,884091​
1,21547​
Eigen:
2,670807​
3,49856​
Cholesky:
0,024629​
0,034597​
QR:
0,136306​
0,145371​
100 matrix products:
10,873585​
19,050479​
Inverse:
0,195866​
0,259115​
Pseudo-inverse:
1,699905​
2,366665​
Matrix size N=4096
TestCalculation time [sec]Calculation time [sec]
SVD:
9,362006​
9,660486​
Eigen:
19,267827​
19,53395​
Cholesky:
0,14654​
0,295916​
QR:
1,056251​
1,118538​
100 matrix products:
82,643343​
164,244627​
Inverse:
1,262526​
1,824012​
Pseudo-inverse:
15,079661​
18,050172​
Total Calculation Time
128,818154​
214,727701​

Apple sitzt offensichtlich im gleichen Nest wie früher AMD.

Matlab Anwender sollten daher bis auf weiters besser zu einer Intel Mac Variante greifen, sollten sie den Mac jenseits des reinen Schreiben des Codes auch bei dessen Ausführung einsetzen. Auch sollte man das Ergebnis eventuell auf einer AMD/Intel x86 CPU noch einmal gegenrechnen lassen, weil unklar ist, wie Rosetta2 die x86 SIMD Befehle überhaupt ausführt und ob es da gegebenenfalls zu Ungenauigkeiten kommen kann.
 
Zurück
Oben