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

[gustlegga]

Er hat aber Recht mit der Feststellung, das die Handoptimierung der MKL für AVX erfolgt ist, bevor es eine AmD CPU gab, die das implementiert hat - so wie es jetzt bei AVX512 der Fall ist.

Dann hätte man alternativ aber auch ein Fallback auf eine der SSE4 Iterationen verwenden können, statt der steinalten Version 2.
Ein P4/Athlon64 wird wohl nicht mehr in Produktivsystemen stecken die mit solcher Software laufen.

Intel hat früher oft ein Geschäftsgebahren an den Tag gelegt, welches ich verachte, aber bei der MKL sehe ich eben keine moralische Verpflichtung anders zu handeln, weil es ganz offensichtlich, siehe Intel-Website, ein propritäres Produkt ist, welches niemand ohne Intel CPU verwenden sollte.

Ich kauf der latent kriminellen blauen Bude (abgesehen vom SoC in meinem Tablet) zumindest für meine privaten Systeme seit 20Jahren nichts mehr ab, aber stimme ich dir voll zu, dass es nicht die Aufgabe eines Herstellers proprietärer Software ist die Kompatibilität für den Mitbewerber zu gewährleisten..
Wenn dann wäre halt konsequent gewesen generell keine AMD-CPUs zu unterstützen.
Solange das in den Whitepapers/Systemrequirements ausführlich dokumentiert ist sollte das auch kein Problem sein.
(Die Software die ich beruflich verwende - PaletteCAD - empfiehlt für den 3D-Renderer auch nur GPUs von nVidia, trotzdem läuft das auch auf meiner R9-380, da halt dann nur in OpenGL und ohne Support vom Softwarehersteller)
So kann Intel natürlich sagen: Seht her, wir unterdrücken ja nicht, es läuft ja auf AMD.
Das ich das Vorgehen auch nicht pricklend sondern moralisch zumindest zweifelhaft finde, und man auch einfach die Flags der Befehlssätze hätte abfragen können, ist ein anderes Thema.
Das kriegen ja sogar Freeware Tools wie CPU-Z hin.
Aber wie gesagt, ist es eigentlich nicht Intel´s Aufgabe.
Und wenn der Mitbewerber deutlich schlechter dasteht ist das ja auch dem Marketing förderlich.

Für gewöhnlich wissen Menschen, die Numpy verwenden, ob sie das betrifft... da du diese Frage stellst, betrifft es dich nicht...

Hihihi

...ebenso wie alle anderen die nichts mit wissenschaftlichem Rechnen zu tun haben... also betrifft es 99% der Nutzer nicht.

Dafür strotzt der Thread wieder vor Rechtsexperten. Ist ja auch was wert ^^
Mir fällt hier schon wieder viel zu oft das Wort "illegal", "Schmiergeld" etc..

Nehmen wir einen Autovergleich,

Nein! Bitte nicht.....

Ich liebe es wie hier im Forum wieder die fetzen fliegen! Ach ist das spannend! Auf die 12e

Jupp, wieder jede Menge 🍿 nötig.
Ich verkürz mir hier aber auch nur die Wartezeit aufs NFL Monday Night Game. 🏉

 

[Wadenbeisser]

@Creeed

Das nicht aber irgendwer muss den Rechner ja auch bezahlt haben und solche Spielchen macht man vor allem um die Preise hoch zu halten.

Der Kunde bezahlt mehr als er bei einem gesunden Wettbewerb müßte -> die Nummer geht wort wörtlich auf seine Kosten.

 

[D2490nm4573r]

Das steht halt dort nicht. Was Intel nicht machen darf ist, dritten Softwareanbietern vorzuschreiben wie die Software auf nicht Intels CPUs laufen soll. Wer die Intel Bibliotheken nutzt tut das freiwillig und hat jedes recht andere Bibliotheken für andere CPUs zu nutzen.
...

Es steht dort eben schon,

Intel shall not include any Artificial Performance Impairment in any Intel product .... As used in this Section 2.3, "Artificial Performance Impairment" means an affirmative engineering or design action by Intel ... that (i) degrades the performance or operation of a Specified AMD product

den auch das schreiben von code ist "engineering" und demnach ist das absichtliche nicht nutzen von AVX2 eben eine solche "affirmative engineering action by Intel that degrades the performance or operation of a Specified AMD product".

Dieser part steht ja auch nur deshalb in dem Agreement weil Intel eben damals das gleiche mit ihrem C++ Compiler gemacht nur das es die SSE Befehlssatzerweiterungen waren die Intel damals deaktiviert hat wenn bei der Abfrage der VendorID heraus kam das es sich nicht um einen Intel Prozessor handelte.

 

[MaverickM]

ganz im ernst, das ist jetzt nicht wirklich intels schuld, sondern matlabs.

Eher 50/50. Intel ist Schuld, weil sie absichtlich die Bibiliothek so programmiert haben, dass alles außer Intel schlechter dasteht. Und die Entwickler von Matlab, weil sie den Schmu als Basis verwenden, ohne eigenen Code nachzuschieben, bzw. diese Eigenheit abzuschalten. Man kann nur hoffen, dass die Entwickler einsichtig sind, und in einer neuen Programmversion den Workaround standardmäßig einbauen.

 

[eRa84]

Kann mir das mal einer genauer übersetzen? Wann wird denn diese Intel Bibliothek benutzt? Ist diese mathlab gedöns bei allen Anwendungen aktiv oder wie kann ich mir das jetzt vorstellen?

 

[Nureinnickname!]

Krass dass die wenigsten hier Raffen worum es eigentlich geht ^^, lesen ist wohl nicht deren stärke

 

[konkretor]

Dann mach ich heute mal nen Ticket auf bei Mathworks und Frage freundlich nach. Mal sehen was sie antworten

 

[Bard]

Die gleiche Geschichte gibts doch auch bei nVidia mit PhysiX.

Sobald man PhysiX über die CPU berechnet, verwendet es nur einen Thread.
Sobald man es über die GPU berechnet sinds plötzlich 100 bis zu 1000 Threads.

Ein Schelm wer sich dabei was denkt.


Leider kann man da auch nicht viel dagegen tun, solange die Industrie/Firmen/etc. darauf beharren, diese Closed Formats zu verwenden, statt da von Anfang an "nein" zu sagen und nur auf Open Source zu setzen.

 

[Foxley]

unseriös Intel. die Energie wäre in gewissen anderen Dingen besser aufgehoben.Genau so schlimm wie der Verkaufsskandal(Deal) wo es in Elektrofachmärkten nur Intel Produkte zu kaufen gab.Einfach nur unfairer Wettbewerb.Aber wenn die eigene Leistung nicht mehr ausreicht wird halt betrogen durch die Blume.

 

[yummycandy]

Der Einwand zu Matlab ist schon richtig. Wenn sie es ernst genommen hätten mit der AMD Unterstützung, würden sie auf OpenBLAS + MKL setzen. Das soll allerdings die Kontroversen um die MKL an sich nicht schmälern. Schließlich wird diese ja auch von vielen anderen Projekten eingesetzt. Aber wahrscheinlich ist vielen Progammiern diese Unterscheidung nach Anbieter einfach zu aufwendig, denn sie müßten das auch supporten. Dazu kommt noch der geringere Marktanteil von AMD, was sich allerdings weiter verändern kann.

 

[calluna]

Du glaubst doch wohl nicht ernsthaft dass einer Derjenigen, die hier Intel bis aufs Messer verteidigen, sich einen AMD-Rechner unter den Tisch stellen werden.

Da irrst du dich gewaltig, denn OpenBLAS ist ja nicht so viel schlechter als die MKL... und die vielen Kerne bei AMD gleichen das bestens aus... denn alles, wofür man Numpy, Dask etc. verwendet, skaliert bestens mit der Kernzahl. ;-)

Wenn ich Hardware brauche, wird das rational entschieden und nicht nach Gefühl.

 

[catch 22]

Verstehe den Shitstorm hier gegen Intel (ausnahmsweise) nicht. Intel ist Entwickler und Maintainer der Math Kernel Library. Ich optimiere meine Software doch nicht für Konkurrenzprodukte, dafür würde ich auch keinen müden Cent aufwenden als Unternehmen.
...

Es verlangt ja auch niemand von Intel eigene Software Produkte für andere zu optimieren. Es reicht vollkommen aus, lediglich keine Bremsen für andere Hardwarehersteller einzubauen. denn das ist geschehen.

Dazu nochmal die essentiellen Stellen aus dem Artikel

Mehr Leistung per Batchdatei
Die Lösung ist ein simpler vierzeiliger Code in einer Batch-Datei den der Autor ebenfalls im Reddit-Forum veröffentlicht hat.

und

Standardmäßig fragt die Intel Math Kernel Library die Vendor-ID-Zeichenfolge des genutzten Prozessors ab. Wenn eine andere Zeichenfolge als „GenuineIntel“, wie beispielsweise „AuthenticAMD“, ausgelesen wird, greift die Bibliothek in einer Art Fallback-Modus auf gewöhnliches SSE zurück, ohne die von der CPU real unterstützten Befehlssatzerweiterungen zu beachten, was einen erheblichen Leistungsnachteil für Prozessoren vom Typ AMD Ryzen mit ihrer vollen SSE4-, AVX- sowie AVX2-Implementierung mit sich bringt.

Der Workaround zwingt Intels Programmbibliothek dazu, unabhängig vom Ergebnis der CPU-Vendor-ID-Abfrage, AVX2 zu verwenden.

 

[BosnaMaster]

@catch 22 ich sehe eigentlich auch nicht wo das Problem ist, frage ob es mein Prozessor ist, wenn ja dann so denn ich weiss was mein Prozessor kann, und für den Rest bitte Standardprogramm.

Eigentlich völlig normal für mich, AMD soll doch selber beim Entwickler anklopfen, oder ist dass auch Intels Aufgabe?

Ich verstehe die grosse Aufregung echt nicht und in letzter Zeit ist eh so, dass es Mode ist Intel ans Bein zu Pinkeln...

Das erläuterte Szenario gibt es aber schon ewig und ist sicher nicht neu. Ich als Hersteller schei.. drauf ob es AMD, nVidia oder Intel ist, stelle Entwicklern sahen zur Verfügung, und soll noch schauen dass die Konkurrenz gut dasteht und die volle Leistung abruft. lol

 

[MaLow17]

Die gleiche Geschichte gibts doch auch bei nVidia mit PhysiX.

Sobald man PhysiX über die CPU berechnet, verwendet es nur einen Thread.
Sobald man es über die GPU berechnet sinds plötzlich 100 bis zu 1000 Threads.

Leider kann man da auch nicht viel dagegen tun, solange die Industrie/Firmen/etc. darauf beharren, diese Closed Formats zu verwenden, statt da von Anfang an "nein" zu sagen und nur auf Open Source zu setzen.

1. Es heißt PhysX.
2. Unterstützt PhysX seit dem SDK 3.0 SSE und Multithreating, siehe z.B. Borderlands 2.
3. Ist PhysX seit dem SDK 4.0 nicht nur für CPUs, sondern auch für GPUs quelloffen, siehe Nvidia PhysX: Ab sofort komplett Open-Source und in Version 4.0 verfügbar

 

[Bard]

1. Es heißt PhysX.
2. Unterstützt PhysX seit dem SDK 3.0 SSE und Multithreating, siehe z.B. Borderlands 2.
3. Ist PhysX seit dem SDK 4.0 nicht nur für CPUs, sondern auch für GPUs quelloffen, siehe Nvidia PhysX: Ab sofort komplett Open-Source und in Version 4.0 verfügbar

Ja, aber alles erst nach 10 Jahren.

 

[Rockstar85]

Ja, aber alles erst nach 10 Jahren.

Ist aber auch eine konsequenz auf Grund des Marktdrucks, und ich rede hier von Big blue

 

[yummycandy]

@BosnaMaster Nochmal, es geht darum, daß Intel eine Featureabfrage macht (also AVX, SSE usw.) und zusätzlich eine Herstellerabfrage. Wenn sie sowieso Features abfragen, warum wird dann für Intel-fremde CPUs nicht auf die vorhandenen Features, sondern auf SSE gestellt? Wäre keinerlei Optimierung, sondern
nur ne normale Abfrage.

Ein anderer legitimer Weg wäre die komplette Ignorierung fremder CPUs, die damit dann gar nicht mit der MKL laufen würden. Dann müßten die Entwickler standardmäßig zusätzlich OpenBLAS einsetzen.

 

[HaZweiOh]

ich sehe eigentlich auch nicht wo das Problem ist
Intel soll noch schauen, dass die Konkurrenz gut dasteht
LOL

Unsinn, ließ doch mal die Beiträge! Es wurde doch schon 100 Mal gesagt, dass es hier gar nicht um "Optimierung" geht, sondern um gezielte Behinderung.

 

[Ned Flanders]

Dann mach ich heute mal nen Ticket auf bei Mathworks und Frage freundlich nach. Mal sehen was sie antworten

Ja bitte! Und jeder AMD Matlab User sollte das tun! Vielleicht ändert sich auf diese Weise etwas.

Gruss, Ned

 

[AMDprayer]

Eher 50/50. Intel ist Schuld, weil sie absichtlich die Bibiliothek so programmiert haben, dass alles außer Intel schlechter dasteht. Und die Entwickler von Matlab, weil sie den Schmu als Basis verwenden, ohne eigenen Code nachzuschieben, bzw. diese Eigenheit abzuschalten. Man kann nur hoffen, dass die Entwickler einsichtig sind, und in einer neuen Programmversion den Workaround standardmäßig einbauen.

Du kannst als Entwickler nicht das Rad immer neu erfinden. Man ist gezwungen Bibliotheken zu verwenden um sein Ziel zu erreichen und muss darauf vertrauen, dass sie funktionieren wie sie sollen ohne den kompletten Code nochmal zu sichten. Ich wette dem Matlab-Entwicklern war dies gar nicht bewusst. Jetzt wo das bekannt ist, müssen sie natürlich handeln.