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

DocWindows schrieb:
Kleines Suchspiel. Irgendwo hier ist der Vendorstring versteckt. Wer findet ihn zuerst? :D
suchspiel.png

Was war nochmal der erste Preis? :evillol:
 
@Zero_Point Ehre und der Respekt der Community. Das muss reichen :schluck:

nille02 schrieb:
Man könnte sich das File auch mal mit Ghidra anschauen. Wäre interessant ob es eine Feature Tabelle nutzt pro Generation oder nur ein Vendor Check gemacht wird und dann dennoch jedes Feature geprüft wird.

Es nutzt die Funktion cpuid um die erweiterten Features der CPU auszulesen. Aber nur wenn eine Intel CPU verbaut ist (Vendor Check). Ansonsten wird das kleinstmögliche Featureset angenommen.

Hier ist eine Doku zu der Funktion von AMD. Was AVX2 angeht, kannst du auf Seite 59/60 sehen, dass das 5.Bit des EBX CPU-Registers auf 1 steht, wenn man über cpuid den Funktionsblock 7 abruft. Das ist bei Intel ganz genauso. Würde die MKL diesen Funktionsblock bei Intel und AMD CPUs abrufen, würde bei AMD auch AVX2 funktionieren. Tut sie aber nicht. Das passiert nur wenn eine Intel-CPU verbaut ist.
Was verbaut ist, bestimmt der Vendor ID String der aus 3 32Bit Blöcken besteht.
Sie werden auch über cpuid gefüllt, wenn man den Funktionsblock 0 abruft. Die 3 CPU-Register EBX, ECX und EDX enthalten dann den String AuthenticAMD oder GenuineIntel. Siehe hierzu Seite 56.

Ich würde ja hier die disassembly dazu zeigen, aber ich weiß nicht ob man das rechtlich darf. Nicht nur seitens Intel, sondern auch seitens Computerbase.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: konkretor und Zero_Point
SV3N schrieb:
dass ihre Software mit um bis zu 400 Prozent geminderter Leistung auf AMD-Prozessoren läuft?
Bitte nochmal das Algebra-Kapitel über Prozentrechnen im Schulbuch nachschlagen. ;)
Es sind ~75% langsamer.
Eine AMD Cpu kommt im Worst-case auf etwa ein Viertel der Intel-CPU.
(Wert differiert je nach CPU bzw getesteter Operation)
Ergänzung ()

DocWindows schrieb:
Kleines Suchspiel. Irgendwo hier ist der Vendorstring versteckt. Wer findet ihn zuerst? :D
Du hättest es etwas schwieriger machen können, wenn du nur den HEX-Code gepostet hättest. :D
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Sombatezib, Zero_Point und SVΞN
@gustlegga Ich könnte ja eine gepatchte MKL als Hexcode im JPG-Format posten. Zum selber abtippen wie damals zu C64 Zeiten. Sind ja nur 70 Megabyte, also wie lange kann das dauern abzutippen? 1-2 Jahre maximal :evillol:
 
  • Gefällt mir
Reaktionen: konkretor, SVΞN und gustlegga
corvus schrieb:
Das ist mir sogar nun neu, hast evtl. eine Quelle dazu? Ging komplett an mir vorbei. Obwohl ich SC2 ausschließlich auf AMD gezockt habe.

originalpost:

http://realmofespionage.blogspot.com/2015/01/starcraft-ii-cpu-benchmarking-with-amd.html

aufbereitung:

https://www.reddit.com/r/AdvancedMi...amd_mythbusters_sc2_framerates_and_the_intel/

angeblich wurde hier seitens blizzard mittlerweile gepatcht; ich konnte dafür aber nirgends einen tatsächlichen hinweis finden.

für wow gibts ähnliche beobachtungen:

https://us.battle.net/forums/en/wow/topic/4079871855


das ganze müsste man jetzt mal mit zwei vergleichbaren amd/intel rechnern neu benchen, damit man "über kreuz" die daten vergleichen kann.


das hier ist auch noch eine recht witzige angelegenheit:

https://www.reddit.com/r/Amd/comments/6lej62/amd_benchmarks_being_alternated_shown_by_spoofing/

das ist übrigens immer noch aktuell - ihr müsst die "device type" auswahl auf CPU reduzieren:

https://compubench.com/result.jsp?benchmark=compu15d

da stehen intel ryzen ziemlich weit oben in der liste.


schon 2008 ist das ganze bei ars technica im via nano benchmark aufgefallen, als pcmark 05 getestet wurde. via cpus können einfach die vendor id ändern, und mit jeder änderung der ID hat sich die performance verändert, vorallem wenn das ding auf einmal eine intel cpu war.

https://arstechnica.com/gadgets/2008/07/atom-nano-review/6/


dazu ein blog post aus 2009:

https://www.agner.org/optimize/blog/read.php?i=49&v=t
 
  • Gefällt mir
Reaktionen: konkretor, Tapion3388, stolperstein und 3 andere
duskstalker schrieb:
originalpost:

http://realmofespionage.blogspot.com/2015/01/starcraft-ii-cpu-benchmarking-with-amd.html

aufbereitung:

https://www.reddit.com/r/AdvancedMi...amd_mythbusters_sc2_framerates_and_the_intel/

angeblich wurde hier seitens blizzard mittlerweile gepatcht; ich konnte dafür aber nirgends einen tatsächlichen hinweis finden.

für wow gibts ähnliche beobachtungen:

https://us.battle.net/forums/en/wow/topic/4079871855

Vielen Dank, schaue ich mir heute Abend mal durch.
 
https://www.agner.org/optimize/blog/read.php?i=49&v=t

hab ich auch entdeckt, sehr interessant :-)
Ergänzung ()

DocWindows schrieb:
@gustlegga Ich könnte ja eine gepatchte MKL als Hexcode im JPG-Format posten. Zum selber abtippen wie damals zu C64 Zeiten. Sind ja nur 70 Megabyte, also wie lange kann das dauern abzutippen? 1-2 Jahre maximal :evillol:
Hängt von den Anschlägen pro Jahr ab. Oha, schlechte Wortwahl und Satzbau. Sorry.
 
Zuletzt bearbeitet: (Doppeldeutigkeit)
DocWindows schrieb:
@gustlegga Ich könnte ja eine gepatchte MKL als Hexcode im JPG-Format posten. Zum selber abtippen wie damals zu C64 Zeiten. Sind ja nur 70 Megabyte, also wie lange kann das dauern abzutippen? 1-2 Jahre maximal :evillol:
Ich meine so, du hättest in deinem Screenshot nur den HEX-Dump stehen lassen sollen, ohne den hinteren Bereich. ;)

C64 Zeiten? Oh ja diese Seitenlangen MSE-Listings in der 64er...
 
gaelic schrieb:
Funktioniert die environment variable auch unter Linux. Ich und meine Kollegen nutzen zuhauf Numpy und GAMS/gurobi und sind hier sicherlich massiv betroffen.

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?

Hast du noch nie getestet, wie gut ein Algorithmus funktioniert mit Numpy, CuPy, Dask... oder Numba?

Vielleicht hast du auch gar kein BLAS und LAPACK installiert.

Ich kann dir sagen... wenn du bestimmte Details nicht weißt, wirst du ohnehin nicht die Leistung haben, die du haben könntest, egal ob mit Intel oder AMD und mit oder ohne MKL.

Aber da liegt eben der Unterschied zu Matlab, dort sollten technische Details, die man bei der Verwendung mit Numpy und Co. wissen sollte, dem Nutzer verborgen bleiben.

Davon abgesehen... hat hier überhaupt jemand einmal mit einer aktuellen Matlab Version überprüft, ob das alles stimmt? Ich habe auf Arbeit nur R13b und nutze es schon lange nicht mehr. Und zur Zeit von R13b war AMD keine Alternative im Gegensatz zu jetzt.
 
Zuletzt bearbeitet:
Hallo32 schrieb:
Was für ein Test kommt denn im Zusammenhang mit OpenBLAS?

Aus meiner Sicht ideal wäre es mit numpy den Pudget Systems Benchmark nach zu kochen und zusätzlich eben noch die MKL mit Workaround zu nehmen. Als quasi MKL vs MKL-W vs OpenBLAS.

Da ich aber ein Fachidiot und dazu nicht in der Lage bin suche ich noch freiwillige Helfer im Sammelthread.
 
Wadenbeisser schrieb:
Da ging es wohl eher darum dass das GPU beschleunigte PhysX bei der Konkurrenz nicht nur auf die CPU ausgelagert sondern auch noch auf einen Kern begrenzt und mit hoffnungslos veralteten FPU Code betrieben wurde.

Mir ist schon klar worum es da ging. Allerdings hatte ich nicht zuende gedacht, NVIDIAs CPUs gibt es ja nur mit integrierter GPU, daher ergibt meine Frage keinen Mehrwert für die Diskussion. Sorry, war ein Versuch die Perspektive zu wechseln der nichts gebracht hat.
Ergänzung ()

gimmix schrieb:
Bitte nochmal für die Nicht-Mattlab-User unter uns:

1) Hat die Vendor-ID-Abfrage irgendeinen Sinn

Ja, sie hat wie Du selbst bemerkt/vermutet hast aller Wahrscheinlichkeit nach den Sinn

dass Intel keine Produkthaftung für Fremdhersteller übernehmen will

Gern geschehen.
 
Zuletzt bearbeitet:
D2490nm4573r schrieb:
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
Es steht dort eben schon,

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".[...]

Och Keule, du lässt in deinem Zitat doch aber gerade die wesentlichen Einschränkungen weg. Intel darf nicht aktiv den Wettbewerb verhindern indem sie Nachteile für ihre Wettbewerber aktiv entwickeln / in ihre Produkte einbauen. Genauso darf Intel Dritte nicht dazu bringen eben dies zu tun. Im Zweiten Absatz von 2.3 steht dafür aber genauso klar, dass eben dieser Punkt NICHT dazu führen darf, dass Intel gezwungen wird ihre Produkte für ihre Wettbewerber optimieren muss.
Dem Kommt Intel sauber nach. Bibliotheken und Compiler optimieren fröhlich auf neure Intel CPUs und alles andere nutzt einen Default der nicht viel mehr nutzt als SSE2 (was glaub auch der Default vom GCC und VisualC Compiler ist, solang man keine spezfischen Architekturen bzw. Featuresets angibt). Mit diesem Default laufen erzeugte Binaries dann auf allen CPUs bis hinunter zum Intel P4, AMD Athlon 64/XP und Via C3. Was Intel jedoch nicht macht ist den Wettbewerb aktiv einzuschränken. Dazu müsste man nachweisen, dass Intels Software auf nicht Intel CPUs sinnlose Loops / Sprünge einbaut. Dem ist aber wohl eher nicht so, denn ein Intel P4 und ein Ryzen CPU nutzen genau die selben SSE2 Code.

Seite 6 Punkt 2.3
http://download.intel.com/pressroom/legal/AMD_settlement_agreement.pdf
Ergänzung ()

SV3N schrieb:
@DocWindows die Frage die sich mir stellt und die man vielleicht ganz allgemein mal stellen sollte, warum existiert ein solches Problem seit 10 Jahren und warum unternimmt niemand etwas dagegen?
Es wird nix dagegen unternommen, weil es legal ist. In System mit freier Wirtschaft kann man Marktteilnehmer nicht dazu zwingen für die Konkurenz zu entwickeln.

Weshalb akzeptieren Unternehmen wie MathWorks, dass ihre Software mit um bis zu 75 Prozent geminderter Leistung auf AMD-Prozessoren läuft? Zumal der Workaround den Ned Flanders hier ,wohlgemerkt als absoluter "Non-IT-Professional", präsentiert hat, so einfach wie simple ist?

Weshalb das so ist und zwar nicht nur bei Matlab/MathWorks, sondern bei so gut wie allen Softwarelösungen die auf MKL basieren, darüber darf sich gerne jeder sein eigenes Bild machen. Keine der betroffenen Firmen wollte also, dass seine Software abseits von Intel-CPUs performant läuft? Das lass ich dann mal so stehen.
Die Mathebibliotheken von Intel sind in Bezug auf Leistungsumfang, Performance und liberaler Lizenzierungsmodell recht allein am Markt.
Die Entscheidung ist also bei Mathlab: Entweder die schnellste Mathebibliothek nehmen und Intel Systeme bevorzugen oder allen Kunden 10-50% schlechtere Performance liefern.
Das Mathlab nicht von sich aus an den Bibliotheken herumfummelt hat einen ganz gewichtigen Grund: VERLÄSSLICHKEIT

Wenn die Bibliotheken den Codepfad für Haswell (oder später) einschlagen, dann ist es recht wahrscheinlich, dass irgendwo im CODE ein paar BMI 1/2 Instruktionen vorkommen. Haswell kann eben diese Befehle sauber abwickeln, bei AMDs Excavator Architektur (erste AMD Arch mit AVX2) rennst man damit in Ausnahmefehler.
Was du forderst, ist also, dass Matlab Software auf den Markt wirft, die dicke Benchmarkbalken liefert aber im Zweifelsfall halt auch kritische Fehler wirft. Das sind auch genau die Anforderungen in dem Bereich, wo Mathlab zur Anwendung kommt..


Das Intel LegitReviews in der letzten Woche sogar vorgeschlagen hat, Matlab als Benchmark für CPU-Leistung zu nutzen, muss man wohl auch nicht weiter kommentieren. ;)

"Last week @Intel suggested that we take a look at MATLAB workloads for CPU testing!", LegitReviews
Nüchtern betrachtet, wenn man Intel CPUs kauft, kauft man eben auch die Softwareunterstützung mit. Das man das als Anbieter gern mit beworben haben möchte ist logisch.

Problematisch wird es eigentlich erst, wenn auf der Seite des Journalismus die Kompetenz nicht ausreicht um das alles für Leser / Konsumenten ordentlich einzuordnen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: BosnaMaster, gustlegga und Hayda Ministral
Dai6oro schrieb:
Was ich aber schon wieder geil finde ist, dass Intel legitreviews vorgeschlagen hat MATLAB fürs CPU testing zu nehmen. Ein dickmove von der Firma nach dem anderen. Alles! was dieser Verein vorschlägt sollte 2x-3x geprüft und im Zweifelsfalle nicht verwendet werden.
Können Sie ja jetzt machen, mit Neds Rework.

DocWindows schrieb:
@gustlegga Ich könnte ja eine gepatchte MKL als Hexcode im JPG-Format posten. Zum selber abtippen wie damals zu C64 Zeiten. Sind ja nur 70 Megabyte, also wie lange kann das dauern abzutippen? 1-2 Jahre maximal :evillol:
Spielverderber
Ich hab aber FineReader :p
 
  • Gefällt mir
Reaktionen: gustlegga
Piktogramm schrieb:
Es wird nix dagegen unternommen, weil es legal ist. In System mit freier Wirtschaft kann man Marktteilnehmer nicht dazu zwingen für die Konkurenz zu entwickeln.

Ich rede davon, weshalb niemand auf die Idee gekommen ist, eine vierzeilige Batch-Datei zu schreiben, wie es @Ned Flanders getan hat! Wenn man damit die Performance auf AMD-CPUs so signifikant verbessert, ist es mir unerklärlich weshalb das in 10 Jahren niemand vollbracht oder zumindest versucht hat.
 
  • Gefällt mir
Reaktionen: Argoth, Celinna, McTheRipper und 8 andere
Summerbreeze schrieb:
Können Sie ja jetzt machen, mit Neds Rework.
Als ob dieser "Fix" nicht schon vorher bekannt war. Der Aufwand liegt doch nicht daran ein paar Parameter zu ändern sondern sicher zu stellen, dass die entsprechenden Codepfade auch auf AMD CPUs immer exakt die gewollten Ergebnisse liefern und unter keinen Umstand (zusätzliche) Fehler provozieren. Wobei das perspektifisch auch auf alle kommenden Versionen der MKL zutreffen muss.
 
Piktogramm schrieb:
Als ob dieser "Fix" nicht schon vorher bekannt war.
Er scheint ja wohl zumindest nicht allgemein bekannt gewesen zu sein. Irgendeine verstaubte Forenseite zähle ich jetzt mal nicht. Jetzt kann sich jedenfalls so leicht niemand mehr heraus reden. "Hab ich nicht gewusst."
Jetzt wird sich auf jeden Fall etwas dauerhaft ändern.
 
@SV3N

Wie kommst du darauf, dass das niemand getan hat?
Es gibt auch noch andere Flags in der MKL und OpenBLAS die man in bestimmten Situationen setzen muss, wie die Anzahl in Threads=1 in Verbindung mit Python Dask.

Der Punkt ist, und das wurde hier auch schon angesprochen, dass jeder die MKL auf eigene Gefahr außerhalb der Spezifikation verwendet - ubd das sollte man auf Arbeit nicht tun, wenn es sich nicht um unkritische Berechnungen handelt.

Da ist es besser zu ATLAS oder OpenBLAS zu greifen. Und in Verbindung mit Python Dask sollte die neue AMD CPU mit den vielen Kernen jede preislich vergleichbare Intel-CPU hinter sich lassen.

Matlab ist ein anderes Thema... und da hat hier niemand mit einer aktuellen Version die Behauptungen überprüft.
Davon abgesehen würde ich Cuda mit Matlab verwenden, wenn ich noch damit arbeiten müsste.

@Summerbreeze

Ach komm... ich bin mir sicher, dass fast alle, die sich hier darüber aufregen, weder Matlab noch Numpy verwenden bzw. etwas mit Numerik zu tun haben.
 
Zuletzt bearbeitet:
Zurück
Oben