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

[Piktogramm]

Sehr schön erklärt, wenn auch der erste Absatz naive Theorie beinhaltet. Wie soll man das (vor Gericht) nachweisen? Ohne Whistleblower keine Chance und die findet man in der Industrie deutlich seltener als bei Milität oder Politik.

Naja die relevanten Symbolnamen in den Objektdateien habe ich ja bereits herausgesucht. Beim Rest hilft der Decompiler. Damit kann man sauber nachvollziehen was der Code macht. Wobei sich ein ordentlich geschriebenes "Wir Optimieren auf div. Intel CPU Generationen" vs. "Wir bremsen Dritte absichtlich aus" deutlich unterscheiden würde. Dabei würde ich davon ausgehen, dass auf die bzw. eine der schnellsten Mathebibliotheken schon mal Decompiler drauf gefallen sind.

 

[vander]

Wobei sich ein ordentlich geschriebenes "Wir Optimieren auf div. Intel CPU Generationen" vs. "Wir bremsen Dritte absichtlich aus" deutlich unterscheiden würde.

Ich behaupte, der Unterschied ist nicht so groß wie du andeutest.

Es stimmt, daß sie nicht geschrieben haben:
Wenn CPUID() Nicht "Intel" Dann ExtraLangsameBerechnung();

Stattdessen haben sie geschrieben:
Nur Wenn CPUID() Gleich "Intel" Dann OptimaleBerechnung();

Unterm Strich kommt dabei so ziemlich das Gleiche heraus, findest du nicht?

Wenn man andere nicht einschränken und zukunftssicher programmieren will, dann macht man die Auswahl nicht am CPU Hersteller, sondern an den Fähigkeiten der CPU fest, genau das hat Intel aber vermieden.
Da die Intel Entwickler mit Sicherheit was von ihrem Fach verstehen, gehe ich davon aus das sie sehr genau wussten was sie da machen. Die Motivation kann ich trotzdem nur unterstellen, nicht beweisen.
Kann natürlich alles ganz andere Gründe haben, die nur Intel kennt.

 

[Salamimander]

Wisst ihr was mich in der Diskussion nervt? Der Vorwurf AMDs AVX Implementierung könnte Buggy sein... Sogesehen könnte SSE ebenfalls buggy sein, daher faule Ausrede!

Es müssen CPU Features geprüft werden und nicht CPU Hersteller. „Wenn“ man zusätzlich auf bestimmte CPUs hin optimiert, dann KANN an dieser Stelle gerne weiter abgefragt werden aber bitte NACH dem Featureset und nicht bereits davor...

 

[vander]

Auf bestimmten AMD CPUs ist sie das auch, was aber nicht Intels Problem sein sollte. Ein entsprechender Disclaimer für MKL Nutzer "... funktioniert nur ordnungsgemäß auf Intel CPUs ..." hätte sie abgesichert und den schwarzen Peter zu AMD geschoben. Fände ich besser. Da hätte AMD die nächste Umsetzung besser machen müssen.

Man kann es aber als willkommene Ausrede deuten, die MKL und andere Intel Produkte für aktuelle und zukünftige Konkurrenz ungenießbar zu machen, um die eigene Arbeit zu schützen.
Wäre ja noch schöner wenn Intel AVX implementiert und unterstützt, dann kommt die nächste CPU Generation der Konkurrenz und ist mit AVX sogar schneller, da besser umgesetzt.
Also haben sie das mal eben verriegelt. Auch ne Theorie.

 

[adAstra]

@vander

Reicht der Hinweis

Supported Hardware
Intel® Xeon® processor
Intel® Core™ processor family
Intel Atom® processor
Intel® Xeon Phi™ processor

auf der offiziellen MKL-Homepage

https://software.intel.com/en-us/mkl

sowie eine fette Meldung bei der Installation der Bibliothek auf Nicht-Intel-Plattformen?

 

[yummycandy]

Supported Hardware
Intel® Xeon® processor
Intel® Core™ processor family
Intel Atom® processor
Intel® Xeon Phi™ processor

auf der offiziellen MKL-Homepage

https://software.intel.com/en-us/mkl

sowie eine fette Meldung bei der Installation der Bibliothek auf Nicht-Intel-Plattformen?

Die Frage hatten wir schon. Es wäre nach dem Hinweis besser gewesen, wenn sie die MKL auf anderen Systemen überhaupt nicht lauffähig gemacht hätten.

 

[adAstra]

@yummycandy

Dass wir die Frage hier bereits hatten scheint @vander überlesen zu haben - angesichts von fast 30 Seiten durchaus zu verzeihen. Ansonsten würde mich seine Meinung zu dem Thema interessieren, nicht deine bereits geäußerten Ansichten dazu.

Ich persönlich finde deinen Vorschlag unsinnig. Intel macht transparent, dass MKL nur auf ihrer Hardware die volle Performance liefert. Wenn Matlab dies nun ignoriert, dann liegt der Ball nicht mehr bei Intel. Aber wir drehen uns hier im Kreis.

 

[vander]

@KuestenNebel
Ich hätte mich für deine Argumentation eher darauf bezogen, passt besser als die allgemeine "Supported" Phrase und steht auch für andere Intel Produkte, wie ICC oder VTune.

Meine Meinung dazu, ich kann die Argumente beider Seiten nachvollziehen. Es ist schwer hier eindeutig von gut und böse zu sprechen. Meine Meinung ist da auch subjektiv.

Probleme ergeben sich IMO aus der Marktbeherrschenden Position die Intel hat. Wenn eine Firma ihr Produkt 100% gegen Mitbewerber abschotten dürfte, hätte es auch nie eine Verurteilung Microsofts (Browser Weiche) gegeben. Auch da fehlt IMO das entsprechende Urteil zu Android, wobei Google das inzwischen überflüssig gemacht hat, indem sie alle anderen Browser Engines erfolgreich vom Markt verdrängt haben.
Den Konkurrenzkampf auf dem Markt auszuhebeln (Sozialismus) oder die Ausschaltung jeglicher Konkurrenz eines Marktteilnehmers finde ich nicht wünschenswert, aus Verbraucher Sicht. Deswegen gibt es da bestimmte Spielregeln/Gesetze.
Ob Intel hier gegen geltendes Marktrecht verstößt müsste ein Gericht klären. Das dies aktuell nicht passiert kann mehrere Ursachen haben.
Die negativen Folgen für den Verbraucher sind IMO bereits sichtbar/nachweisbar.

P.S. Ich finde gerade den Link nicht, aber hatte vor einiger Zeit mal gelesen das in einer der bekannten Engines (Unity, Unreal, FMOD?) eine Soundroutine auf AMD CPUs signifikant langsamer abgearbeitet wurde(2ms zu 200ms glaub ich), was immer wieder zu entsprechenden Performance Problemen führte.
Vielleicht ein Programmierfehler, schlechte QS, AMD schwieriger zu programmieren, ... vielleicht auch nicht.
Für den Anwender auf jeden Fall Mist, da weder vorhersehbar noch zu beheben.

P.S.S. Ich bin nach meinem letzten Post auf, Seite 19 oder so, direkt hierher gesprungen. Habe tatsächlich nicht alles gelesen

 

[Piktogramm]

Ich behaupte, der Unterschied ist nicht so groß wie du andeutest.

Es stimmt, daß sie nicht geschrieben haben:
Wenn CPUID() Nicht "Intel" Dann ExtraLangsameBerechnung();

Stattdessen haben sie geschrieben:
Nur Wenn CPUID() Gleich "Intel" Dann OptimaleBerechnung();

Unterm Strich kommt dabei so ziemlich das Gleiche heraus, findest du nicht?

Wenn man andere nicht einschränken und zukunftssicher programmieren will, dann macht man die Auswahl nicht am CPU Hersteller, sondern an den Fähigkeiten der CPU fest, genau das hat Intel aber vermieden.
Da die Intel Entwickler mit Sicherheit was von ihrem Fach verstehen, gehe ich davon aus das sie sehr genau wussten was sie da machen. Die Motivation kann ich trotzdem nur unterstellen, nicht beweisen.
Kann natürlich alles ganz andere Gründe haben, die nur Intel kennt.

Nunja, es gibt den Codepfad "extra langsam" halt nicht. Es gibt einen Default, den auch alle Intel CPUs vor Penryn (Core2Duo) bzw. auch spätere Atoms benutzen müssen. Dieser Default verlangt glaube ich mindestens SSE2.
Das von den sonstigen Optimierungen des Intel Produkt fast nur Intel profitiert, ist halt so. Fast so als wäre das Ganze im kapitalistischem Wettbewerb angesiedelt. Solang Intel kein "extra slow" Code für Konkurrenten einbinden sind die Wettberwerbsregeln erfüllt. Machen am Ende alle so, Apple mit Swift und Mantle, Microsoft lage mit .Net und heut noch mit DirectX, Nvidia mit CUDA, ... Alles irgendwo geile Technologien, aber alle im große Maße proprietär. Wer was anderes will, es gäbe da ein Universum an BSD, GPL, Apache und MIT lizenzierten Alternativen. Oft weniger gülden, dafür aber auch weniger Käfig.

Wisst ihr was mich in der Diskussion nervt? Der Vorwurf AMDs AVX Implementierung könnte Buggy sein... Sogesehen könnte SSE ebenfalls buggy sein, daher faule Ausrede!

Das hat so Niemand behauptet. Meine These war: Die Codepfade könnten mehr enthalten als nur AVX Code und zu Konflikten führen auf CPUs die diese Features trotz AVX2 Unterstützung nicht haben. Genauso wie es CPU Bugs geben könnte, auf die man intensiv Testen müsste. Vor allem da Intels ICC Compiler die AMD CPUs nicht kennt und deren Errata nicht beachtet und damit potentiell problematischen Code ausspucken könnte. Genauso wie die Teile die Assembler geschrieben wurden getestet werden müssten.
Das ist schlicht und ergreifend Qualitätssicherung wie er Branchenstandard ist (sein sollte..).

Naja und die Zen (17h) Errata zeigen unter Punkt 990 immerhin auf, dass Performancecounter für SSE/AVX probleme haben können. Errate für Zen+ und Zen2 gibt es noch nicht öffentlich.

Die Frage hatten wir schon. Es wäre nach dem Hinweis besser gewesen, wenn sie die MKL auf anderen Systemen überhaupt nicht lauffähig gemacht hätten.

Dann würden sie gegen Auflagen der FTC verstoßen, wo sie genau das nicht machen dürfen.
Mit der Aktion würde sehr viel Software im professionellen / wissenschaftlichem Bereich gar nicht auf AMD laufen und hätte in diesem Marktsegment einen noch viel schwereren Stand.

 

[vander]

Nunja, es gibt den Codepfad "extra langsam" halt nicht.

Hab auch nichts anderes behauptet ;-)

Es stimmt, daß sie nicht geschrieben haben:
Wenn CPUID() Nicht "Intel" Dann ExtraLangsameBerechnung();

 

[Gerry18]

Wenn ich mir die ganze Diskussion hier ansehen wer den nun Schuld ist, dann ist die richtig kindlich. Nicht kindisch sondern kindlich.
Den am Ende spielt es keine Rolle wer wirklich schuld ist, wie es sich wirklich verhält und welche Auswirkung es hat. Leider. Ein Rolle spielt am Ende wie es von der Allgemeinheit wahr genommen wird und die wird sein INTEL ist viel böse.
Die Meisten haben keine Ahnung von der Materie, das heißt welche Auswirkungen hat es. Die werden sich auch damit nicht Beschäftigen, warum auch. Ist nicht ihr Feld. Zu solchen Menschen zähle auch ich. Wo bei mir würde es schon Interessieren was heißt es in der Praxis genau. Eine Antwort darauf hab auch ich hier nicht gefunden.

Ein Antwort kann man hier aber auch kaum finden, die paar die es versuchen zu ergründen gehen in den Ego Argumenten einfach unter.
Daher bleibt am Ende was übrig. INTEL ist viel böse und alle die INTEL verteidigen sind die Handlanger des Bösen.
Ja Leute so ist eben die Welt die wir geschaffen haben.

Anstatt hier eine kindliche Diskussion zu führen wäre es wichtig das sich die Profis ( damit meine ich aber nicht die selbst ernannten Profis ) mal hinsetzen und mal versuchen heraus zu finden welche Auswirkungen das genau hat in der Praxis und wo. Nur dann kann auch an den Richtigen Stellen druck ausgeübt werden das es verbessert wird.

 

[blöderidiot]

Anstatt hier eine kindliche Diskussion zu führen wäre es wichtig das sich die Profis ( damit meine ich aber nicht die selbst ernannten Profis ) mal hinsetzen und mal versuchen heraus zu finden welche Auswirkungen das genau hat in der Praxis und wo.

Genau das findest Du hier im Thread. Es ist allerdings aufgrund des schieren Umfangs a) mühevoll und b) musst Du selber ein wenig "Profi" sein, um die richtigen Antworten richtig beurteilen zu können. Im Grunde ist alles gesagt worden und die Gründe und die Geschichte der Gründe sind auch klar geworden.

Nur dann kann auch an den Richtigen Stellen druck ausgeübt werden das es verbessert wird.

Oder auch nicht ...

 

[vander]

... und die wird sein INTEL ist viel böse.

Wie genau stellst du dir das vor, so wie beim bösen VW? "Der Teufel scheißt auf den größten Haufen." Daran ändert sich auch so schnell nichts.

 

[cm87]

https://www.extremetech.com/computi...ss-matlab-cripple-amd-ryzen-threadripper-cpus

Danke @yummycandy

 

[yummycandy]

https://www.extremetech.com/computi...ss-matlab-cripple-amd-ryzen-threadripper-cpus

 

[Iscaran]

GROMACS 2019.4 Update schein übrigens auch EXAKT dieses Problem zu fixen.
http://manual.gromacs.org/documentation/2019.4/release-notes/2019/2019.4.html
"The AMD Zen 2 architecture is now detected as different from Zen 1 and uses 256-bit wide AVX2 SIMD instructions (GMX_SIMD=AVX2_256) by default. Also the non-bonded kernel parameters have been tuned for Zen 2. This has a significant impact on performance. "

Lustigerweise fiel das Intel wohl selbst auf als sie GROMACS Benchmarks im Rahmen des Xeon vs Epyc Marketings machten :-)
https://www.servethehome.com/intel-...blishing-intentionally-misleading-benchmarks/
https://twitter.com/Patrick1Kennedy/status/1191841705625997312
https://www.servethehome.com/update-to-the-intel-xeon-platinum-9282-gromacs-benchmarks-piece/

 

[blöderidiot]

GROMACS 2019.4 Update schein übrigens auch EXAKT dieses Problem zu fixen.
http://manual.gromacs.org/documentation/2019.4/release-notes/2019/2019.4.html
"The AMD Zen 2 architecture is now detected as different from Zen 1 and uses 256-bit wide AVX2 SIMD instructions (GMX_SIMD=AVX2_256) by default. Also the non-bonded kernel parameters have been tuned for Zen 2. This has a significant impact on performance. "

Genau! Siehe hier: https://www.computerbase.de/forum/t...f-amd-ryzen-signifikant.1906207/post-23375074

 

[Ned Flanders]

@blöderidiot

Also bei Matlab tut sich wohl was... ich hab von einem Mitarbeiter die inoffizielle Nachricht bekommen, dass sie sich ein paar Threadripper 2950x Systeme bestellt haben. Auch schreibt einer der ranghöheren Entwickler (Patrick Quillen) in mehreren Foren:

At MathWorks, we are continuing to investigate this to determine if we can qualify a change to the full production release of MATLAB. Note that in the meantime we are unable to confirm that using these environment variables will work correctly throughout our products, so use at your own risk.

In addition to the approach suggested above, it is possible to substitute a different BLAS implementation for the BLAS qualified by MathWorks for use in MATLAB. This can be done by specifying the full path to the .so/.dll containing your BLAS implementation in an environment variable called BLAS_VERSION. This comes with the same caveats that MathWorks has not qualified our products against alternate BLAS implementations, so as above, we can't confirm that using your own BLAS, such as OpenBLAS, will work correctly throughout our products.

https://de.mathworks.com/matlabcent...rformance-for-modern-amd-cpu-s#comment_768441

Da gibts auch noch etwas mehr Infos von Quillen dazu.

Ich bin ja mal gespannt was dabei raus kommt, aber zumindest gerät der Stein wohl ins Rollen. Wurde ja auch höchste Zeit!

 

[yummycandy]

In addition to the approach suggested above, it is possible to substitute a different BLAS implementation for the BLAS qualified by MathWorks for use in MATLAB. This can be done by specifying the full path to the .so/.dll containing your BLAS implementation in an environment variable called BLAS_VERSION.

Auch das erste Mal, daß ich das so lese. Ist also möglich jetzt schon OpenBLAS oder BLIS zu benutzen, insofern sie die gleiche API wie die MKL haben?

 

[Ned Flanders]

@yummycandy

Pat Quillen etwa 20 Stunden ago

Yes, this is not well-known. It is not documented, and we usually only tell folks about it when they call into customer support.
To help clarify, what I'm saying is that upon load of the BLAS, MATLAB checks for the existence of BLAS_VERSION and loads whatever library is pointed to by that variable in lieu of the default specified by MATLAB. MATLAB looks for symbols corresponding to those in the BLAS standard: netlib.org/blas and uses them as the BLAS. If you have a complete BLAS from your vendor, or if you've compiled one, you should have no problem.

Was auch wieder traurig ist, denn den guten Wick und viele Andere die nach Hilfe im Support Forum gefragt haben, haben sie nie darauf hingewiesen... und sind wohl auch nicht auf die Idee gekommen das mal offiziell zu unterstützen.

Aber Quillen ist definitiv ein höheres Tier und hat, abgesehen von diesem Post, auch noch nie etwas im Support Forum geschrieben. Auch sein Post bei Reddit und Extreme Tech ist der jeweils erste überhaupt.