News Intel MKL: Workaround erhöht Leistung auf AMD Ryzen signifikant

[Hallo32]

@Ned Flanders
Was hast du als Benchmark verwendet?

 

[Ned Flanders]

@Hallo32

Den integrierten Matlab Benchmark (Bench(4)) und das im Reddit Artikel verlinkte Script.

 

[Müritzer]

Eine unendliche Geschichte in 5 Buchstaben zusammengefasst: Intel

 

[Discovery_1]

Ich werde die Variable? Morgen mal standardmäßig eingeben. Ob's bei meinem R5 2600 was bringt? Naja, ist zumindest kein Übertakten. Kaputt machen, kann ich ja nix.

 

[wayne_757]

Worum geht es dann in dieser News frage ich mich.

Ich formuliere es um:
AMD selbst kann hierfür keinen sinnvollen Workaround anbieten

 

[Hayda Ministral]

Nvidia mit PhysX was auf CPU´s grundsätzlich nur einen Kern nutzen tut.

Auch auf NVIDIAs CPUs? Dann gibt das zwar schlechtes Karma, ist aber dennoch kein Vendor-Bashing.

 

[SVΞN]

Artikel-Update: Auch NumPy für Python betroffen

Wie sich mittlerweile herausgestellt hat, ist auch NumPy, eine Programmbibliothek für die Programmiersprache Python, von der eingangs geschilderten Problematik betroffen. Intern verwenden sowohl Matlab als auch NumPy die beiden Programmbibliotheken BLAS und LAPACK, die ihrerseits Bestandteil der Math Kernel Library sind, für eine effiziente Berechnung linearer Algebra.

Ein Test von Puget Systems zeigte bereits im August dieses Jahres ähnliche Auffälligkeiten wie die von Ned Flanders in Matlab nachgewiesenen.

Apparently this trick does also some magic to pythons numpy on windows (std conda install that brings the mkl lib in and no way to change to openblas easily). The code shown in the article below took 64s on my Ryzen 3600 with the workaround and 266s without it!

Sammelthread im ComputerBase Forum

Da in Kürze mit Benchmarks und Ergebnissen zu weiteren betroffenen Programmen zu rechnen ist, haben die Forenmitglieder ZeroStrat und erneut Ned Flanders einen Sammelthread dazu ins Leben gerufen. ZeroStrat selbst hat mittlerweile Ergebnisse für einen AMD Ryzen 9 3900X vorlegen können, welche die bisherigen Ergebnisse von Ned Flanders bestätigen. Die beiden rufen die Community dazu auf sich zu beteiligen.

 

[Ripcord]

@Red59 Allerdings sehe ich die Schuld weniger bei Intel, sondern beim Entwickler solcher Tools.

Wir wissen nicht, ob sich die Entwicker an Vorgaben eines speziellen Chipherstellers halten. Daher muss man bis das geklärt wurde beiden den schwarzen Peter zuschieben oder beide für unschuldig halten.

Die Erfahrung aus der Vergangenheit lässt da aber kaum Interpretationsspielraum...

Eine unendliche Geschichte in 5 Buchstaben zusammengefasst: Intel

Deswegen kauf man auch die alte DVD und nicht die verpfuschte neue amerikanisierte Bluray

 

[max9123]

@Ned Flanders

Eine Frage hätte ich noch.
Erkennt MKL die Anzahl an Kernen korrekt (nur die physischen Kerne sollten verwendet werden)?
Ansonsten vermindert sich die Performance relativ deutlich.
Falls nicht sollten folgende Umgebungsvariable richtig gesetzt werden:

bei 6K/12T:
MKL_NUM_THREADS=6

 

[xxMuahdibxx]

Auch auf NVIDIAs CPUs? Dann gibt das zwar schlechtes Karma, ist aber dennoch kein Vendor-Bashing.

Du weist wie PhysX funktioniert und was eine CPU ist ?

Nvidia -> PhysX wird über die GPU und auch teilweise CPU berechnet aber halt auch Mehrkern Optimiert.

AMD -> PhysX wird über die CPU only berechnet aber dabei auf einen Kern beschränkt.
Aber da PhysX so gut wie tot ist ... kommt jetzt Raytracing :-)

@ Mods ... wenn ihr schon sagt das es einen Sammelthread dazu gibt ... denn verlinkt den doch in den Eingangspost.

 

[JaKno]

ein Schelm, wer Böses dabei denkt

 

[wayne_757]

Was viele hier im Übrigen auch vergessen ist die Tatsache, dass Intel aus einer marktbeherrschenden Position heraus agiert. Das macht das ganze doppelt kritisch.

Bei uns im Konzern gibt es da Compliance Regeln. Für so eine Aktion bekäme man da im besten Fall eine Abmahnung und im schlechtesten wäre man den Job los.

 

[Piktogramm]

Wie das imho eigentlich ablaufen sollte wäre folgendermaßen:

- Die Software (MKL) fragt das Feature Set der CPU ab. Die CPU sagt: Ich kann SSE, SSE2, SSE3, SSE4, AVX, AVX2.

- Die Software verwendet entsprechend den schnellsten verfügbaren Codepath.

Und so funktioniert das im Allgemeinen auch und auch die Intel MKL muss das ja so machen, denn wenn sie auf einem Intel Ivy Bridge läuft, kann sie ja auch kein AVX2 verwenden.

Warum man da eine Vendor String Abfrage braucht erschließt sich mir nicht. Die macht die Software in keinem einzigen Fall schneller. Der einzige Grund warum man diese einbaut ist den Code unter Vorraussetzung X gezielt langsamer zu machen. Da kann man diskutieren ob das legal, egal oder normal ist. Ich finds Mist.

Jain, Intel optimiert immer für die neusten ihrer CPUs um Verkaufsargumente für diese zu haben. Bei diesen CPUs weiß Intel auch ganz genau welche Features sie haben. Eine genaue Unterscheidung zu bauen, welche Features die CPUs haben macht an der Stelle schlicht keinen Sinn, eine Unterscheidung nach CPU Generation reicht um dieses Ziel zu erreichen.

Ansonsten, AMD hat eigene C/C++ Compiler und Bibliotheken die für AMD aber nicht Intel optimiert wurden (Link). AMDs ROCm (GPU Compute/OpenCL) läuft nur auf AMD GPUs genauso wie Nvidias CUDA Cosmos recht exklusiv ist. Gerade bei AMDs Compiler und Bibliotheken ist hauptsächlich der Unterschied, dass man die in kaufbarer Software fast nicht findet und deswegen da nicht feststellen kann, dass Intel nicht gut wegkommt. Was aber auch damit zu tun hat, dass Intel Compiler und Bibliotheken wesentlich konsistenter pflegte als AMD.

Ergänzung (18. November 2019)

Bei uns im Konzern gibt es da Compliance Regeln. Für so eine Aktion bekäme man da im besten Fall eine Abmahnung und im schlechtesten wäre man den Job los.

Deine Firma zahlt also dafür, dass du dafür sorgst, dass die Konkurrenzprodukte auf euren Systemen gleich gut oder besser läuft?

 

[Ned Flanders]

Eine genaue Unterscheidung zu bauen, welche Features die CPUs haben macht an der Stelle schlicht keinen Sinn, eine Unterscheidung nach CPU Generation reicht um dieses Ziel zu erreichen.

Aber garantiert macht Intel eine Feature Abfrage und keine Model Generation Abfrage. Das wäre viel zu riskant und fehleranfällig. Dafür gibts ja Feature Set Report Functions.

 

[rudl]

Wtf! Mir fehlen die Worte
(Nicht das meine alten phenoms und Sandy Bridge Prozessoren avx2 könnten^^)

 

[Foma]

Ich verstehe nicht wofür diese Leistungssteigerung dient, wird das System schneller oder Spiele oder betrifft es nur spezielle Programme. Ich lese ständig nur Benchmark hier, Benchmark da, machen die Leute den ganzen Tag nur Benchmarks? Klärt mich bitte auf!

 

[cunhell]

Liegt daran dass AMD nie in etwas investiert. Nvidia und Intel hängen sich bei vielen Entwicklern rein, AMD nicht mal bei ihrer eigenen Software / Treibern / Firmware. Langjährige Erfahrungen mit viel Ärger verbunden lassen mich einen Bogen um AMD machen. Nach dem Hype kommt der Fall, spätestens wenn sie die nächste heiße Kartoffel aus dem Ofen holen.

In diesem Fall: Wäh, Intel Software mag meine AMD CPU nicht. Aber nicht: Warum hat AMD keine eigene Software?

Mal zu Intel. Die haben seit Jahren üble Security Bugs in ihren Prozessoren die selbst in den neuesten Prozessoren zum Teil nur durch Workarounds und nicht in Hardware gefixed sind. Hatten diverse Bugs in ihren Chipsätzen, die die Features, die angeblich vorhanden sind, unbrauchbar oder nur eingeschränkt nutzbar machten (Sata, USB).
Die User der Atom-Prozessoren freuen sich auch schon darüber, dass Intel es geschafft hat, alte, vermeintlich gelöst Probleme in den Celeron 3000 und 4000 wieder aufleben zulassen, die die Lebensdauer der Prozessoren deutlich reduzieren können. Werden ja nur in NAS-Systemen und Netzwerkgeräten verwendet. Juckt ja nicht.
Müssen ja nicht zuverlässig sein die Dinger.
Haben, wie schon oft erwähnt, in ihrem Compiler die CPU-ID abgeprüft und Features ihren eigenen Prozessoren vorbehalten obwohl die Mitbewerber diese auch unterstützten.
Von den unlauteren Machenschaften, die ihnen eine, mMn, lächerlich hohe Strafe eingebracht haben, ganz abgesehen.
Zudem hat ihnen AMD mit ihrem x86_64-Befehlsatz schön die Show gestohlen und Intel ist damit, mit ein paar Ausnahmen, auf ihren IA64-Prozessoren sitzen geblieben.

Nvidia setzt bei ihren "Produkten" auf Closed Source, während AMD versucht, das Ganze unter Open Source zu fördern. Während AMD mit Mantle versuchte, hardwarenahe Programierung zu ermöglichen, förderte Nvidia DX11 anstatt was neues zu liefern. Lag ja den eigenen Karten super und man konnte glänzen. Das Vulcan und DX12 kurz nach der Veröffentlichung von Mantle ins Laufen kam, kam nicht von ungefähr. Und wenn man so diverse Foren liest, sind die Nvidia-Treiber bei weitem nicht mehr so toll, wie gerne behauptet wird.
Und Nvidia findet DX12 auch plötzlich ganz toll weil man es für DXR benötigt. Sonst würden vermutlich immer noch DX11 Spiele massiv gepuscht werden.

Und nein, es geht nicht darum, dass die Intel-Software nicht für AMD optimiert ist. Die Software ignoriert einfach einige Funktionen der CPUs, wenn nicht Intel zurück gemeldet wird, obwohl die CPUs die Featuresets unterstützen.
Das hat nichts mit optimieren zu tun.

Cunhell

 

[usb2_2]

@Foma
Das Problem ist, dass sowas ähnliches schon vorgekommen ist und für illegal erklärt wurde.

Du ließt hier von Benchmarks, da besonders auch da geschummelt wurde und Leute entsprechend eine Intel CPU gekauft haben, die am Ende nicht schneller war, als die von AMD. Dafür mussten sie die Nutzer in den USA schon entschädigen.

Die Leistung wird in einigen Programmen für AMD jetzt mit der Anpassung höher ausfallen.

 

[rudl]

Ich verstehe nicht wofür diese Leistungssteigerung dient, wird das System schneller oder Spiele oder betrifft es nur spezielle Programme. Ich lese ständig nur Benchmark hier, Benchmark da, machen die Leute den ganzen Tag nur Benchmarks? Klärt mich bitte auf!

Betrifft Mal so ziemlich alles was mit Data science zu tun hat gravierend genug. Bei spielen kann man nur mutmaßen.

 

[Piktogramm]

@Ned Flanders
Wieso denn? Beim Compilieren ist die simple Methode ja auch nur die Architektur anzugeben march=$cpugen. Wenn die optimierten Codepfade so erzeugt werden, ergibt es wenig Sinn Codepfade anders zu wählen als durch eine Abfrage der CPU Generation. Falls Irgendwo handgeklöppelter Assembler eingebunden werden muss, kann man die Unterscheidung mit Compilerhints beim Buildprozess erledigen oder durch Buildscripts. An so einer Stelle reicht es dann auch, wenn man den zu nutzenden Codepfad anhand der CPUgeneration festmacht. Binaries die eine genauere Unterscheidung nach Featureset zulassen fallen ja eh nicht aus dem Buildprozess.