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

[Diablokiller999]

@Diablokiller999

Und kannst du einmal erklären, wo genau das Problem ist abgesehen von Matlab?

Ja, ist ganz einfach. So eine Abfrage macht man nicht ohne Hintergedanken, weil sie nämlich nur dazu dient, die Konkurrenz schlechter darstehen zu lassen. Simple as that

 

[Müs Lee]

Hat hier jemand Abaqus zur Verfügung? Würde mich interessieren, welche Unterschiede sich da ergeben.

 

[calluna]

@Diablokiller999

Ja, das ist richtig... aber ebenso richtig ist, das es sich bei der MKL um proprietäre Software handelt, die Teil des "Intel Parallel Studio XE" und vom Anbieter explizit nur für die Verwendung eigener Produkte gedacht ist.

Etwas anderes ist dagegen die MKL-DNN, die open source ist. Dort findet so eine Benachteiligung nicht statt und AMD ist in den Benchmarks deutlich besser als vergleichbare Intel CPUs. (Aber bei der MKL-DNN spielt Zuverlässigkeit der Algorithmen auch keine so große Rolle.)

Und ich bleibe dabei: für mich liegt der Fehler im Fall von Matlab bei Mathworks, denn es ist ok, die MKL-DNN einzubinden, was sie ja getan haben, aber nicht die MKL ohne die Alternative auf OpenBLAS und Co.

Alles andere, wie der Verweis auf NumPy in der News, ohne da zu differenzieren und es korrekt darzustellen, ist für mich nur ein Ausnutzen der allgemeinen Gefühlslage beim Thema Intel vs. AMD, um möglichst viele Klicks zu generieren.

 

[Jim Panze]

Aber deren Software prüft auf die ID und wenn die nicht auf Intel lautet, dann werden Features, die eigentlich vorhanden sind, nicht genutzt. Inwiefern soll das nicht Intels Schuld sein?
Das hat doch System.

 

[calluna]

@Jim Panze

Es ist deswegen bezogen auf Matlab nicht Intels Schuld, weil es in der Verantwortung von Mathworks, dem Entwickler, liegt, die passende BLAS / LAPACK Implementierung zur jeweiligen Hardware auszuwählen... vor allem dann, wenn bei den Hardwareanforderungen bezogen auf AVX auch AMD genannt wird.

Davon abgesehen... das mit der MKL ist auch nur deswegen ärgerlich, weil es von allen Implementierungen die beste ist - aber die anderen Implementierungen sind ja deswegen nicht schlecht!

 

[Atent123]

Lass es mich so formulieren. Sie benutzen IMO extra keine Feature Set Abfrage, um den Einsatz von nicht Intel CPUs zu erschweren.

Da es auch bei Intel CPUs große Variationen beim Feature Set gibt, müssen sie eine solche Anfrage eh durchführen.

 

[gaelic]

Ach komm... du und deine Kollegen nutzen zuhauf Numpy, also Python... und ihr habt bis jetzt nicht die Unterschiede zwischen den verschiedenen Backends für Numpy und Co. gekannt?

Wohin soll ich kommen?

Jd ja, wir nutzen zuhauf NumPy. Und das im Prototyping und das auf sehr diversen Geräten, Linux, Windows, Mac; alles dabei. Prozessoren von i2500 bis hin zum aktuellen Threadripper. Manche haben Python direkt vom System (vor allem Linux) installiert, andere nutzen (ana)conda; manche haben auch ein venv im Einsatz.

Aber was erzählt ich dir auch. <*))))<

 

[RuhmWolf]

Ein besonderer Dank an Ned Flanders und alle Beteiligten, die beim Aufarbeiten mithelfen, genauso auch ein großer Dank an die Trolls im Thread: sehr hohes Trollniveau, so dass man mit Freude auch diese Beiträge liest. Die Kirsche auf der Torte ist natürlich der versteckte Fisch:

Wobei das perspektifisch auch auf alle kommenden Versionen der MKL zutreffen muss.

Genial unterschwellig. Danke <*))))<

@calluna Witze erklären kommt nie gut an.

Es bleibt ein genialer Schachzug perspektifisch anstelle von perspektivisch zu schreiben.

 

[calluna]

@gaelic

Na wenn vor allem Linux genutzt wird... kein Problem: unter pip einfach nicht "install intel-numpy" schreiben und unter Conda "conda install nomkl" und einfach OpenBLAS verwenden. Unter conda-forge ist das auch der Standard.

@RuhmWolf

Welche Ironie, dass dein letzter Beitrag genau das ist: ein Troll-Post.

 

[Ned Flanders]

Aber deren Software prüft auf die ID und wenn die nicht auf Intel lautet, dann werden Features, die eigentlich vorhanden sind, nicht genutzt. Inwiefern soll das nicht Intels Schuld sein? Das hat doch System.

Ich schreib hier nochmal meine Meinung dazu rein falls die noch nicht ganz klar war.

Die Ursache für die Misere ist die Abfrage des Vendor Strings durch die Intel MKL. Diese führt dazu, dass völlig unabhängig vom vorhanden Feature Set, auf CPUs die nicht von Intel stammen, kein Codepfad moderner und schneller als SSE benutzt wird. AFAIK ist das auch ein einmaliges Vorgehen. In jedem Programmers Guide, auch denen von Intel wird eine Feature Abfrage und nicht der Vendor String zur Ermittlung der Fähigkeiten einer CPU empfohlen.

Warum Intel das macht ist nur zu logisch. Ihre eigenen CPUs werden durch dieses Vorgehen kein Stück schneller. Das ist eine aktive Maßnahme um die Konkurenz schlecht dastehen zu lassen, ein Performance Kill Switch. Eine voll auf Intels Architektur (Cachegrößen, Anbindung, Latenzen etc.) optimierte MKL wäre auch so auf Intel CPUs sicherlich schneller als auf nicht-Intel CPUs, aber natürlich keine 400%. Das ist der Punkt den man diskutieren kann. Ist das gut? Ist das schlecht? Ist das sinnvoll? Ist das gerecht? Ist das normal? Die Meinungen dazu gehen auseinander und nach heftigem Schütteln trennen sie sich typischer Weise in eine blaue und eine grüne Phase. Ich persönlich finde das Vorgehen absoluten Käse.

Allerdings bewirbt Intel die MKL auch nicht als universale, numerische Library sondern als die schnellste nummerische Library auf Intel CPUs.

Matlab und noch so einige andere haben diese Library nun in ihre Software übernommen und Intel pushed Hardware Reviewer dazu doch mal Benchmarks mit einer solchen Software zu machen. --> Marketing.

Aus Endkunden Sicht könnte einem das alles bis zu diesem Punkt eigentlich völlig egal sein, solange die Software Hersteller nicht so bescheuert wären die MKL als EINZIGE nummerische Library einzubinden und dem Benutzer gar keine Wahl lassen würden eine Alternative zu verwenden.

Ich beispielsweise benutze Matlab für allerlei Zeug. Die Lizenzgebühren für Matlab sind nicht gerade gering. Matlab gibt als Systemvorraussetzung an, dass eine Intel oder AMD CPU mit AVX2 Unterstützung empfohlen ist, was absurd ist, denn AVX2 wird auf AMD CPUs garnicht unterstützt, weil die MKL das unterbindet. Eine alternative Lib kann ich aber selbst manuel garnicht einbinden.

Bei anderen kann man das zwar, aber es ist oft mit erheblichem Aufwand verbunden.

Wer hat also Schuld an der Misere:

Matlab hat die Wahl, sie könnten problemlos zwei alternative Libs beim Installieren anbieten. Das ist kein Hexenwerk. Octave bietet sogar mehrere an. Warum tun sie es nicht? Ignoranz nehme ich an. Eventuell auch Unwissen. Mein Kontakt mit dem Support suggeriert: vermutlich beides.

Intel ist auch kein zahmes Kätzchen hier. Sie vertreiben proaktiv Software die mit einem Performance Kill Switch ausgestattet ist und benutzen diese Software dann um zu zeigen wie viel schneller ihre Hardware sei. Dabei spielt eben auch Marktmacht eine Rolle. Sie versuchen aktiv Prozessoren der Konkurenz für gewisse Aufgaben untauglich zu machen. Wer sowas verteidigt... ich verstehe es nicht.

Meine Hoffnung: Das meine Aktion etwas "awareness" für diese Problematik weckt, denn obwohl ich das immer wieder angesprochen habe, hört doch keiner zu. Ich bin jedenfalls gespannt, ob Firmen wie Matlab jetzt darauf reagieren und dem User eine sinnvolle Wahl anbieten. Das gilt auch für die anderen Projekte wie numpy etc. Das Intel sein Verhalten ändert, davon würde ich nicht ausgehen, zumindest solange nicht, bis die meisten Projekte und Hersteller anfangen dem User die Wahl direkt bei der Installation zu überlassen.

Gruss, Ned

 

[gaelic]

@gaelic

Na wenn vor allem Linux genutzt wird... kein Problem: unter pip einfach nicht "install intel-numpy" schreiben und unter Conda "conda install nomkl" und einfach OpenBLAS verwenden. Unter conda-forge ist das auch der Standard.

Ich habe nicht geschrieben daß vor allem Linux verwendet wird. Sondern wenn Linux verwendet wird, kommen die Pakete und libs vor allem direkt von der Distri und es wird (weniger) conda verwendet. Wobei sich das mitunter verschiebt ...

 

[calluna]

Intel ist auch kein zahmes Kätzchen hier. Sie vertreiben proaktiv Software die mit einem Performance Kill Switch ausgestattet ist und benutzen diese Software dann um zu zeigen wie viel schneller ihre Hardware sei. Wer sowas verteidigt... ich verstehe es nicht.

Also das habe ich nicht verteidigt und ich sehe auch nicht, wer das hier sonst noch verteidigt hat. Für mich hat das eine mit dem anderen nichts zu tun.

Und das ist auch keine MKL spezifische Sache... es liegt anscheinend am Intel-Compiler: http://public.clu2.fastmail.us/icc_cpu_dispatch.html

Das sollte jeder, der die Compiler verwendet, überschreiben.

@Ned Flanders ... so wie ich das sehe, ist es bei NumPy kein Problem, oder irre ich mich? Unter Linux sowieso nicht und für Windows und Conda sollte das hier reichen: conda install "blas=*=openblas"

@gaelic

Mit "numpy.config.show()" kannst du im Zweifelsfalls checken, was verwendet wird.

 

[jemandanders]

Wer will kann sich ja auch mal bei AMD beschweren, AMD hat ihre Softwareunterstützung massiv zurückgefahren.

Das habe ich in der Tat schon getan.
Offenbar hat AMD in den schweren Jahren alles zurück gefahren, was zum Überleben nicht absolut dringend notwendig war. Dies sollte/muss/wird (hoffentlich) auch wieder geändert werden sobald mehr Geld in der Kasse ist.
Vielen Dank übrigens für deinen Link: https://www.agner.org/optimize/blog/read.php?i=49#49
Finde ich sehr aufschlussreich.

Das ist alles 2009 bekannt und nicht auf einer "verstaubten" Forenseite sondern tatsächlich auf Mailinglisten die Leute nutzen die den ganzen Komplex verstehen und entsprechende Software entwickeln.

Nur, das mich das Thema 2009 noch nicht tangiert hat.
Es ist aber jetzt interessant für mich, da ich mittlerweile fest Entschlossen bin Intel, zumindest für die nächsten Jahre, den Rücken zu kehren.
Den Machenschaften dieses Konzerns muss meiner Meinung nach, sprichwörtlich "der Stecker gezogen werden". Ethisch unzweifelhaftes Verhalten sieht in meinen Augen anders aus.

 

[blöderidiot]

Aber deren Software prüft auf die ID und wenn die nicht auf Intel lautet, dann werden Features, die eigentlich vorhanden sind, nicht genutzt. Inwiefern soll das nicht Intels Schuld sein?

Ehrlich Leute, wie naiv hört sich das an. Das wurde hier schon 100 mal erwähnt und ignoriert, schon klar, aber ich wiederhole es noch mal: MKL ist eine von Intel für Intel-Prozessoren entwickelte (möglicherweise unter hohen Kosten) Bibliothek, um für Intel-Prozessoren eine hohe numerische Leistungsfähigkeit zu garantieren.
Mit welcher Begründung sollen die Intel-Entwickler irgendwelche nicht-Intel-Prozessoren daran teilhaben lassen? Wie erklärst Du das dem Management? Es gibt keinen Vertrag mit AMD, dass Intel seine selbstentwickelte und nicht quelloffene Bibliothek für AMD-Prozessoren freigibt. Dass AMD-Prozessoren diese Bibliothek dennoch de-facto weitgehend (ohne AVX) erfolgreich nutzten und auch weiter nutzen können - ist doch nett von Intel, oder? Wie @calluna weiter oben richtig erwähnt, bauen die (proprietären) Intel-compiler icc und icpc diese architekturabhängigen Codepfade auf. Mal andersherum betrachtet! Wenn AMD wollte, hätten sie mit Sicherheit einen Deal mit Intel diesbezüglich (AVX/AVX2) machen können. Hätte wahrscheinlich "gekostet". Wenn es eine Umgebungsvariable gibt, die MKL dazu bringt, AVX (=4) oder AVX2 (=5) immer zu verwenden, und das aber von MatWorks/Matlab nicht abgesegnet ist, kann das IMHO halt nur von Hobbyisten genutzt werden. Der "impact" dieser möglichen Nutzung dieser Umgebungsvariablen wird aber, wie @Ned Flanders gemerkt hat, sehr hoch sein - aus naheliegenden Gründen. Was MathWorks/Matlab betrifft, so vermute ich, dass (da seit Zen2 AMD endlich AVX2/256bit anbietet und die Beliebtheit von Zen im wissenschaftlich-technischen Bereich gestiegen ist) vielleicht ab Matlab R2020.A oder R2020.B eine Veränderung eintreten wird - und daran hat @Ned Flanders dann sicher einen Anteil, da er eine Lawine losgetreten hat, die zwar schon länger existierte aber erst jetzt ihre Kraft entfaltet

Außerdem läuft die MKL üblicherweise nicht auf Gaming-Systemen, daher weiß ich noch nicht ganz, was der ganze Aufschrei hier im Forum bedeuten soll?

 

[HaZweiOh]

aber ich wiederhole es noch mal

Nur machen es deine ständige Wiederholungen nicht besser. Wir befinden uns nicht im wilden Westen, sondern im Wettbewerbsrecht gegenüber einem Monopolisten. Das Wettbewerbsrecht ist zum Glück ein scharfes Schwert, wenn es konsequent angewendet wird. Ein Monopolist kann und darf einfach nicht mehr alles machen, was er will. Vor allem nicht künstlich den Wettbewerb sabotieren. Hätte er noch 10 gleich große Mitbewerber, würde die Sache schon anders bewertet werden. Ob du persönlich Intels Verhalten normal findest, oder nicht, ist da nicht relevant.

Eine Bibliothek ist dazu da, in verschiedenste Programme aller möglichen Hersteller eingebaut zu werden. Das ganze PC Ökosystem funktioniert nur, wenn und solange die einzelnen Bauteile zueinander kompatibel sind. Dafür ist auch keinerlei "Arbeit" bei Intel erforderlich.

Man beachte bei der folgenden Aufzählung das Wort "defective" anstelle von (wie du glaubst) "völlig normal" und "ist doch ihre Sache":

1. Intel provide them, at no additional charge, a substitute compiler that is not a Defective Compiler;
2. Intel compensate them for the cost of recompiling the software they had compiled on the Defective Compiler and of substituting, and distributing to their own customers, the recompiled software for software compiled on a Defective Compiler; and
3. Intel give public notice and warning, in a manner likely to be communicated to persons that have purchased software compiled on Defective Compilers purchased from Intel, of the possible need to replace that software.

Auch der 2. Satz hat es in sich.

 

[blöderidiot]

Das ganze PC Ökosystem funktioniert nur, wenn und solange die einzelnen Bauteile zueinander kompatibel sind. Dafür ist auch keinerlei "Arbeit" bei Intel erforderlich.

Die MKL ist kompatibel und wird auch erfolgreich und zuverlässig von AMD-Prozessoren benutzt. Nur eben nicht mit maximaler Performance. Das steht auch so in Wikipedia:

"Intel MKL and other programs generated by the Intel C++ Compiler improve performance with a technique called function multi-versioning: a function is compiled or written for many of the x86 instruction set extensions, and at run-time a "master function" uses the CPUID instruction to select a version most appropriate for the current CPU. However, as long as the master function detects a non-Intel CPU, it almost always chooses the most basic (and slowest) function to use, regardless of what instruction sets the CPU claims to support. This has netted the system a nickname of "cripple AMD" routine since 2009. As of 2019, MKL, which remains the choice of many pre-compiled Mathematical applications on Windows (such as NumPy, SymPy, and MATLAB), still significantly underperforms on AMD CPUs with equivalent instruction sets."

 

[yummycandy]

Die MKL ist kompatibel und wird auch erfolgreich und zuverlässig von AMD-Prozessoren benutzt. Nur eben nicht mit maximaler Performance. Das steht auch so in Wikipedia:

Ich zitiere dich mal:

Mit welcher Begründung sollen die Intel-Entwickler irgendwelche nicht-Intel-Prozessoren daran teilhaben lassen? Wie erklärst Du das dem Management? Es gibt keinen Vertrag mit AMD, dass Intel seine selbstentwickelte und nicht quelloffene Bibliothek für AMD-Prozessoren freigibt.

Das widerspricht sich etwas. Wenn schon freigeben, dann bitte auch alle von Intel lizensierten Erweiterungen. Oder eben nicht freigeben, dann müssen die Programmentwickler zwangsweise auf eine andere Lib ausweichen, bzw. beide benutzen.

 

[HaZweiOh]

Die MKL ist kompatibel

Künstlich verlangsamt => qualitativ schlechter

Das steht auch so in Wikipedia.

Wow, Wikipedia , aber das ändert nix am Problem. Du hast in der Hinsicht eine ziemlich seltsame Rechtsauffassung.

 

[blöderidiot]

Das widerspricht sich etwas. Wenn schon freigeben, dann bitte auch alle von Intel lizensierten Erweiterungen. Oder eben nicht freigeben, dann müssen die Programmentwickler zwangsweise auf eine andere Lib ausweichen, bzw. beide benutzen.

Formal sind AMD-Prozessoren von Intel für die MKL-Nutzung "unsupported":

"Key Specifications

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

De-facto verhindert Intel auch nicht, dass AMD-Prozessoren laufen. Dass Matlab, SciPy etc. trotzdem die MKL nutzen, wirft Fragen auf.

 

[Benji18]

Ehrlich Leute, wie naiv hört sich das an. Das wurde hier schon 100 mal erwähnt und ignoriert, schon klar, aber ich wiederhole es noch mal: MKL ist eine von Intel für Intel-Prozessoren entwickelte (möglicherweise unter hohen Kosten) Bibliothek, um für Intel-Prozessoren eine hohe numerische Leistungsfähigkeit zu garantieren.
Mit welcher Begründung sollen die Intel-Entwickler irgendwelche nicht-Intel-Prozessoren daran teilhaben lassen?

du gehst davon aus das die MKL zusätzliche "optimierungen" für Intel CPUs enhält, warum funktioniert die MKL dann trotzdem auf "none Intel CPUs"? Warum schlägt intel großen Techmagazinen vor doch MKL Tests in ihren Testparkour aufzunehmen?

Intel hat Befehlsatzerweiterungen wie MMX od. SSE und auch AVX als "Standard Entwickelt und diesen Standard hat AMD Lizensiert somit ist aufgrund dessen davon auszugehen das dieser auf allen CPUs gleich rechnet. Die MKL so wie ich das verstanden habe ist nichts anderes als eine Libary damit Programme bzw. Entwickler einen fertigen Baustein haben um auf diese Befehlssatzerweiterungen zuzugreifen damit die Berechnungen schneller abgearbeitet werden.

Hier absichtlich eine "bremse" einzubauen ist manipulativ ins besondere wenn man Techmagazine dazu auffordet diese in Testparkours einzusetzen, das verfälscht das Bild.

Entweder Intel macht die MKL Intel only od. eben für alle CPUs gleich nutzbar alles andere hat mit für Intel "optimiert" nix zutun.