Anwendungen mit Intel MKL lassen AMD-CPUs oft schlecht darstehen

[fortunes]

Nö, wird eine CPU != IntelGenuine erkannt, werden weitere Prüfungen nicht getriggert, großer Unterschied.

Du bist ja schlimmer als ein Kleinkind.

"Intel schaltet das ab."

"Nein, Intel schaltet das gar nicht erst ein!"

Du machst dich sowas von lächerlich und merkst es nicht.

Dann meinetwegen so: Intel prüft, ob Intel vorhanden ist. Wenn nein, dann werden die AVX-Prüfungen, die auf Intel-CPUs laufen, nicht aktiviert.

Und warum? Um die anderen CPUs zu benachteiligen. Denn die Featuresets sind die gleichen, egal ob Intel oder AMD.

 

[Holzmann]

@fortunes

Lass es, es hat keinen Sinn, einige wollen einfach nicht differenzieren bzw. nicht begreifen, denn wo Verstand und Moral aussetzt, regiert der ******* zensiert

 

[dimi0815]

Moralisch natürlich diskutabel und alles andere als astrein.

Aber ist das in 2019 noch einen Shitstorm wert, nachdem man von Holzkarten über langsam angebundene 0,5GB RAM und das Überschreiten von zB PCIe-Spezifikationen bis hin zu nicht erreichten Boosttaktraten oder auf magische Weise erreichte 5GHz auf drölfzig Kernen mit unrealistischen Kühlmöglichkeiten so ziemlich alles gesehen hat?

Hier wird dem Kunden immerhin nichts direkt unter Vorspiegelung falscher Tatsachen verkauft, oder?

Wenn ich als Interessent weiß, dass ML die Intel Lib nutzt und ebenso, dass Intel nur die eigenen CPUs vollumfänglich supportet, darf ich mir doch angesichts der Werbung von Intel mit ML auch meine eigenen und unabhängigen Gedanken dazu machen, ob die Aussagen zu 100% objektiv und vor allem für mich zuverlässig getroffen worden sind.

So mündig sollte doch jeder sein, der eine beliebige Entacheidung (hier mglw. Kaufentacheidung) trifft. Nein?

Ich kaufe doch auch kein AXE Deodorant und beschwere mich dann darüber, dass - trotz Werbung - mir nicht urplötzlich fremde Damen die Kleider auf der Straße vom Körper reißen.

 

[sch4kal]

Du bist ja schlimmer als ein Kleinkind.

"Intel schaltet das ab."

"Nein, Intel schaltet das gar nicht erst ein!"

Jup, Ersteres wäre eine absichtliche Benachteiligung, Letzteres könnte auch einfach nur "Faulheit", im Sinne nicht dafür verwendeter Ressourcen, sein.

Du machst dich sowas von lächerlich und merkst es nicht.

Komisch nur, das du deine Ansicht hier ständig alleine verteidigen musst.
Ich wiederhole mich hier, aber, du hast scheinbar nix mit SW-Entwicklung, und noch viel weniger mit HPC-Software am Hut und gibst hier deine Meinung zum Besten.
Argumentativ wurdest du schon diesbezüglich in anderen Threads von jdl, zu dessen täglich Brot das HPC-Umfeld zählt, in der Luft zerrissen.

Dann meinetwegen so: Intel prüft, ob Intel vorhanden ist. Wenn nein, dann werden die AVX-Prüfungen, die auf Intel-CPUs laufen, nicht aktiviert.

Nicht nur AVX, man nimmt dann einfach die "Baseline", den kleinsten gemeinsamen Nenner, was laut Intel Dev wohl SSE2 war/ist.

Und warum? Um die anderen CPUs zu benachteiligen. Denn die Featuresets sind die gleichen, egal ob Intel oder AMD.

Nochmal, da dein Hirn hier etwas hinten dran zu sein scheint, Intel kann es fucking egal sein, ob andere CPUs durch die EIGENE Lib benachteiligt werden.
Zwingt dich niemand, die MKL zu nutzen, zwingt dich auch niemand, Matlab zu nutzen, oder Mathworks zu rügen, warum sie keine andere Lib einbinden, die AMD CPUs nicht benachteiligt.

- - - Updated - - -

@fortunes

Lass es, es hat keinen Sinn, einige wollen einfach nicht differenzieren bzw. nicht begreifen, denn wo Verstand und Moral aussetzt, regiert der ******* zensiert

Das sagt ja gerade der Richtige.

Wirst du nicht von AMD bezahlt/vergütet ?

 

[Tzk]

Jup, Ersteres wäre eine absichtliche Benachteiligung, Letzteres könnte auch einfach nur "Faulheit", im Sinne nicht dafür verwendeter Ressourcen, sein.

Ich tippe auch das es genau so läuft. Quasi:

Wenn VendorID != "GenuineIntel", dann Fallback nehmen (SSE2), sonst Intel Cpu Typ genauer bestimmen und InstructionSet festlegen.

Der wichtige Unterschied zu "AMD wird benachteiligt" ist hier das Intel halt lediglich prüft ob ne eigene Cpu vorhanden ist und dann nutzt MKL den optimierten Codepfad (AVX2, AVX512). Dadurch das es halt nur 2 x86 Hersteller gibt ist das natürlich automatisch ne Benachteiligung für AMD. Trotzdem wird man Intel daraus keinen Strick drehen können, denn sie sperren 3rd Party (AMD) Cpus ja nicht explizit von der Nutzung der Bibliothek aus. Also rechtlich vermutlich wasserdicht, hat aber ein moralisches Geschmäckle. Besser wäre es gewesen trotzdem auf InstructionSet zu prüfen, wenn keine Intel Cpu erkannt wurde. Das sind nur ein paar Zeilen Code und die tun keinem weh.

Was viel bedenklicher ist, ist die Tatsache das viele Entwickler offensichtlich blind die MKL einbinden und nichtmal prüfen wenn ein AMD erheblich langsamer läuft als anzunehmen ist. Anstatt einfach eine zweite Bibliothek für AMD oder generell eine Alternative zu nutzen.

 

[fortunes]

Jup, Ersteres wäre eine absichtliche Benachteiligung, Letzteres könnte auch einfach nur "Faulheit", im Sinne nicht dafür verwendeter Ressourcen, sein.

Intel fügt die extra Prüfroutine ein, um zu prüfen, ob es sich um Intel- oder non-Intel-CPUs handelt.

Sie programmieren also eine extra Zeile Code - um Ressourcen zu sparen!?



Du machst dich nur noch lächerlich.

 

[ElBlindo]

In letzter Zeit kommt immer mehr von Intels Machenschaften ans Licht. Ich finde die Berichterstattung von HWL wirklich super und informativ.

Aber wofür noch News hier im LuXX veröffentlichen?? Die scheinen ja alle Fehlerhaft oder gar gänzlich falsch zu sein!! Ist diese News jetzt wahr oder nicht??

Oder rennnen die wahren Fachleute nur hier im LuXX rum?? Besonders wenn ein externer Tester zu negativen Statement/Ergebnis von Intel kommt, ist das ja alles üüüüüberhaupt nicht so.

Was denn jetzt?

 

[fortunes]

Ich tippe auch das es genau so läuft. Quasi:

Wenn VendorID != "GenuineIntel", dann Fallback nehmen (SSE2), sonst Intel Cpu Typ genauer bestimmen und InstructionSet festlegen.

Das würde aber bedeuten, dass Intel die MKL seit Version 10 umgeschrieben hat.

Die Versionen 8 und 9 haben alle CPUs gleich behandelt - für alle gab es max. Featureset SSSE3, wenn vorhanden.

Intel hatte damals also bereits alle Prüfroutinen in MKL eingebaut, die es benötigte, um die Featuresets aufzurufen.

Es ist also nur sehr schwer vorstellbar, dass Intel die Programmierung der MKL komplett über den Haufen geworfen und jede CPU von Intel einzeln erkennen lässt, statt die weiteren Featuresets von Version zu Version einfach nur hinzuzufügen. Das ist nämlich leichter als alle CPUIDs einzupflegen, die es jemals von Intel gab.

Ich gehe eher davon aus, dass Intel die Baseline mit SSSE2 aktiviert, dann prüft, ob die IntelVendorID vorliegt, keine CPUID, und dann die weiteren Prüfroutinen für die Aktivierung der Featuresets startet. Liegt keine IntelVendorID vor, werden die Prüfroutinen nicht gestartet und keine Featuresets aktiviert.

 

[Paddy92]

Hör' auf, vom Thema abzulenken. Dem habe ich nicht widersprochen. Es hat aber nichts damit zu tun, dass Intel wohlwissend auf ein Benchmark verweist, das ihre eigene MKL nutzt und AMD-CPUs künstlich benachteiligt.

Du wirfst mir jetzt echt vor, dass ich vom Thema ablenken würde, obwohl du ganz einfach einen neuen Punkt in die Diskussion einstreust?
Die Ausgangsdiskussion - über zig Threads verteilt - war, ob Intel da nun die Nutzung von AVX aktiv abschaltet oder AVX einfach nicht genutzt wird.

Und nein, ich lenke nicht vom Thema ab, da du weiter vorne versuchst hast Ceiber3 zu widersprechen und mir danach bei der Richtigstellung vorgeworfen hast, ich würde Ceiber3 einfach nur aus dem Grund zustimmen, weil es meiner Meinung entspricht. Daraufhin habe ich dir den Beweis verlinkt, dass Intel offiziell nur die eigne Hardware unterstützt. Denn deine Aussage "Intel unterstützt mit der MKL auch fremde CPUs" stimmt nicht so ganz. Zwar funktioniert die Lib auch mit anderen CPUs, nur wird dies nicht gewährleistet.

Wird eine AMD-CPU erkannt, wird diese Prüfroutine abgeschaltet.

Wie kann man nur so begriffsstutzig sein.

Die komplette Zeit reitest du darauf rum, dass AVX abgeschaltet wird. Jetzt wechselst du plötzlich auf die Prüfroutine, die abgeschaltet wird...
Aber auch diese wird nicht abgeschaltet, sondern erkennt diese eine nicht unterstützte CPU -> nutze den default Code path

CUDA läuft nur auf nVidia. MKL läuft auf allen.

Dann siehste mal, wie großzügig Intel doch ist

Das weißt du nicht, weil du es seitenweise über mehrere Threads ignorierst.

Nochmal für dich, zum x-ten Mal:

Intel verweist wohlwissend auf ein Benchmark, welches die Intel-MKL benutzt und aufgrunddessen AMD-CPUs künstlich benachteiligt.

Weil es nicht Bestandteil der Ausgangsdiskussion war und von dir irgendwann einfach eingestreut wurde?!

Aber Hey, Hersteller picken für sich günstige Benches heraus. Nein, wer hätte so etwas denn gedacht?

 

[fortunes]

Du wirfst mir jetzt echt vor, dass ich vom Thema ablenken würde, obwohl du ganz einfach einen neuen Punkt in die Diskussion einstreust?

Du hast geschrieben, dass Intel nur seine eigenen CPUs supportet. Und? Was hat das Abschalten (oder Nicht-Aktivieren) anhand eine Prüfroutine mit "nicht-Support" zu tun?

Man kann doch schreiben, dass eine stabile Nutzung der MKL auf non-Intel-CPUs nicht gewährleistet wird. Aber nein, es werden ganze Featuresets nicht aufgerufen, weil man das auf non-Intel-CPUs verhindern möchte. Auch wenn das keinen Sinn macht.

Die komplette Zeit reitest du darauf rum, dass AVX abgeschaltet wird. Jetzt wechselst du plötzlich auf die Prüfroutine, die abgeschaltet wird...
Aber auch diese wird nicht abgeschaltet, sondern erkennt diese eine nicht unterstützte CPU -> nutze den default Code path

Und warum? Welchen logischen Grund gibt es, AVX nicht zu aktivieren?

Aber Hey, Hersteller picken für sich günstige Benches heraus. Nein, wer hätte so etwas denn gedacht?

Einen Benchmark, von dem sie wissen, dass ihr eigenes Setting dafür sorgt, dass die Konkurrenz benachteiligt wird.

Und darum geht es hier.

 

[Paddy92]

Und warum? Welchen logischen Grund gibt es, AVX nicht zu aktivieren?

Ganz einfach.
Um nicht unterstützte CPUs wird sich nicht gekümmert und diese werden einfach auf den Basisweg abgeschoben.

Einen Benchmark, von dem sie wissen, dass ihr eigenes Setting dafür sorgt, dass die Konkurrenz benachteiligt wird.

Sowie es andere Hersteller auch machen. Ein Beispiel findest du in der News..

 

[Holzmann]

Nehmt euch ein Zimmer.

 

[fortunes]

Ganz einfach.
Um nicht unterstützte CPUs wird sich nicht gekümmert und diese werden einfach auf den Basisweg abgeschoben.

Nochmal:
AVX ist ein Featureset, das man nur aktivieren muss. Sonst nichts weiter. Die gleichen Prüfroutinen, die Intel für die Aktivierung auf den eigenen CPUs einsetzt, kann man auf AMD & Co. einsetzen. Die machen keinen Unterschied.

Man muss nur die eine Zeile Code weglassen, die feststellt, ob Intel oder AMD. Mehr nicht. Kein Mehraufwand, kein Mehrsupport. Nur der Hinweis "Optimiert auf Intel, fremde CPUs können zu Instabilitäten führen."

Sowie es andere Hersteller auch machen. Ein Beispiel findest du in der News..

Dem anderen Hersteller kann man vielleicht vorwerfen, dass sie mit gleichen Waffen kämpfen lassen.

Intel hingegen entwaffnet die Konkurrenz beinahe komplett, bevor man zum Kampf antritt.

 

[Latiose]

Und warum? Welchen logischen Grund gibt es, AVX nicht zu aktivieren?


Und darum geht es hier.

Und was passiert wenn man dies bei Intel auch abschaltet, das avx. Und vorallem wo kann man es denn abschalten. Gibt es denn bei der Software denn überhaupt die Möglichkeit das der Nutzer selbst auch avx abschalten kann. Denn dann wären ja beide bestimmt auf Augenhöhe.
warum avx abgeschaltet wird, es gibt Gründe. Wer zum Beispiel lieber mit nem höheren takt das bewerkställigen will, der schaltet dann avx ganz ab. Denn mit avx gehen keine wirklich hohen Taktraten. Für manche lohnt es sich echt. Wenn man z. B nen 1 GHz höheren takt haben kann mit weniger hitzeentwicklung und weniger Stromverbrauch. Das sind die abgemente die man ja echt gegen avx einwenden kann

 

[ElBlindo]

Nehmt euch ein Zimmer.

 

[Paddy92]

AVX ist ein Featureset, das man nur aktivieren muss. Sonst nichts weiter. Die gleichen Prüfroutinen, die Intel für die Aktivierung auf den eigenen CPUs einsetzt, kann man auf AMD & Co. einsetzen. Die machen keinen Unterschied.

Man muss nur die eine Zeile Code weglassen, die feststellt, ob Intel oder AMD. Mehr nicht. Kein Mehraufwand, kein Mehrsupport. Nur der Hinweis "Optimiert auf Intel, fremde CPUs können zu Instabilitäten führen."

Ach, es ist bekannt, wie genau diese Prüfroutinen ablaufen bzw. auf was genau geprüft wird. Dann hau doch mal raus.

Was passiert denn nach der Vendor-String-Prüfung?
Also ich meine jetzt bezogen auf die Prüfung der Features. Wie wird denn erkannt, welche Features die Intel-CPU unterstützt?

Intel hingegen entwaffnet die Konkurrenz beinahe komplett, bevor man zum Kampf antritt.

Klar, indem man darauf hinweist, dass keine Optimierungen für andere Hardware vorgenommen wird.

 

[Medi Terraner]

Naja, wie haben es schon andere gesagt: Es hat ein Gschmäkle! Ein großes sogar, nachdem Intel extra darauf hinweist, wie gut ihre CPUs mit dem Programm performed und sie wissen, dass die anderen CPUs in ihrer Leistungsfähigkeit beschnitten werden. Aber zeigt, dass Intel im "Panikmodus" ist. All dies ist nur meine Meinung.

 

[Holzmann]

Wenn darüber dachdenkt, wäre das beste einfach AMD bzw. die Zen CPUs von Software zu befreien, die bescheißt.

 

[sch4kal]

Nö, das logisch sinnvolle wäre, auf Bibliotheken auszuweichen, die der Hersteller für seine Produkte empfiehlt oder entwickelt, oder ganz auf Opensource Libs zu setzen, so wie es eben 99 % der User, die mit Software arbeiten, die diese speziellen Libraries benötigt, auch tun.

 

[MassGridParagon]

Ist schon eine wahre Schande für AMD! Wird Zeit, dass AMD vermehrt mit wichtigen Entwicklern zusammen arbeitet und diese auch mit Geld unterstützt .... den AMD war Jahrelang nur noch ne Null-Nummer (seit Opteron, Bulldozer, HSA APU's) was die Zusammenarbeit & Unterstützung von Entwickler angeht.

AMD muss zukünftig hier viel mehr Investieren ... mit viel Geld (harte Dollars) & viel KnowHow als auch Manpower - ROC'm ALL !

@sch4kal

Ja, Ich finde er hat recht .... AMD könnte wirklich mehr tun und die Entwickler besser Unterstützen - vor allem auch mit Software Engineering-Manpower (von AMD Experten speziell auf Ryzen, Threadripper & EPYC optimierter Code) und natürlich ganz viel Geld für die Zusammenarbeit & konstruktive Nachtessen zusammen - das ist wirklich wichtig!

Nehmt euch ein Zimmer.

Ein wahrer Genuss .... Danke & Merci dafür !

 

[elcrack0r]

Wer bist du denn? Das alter ego vom Holzmann? Selber Stil, selbe Art der Avatarwahl?

 

[Holzmann]

Wer bist du denn? Das alter ego vom Holzmann? Selber Stil, selbe Art der Avatarwahl?

Fängst du wieder an hier grundlos User an zu machen, daran ist doch dein letzter account schon gescheitert!?

 

[fortunes]

Der Dampfhammer: AMD Ryzen 9 3950 X Benchmark Session - Workstation, Gaming-Details und Compute - YouTube

Das passiert, wenn man die MKL mit den richtigen Parametern auf AMD-Systemen nutzt.

 

[thegian]

Mit einer AMD-Library würde es vermutlich noch besser aussehen.

 

[fortunes]

Tja, Intel wollte aber, dass man auf den Benchmark von MatLab schaut. Und MatLab nutzt die Intel MKL.

Also muss man die Tricksereien von Intel umgehen, um die wahren Benchmarkwerte zu bekommen.

 

[Oberst]

Ich tippe auch das es genau so läuft. Quasi:

Wenn VendorID != "GenuineIntel", dann Fallback nehmen (SSE2), sonst Intel Cpu Typ genauer bestimmen und InstructionSet festlegen.

Selbst den Fall muss man aber explizit hinein Programmieren. Man könnte ja sonst auch einfach den Hersteller ignorieren und nur nach den Hardware Flaggs der CPU gehen.

Aber Intel hier als böse hin zu stellen, sehe ich auch nicht. Denn schließlich muss man deren MKL nicht verwenden. Mathlabs und Co. hätten hier auch andere Libraries verwenden können... Aber ich könnte mir durchaus vorstellen, dass sich den Fall Gerichte in den USA anschauen. Denn einen expliziten Hinweis, dass die MKL auf nicht Intel CPUs deutlich langsamer läuft, habe ich jetzt auf die Schnelle nicht gesehen, vor allem nicht im Cookbook und anderen Dev Dokumenten (hab aber auch nur kurz geschaut, evtl. habe ich da was übersehen). Die Support Liste hat damit nämlich nichts zu tun. Ginge es nach der, dürfte die Library auf nicht Intel CPUs gar nicht laufen.

 

[sch4kal]

Selbst den Fall muss man aber explizit hinein Programmieren. Man könnte ja sonst auch einfach den Hersteller ignorieren und nur nach den Hardware Flaggs der CPU gehen.

Aber Intel hier als böse hin zu stellen, sehe ich auch nicht. Denn schließlich muss man deren MKL nicht verwenden. Mathlabs und Co. hätten hier auch andere Libraries verwenden können... Aber ich könnte mir durchaus vorstellen, dass sich den Fall Gerichte in den USA anschauen. Denn einen expliziten Hinweis, dass die MKL auf nicht Intel CPUs deutlich langsamer läuft, habe ich jetzt auf die Schnelle nicht gesehen, vor allem nicht im Cookbook und anderen Dev Dokumenten (hab aber auch nur kurz geschaut, evtl. habe ich da was übersehen). Die Support Liste hat damit nämlich nichts zu tun. Ginge es nach der, dürfte die Library auf nicht Intel CPUs gar nicht laufen.

Nö, wurde Intel schon von der FTC dazu verdonnert, und es steht wirklich in fast jedem MKL Artikel in einer Box unten.

 

[OiOlli]

Ich finde ja die Verteidigung süß. Klar macht das Intel nur weil, ähm ja weil halt.

Intel spielt hier mal wieder seine Marktmacht zu Ungunsten der Konkurrenz aus. Da hilft auch kein, muss man ja nicht nutzen. Hersteller passen ihre Software doch meistens an den Marktführer an und nicht an den Underdog.

 

[sch4kal]

So ist das halt, wenn vom Konkurrenten damals nur Software-crap kam, und selbst AMD machine code unter dem Intel compiler schneller war, als unter AMDs compiler.

 

[fortunes]

Aber Intel hier als böse hin zu stellen, sehe ich auch nicht. Denn schließlich muss man deren MKL nicht verwenden.

Es geht ja auch nicht darum, Intel als böse hinzustellen, weil MatLabs deren MKL benutzt und die auf AMD schlecht läuft. Ist halt eine Entscheidung von MatLabs.

Es geht hier darum, dass Intel mit dem Finger auf die Benchmarks von MatLabs zeigt und seine eigenen Prozessoren damit hervorheben will - wohlwissend, dass deren eigene MKL künstlich AMD-CPUs ausbremst.

MatLabs kann nichts dafür, die verwenden einfach nur die MKL von intel, weil sie das schon immer gemacht haben.

Intel aber hat beim Wechsel von Version 9 auf Version 10 der MKL sämtliche Befehlssatzerweiterungen oberhalb SSE2 für non-Intel-CPUs weggenommen bzw. aktiviert diese nicht mehr.

Und genau das wird Intel jetzt vorgeworfen - der Vergleich seiner Produkte mit der Konkurrenz und dabei massiv die mangelnde "Waffengleichheit" ausblenden.