News Intel MKL: Matlab R2020a beinhaltet offiziellen AMD-Workaround

gaelic schrieb:
Also daß die Abfrage dermaßen simpel erfolgt und eigentlich nichts mit "Optimierung" zu tun hat ist erst seit @NedFlanders bekannt.
Das bezweifle ich, denn in meiner Ausbildungszeit vor .... etwa 5 jahren denke ich war es schon üblich für einige tests und benchmarks an der vendorID zu manipulieren. Genau solch eine Diskussion bezüglich MKL und ärger dass man da erst 'hacken' muss damit es auf den bulldozern richtig läuft fand in dem büro statt in dem ich saß.
Allerdings habe ich da auch gelernt dass man solche Dinge nicht nach außen trägt um z.b. gute beziehungen zu schonen. Da gab es eben auch viele engineering samples von intel, oder nichtöffentliche informationen über prozessordetails unter NDA die erheblich bei der forschung halfen und sicher immer noch helfen. Wenn man intel ans bein pinkelt indem man sowas an die große glocke hängt oder gar ein paper drüber schreibt muss man bereit sein auf diese kooperation zu verzichten.
 
  • Gefällt mir
Reaktionen: Iscaran
Kacha schrieb:
Wie genial das ganze funktioniert kann man hier im Forum taeglich beobachten

Wie viele Benchmarks hat Computerbase mit der MKL bisher verwendet? Wenn ich mich nicht irre... keinen!
Bis vor einiger Zeit waren die Intel CPUs auch ohne solche "Tricks" die bessere Wahl. Jetzt ist das anders... ob mit oder ohne MKL.

Wuerde MKL nur auf Intel laufen und sonst einen Fehler geben, dann waere es Produktpflege.

Warum sollte das so sein? Und es wäre irrational unter solchen Umständen so etwas wie die MKL überhaupt zu entwickeln - das ist dir doch bewusst?
 
Zuletzt bearbeitet:
calluna schrieb:
Unternehmen sind keine Personen und es gelten nicht die moralischen Regeln aus unserem zwischenmenschlichen Alltag.
Da habe ich etwas für mich gesprochen: Unmoralisches Verhalten ist für mich absolut nicht nachvollziehbar, und ich meide solche Unternehmen konsequent. Für mich deshalb diese Unterscheidung.
calluna schrieb:
Ja, aber dann wäre es rational so etwas wie die MKL erst gar nicht zu entwickeln.
Du kannst es dir wahrscheinlich kaum vorstellen, aber es gibt Leute, die entwickeln solche Software Open Source. Und nicht nur nette Wohltäter wie @ZeroStrat mit CapFrame X, sondern auch solche von dir angeblich rational-eigennützig genannte Firmen, wie zum Beispiel AMD beim Machine Learning.
 
Colindo schrieb:
Du kannst es dir wahrscheinlich kaum vorstellen...

Doch, kann ich mir vorstellen, die MKL-DNN ist auch Open Source... ist ein guter Punkt, da stimme ich dir zu.

Colindo schrieb:
Unmoralisches Verhalten ist für mich absolut nicht nachvollziehbar, und ich meide solche Unternehmen konsequent.

Und kaufst du Produkte von Nestle oder einem der Tochterunternehmen? (Betrifft ja die Hälfte der Produkte in einem Supermarkt) Ich weiß, was du meinst... das Problem ist nur, dass man, wäre man konsequent, von sehr vielen Unternehmen nichts mehr kaufen könnte.
 
  • Gefällt mir
Reaktionen: .Sentinel.
Artikel-Update: Intel MKL impliziert keinen Workaround
Anders als von einigen Nutzern fälschlicherweise angenommen und von anderen Formaten auch ein wenig unkonkret formuliert, impliziert weder das in Matlab R2020a zum Einsatz kommende Intel MKL 2019 Update 3 noch das aktuellste Update 4 der MKL-Programmbibliothek den Workaround mit dem AMD Ryzen nun in Matlab zu erwartende Ergebnisse erzielen.

Das Lösen des Knotens ist einzig der Laufzeitroutine der Matlab-Macher von MathWorks zu verdanken, die den Prozessor mittels CPU ID und Feature-Set-Abfrage prüft und die MKL in den Debug Mode schaltet.

Release Notes verraten Workaround auch (fast) offiziell
Auch wenn die Release Notes von Matlab R2020a den Workaround nicht beim Namen nennen, geben sie unter dem Punkt „Performance Enhancements“ doch einen deutlichen Hinweis:

[Bilder: Zum Betrachten bitte den Artikel aufrufen.]
 
ZeroStrat schrieb:
Das nicht Unterstützen von AVX kann doch bereits als Untätigkeit ausgelegt werden.
Andersrum ist das Einbauen einer Vendor-ID Abfrage um die Unterstützung explizit zu verwehren alles andere als Untätigkeit.

ZeroStrat schrieb:
*** Support von AVX kann als Optimierung ausgelegt werden.
Wo wird denn da was optimiert?
Die CPU kann AVX, man lässt es die CPU aber bewusst nicht nutzen, und das mit einer Vendor-ID Abfrage, die ansonsten keinen Nutzen hat, somit hat man wie im Agreement beschrieben
absichtlich die Leistung oder den Betrieb eines spezifizierten AMD-Produkts verschlechtert
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: jusaca, Kodak, Volkimann und 4 andere
Ich glaube sowas müssen Juristen entscheiden, denn es ist ja gerade die Frage, wie eine absichtliche Verschlechterung definiert ist. Für micht ist das Nichtunterstützen von Features, die nicht von Produkten der eigenen Firma kommen und einen signifikaten Performanceeinfluss haben bereits eine absichtliche Verschlechterung, da man ja das Feature unterstützt, aber nur bei eigenen Produkten.
 
ZeroStrat schrieb:
** Da AMD selbst keine konkurrenzfähige Lib hat, wäre es ein Produktvorteil für AMD, dass deren CPUs ihr volles Potential entfalten können.
Demnach wäre es auch okay wenn AMD in einer eigenen Lib nach der Intel ID abfragen würde und in dem Fall den takt um 400MHz reduziert?
Immerhin wäre es ein Produktvorteil wenn man Intel CPUs ihr volles Potenzial nutzen lassen würde
 
  • Gefällt mir
Reaktionen: L0g4n und SVΞN
Taxxor schrieb:
Andersrum ist das Einbauen einer Vendor-ID Abfrage um die Unterstützung explizit zu verwehren alles andere als Untätigkeit.
[...]
Die MKL fragt nicht nur den Vendor String ab, sondern auch die Prozessorfamilie (selfplug: such nach meinen vorhergehenden Post). Irgendwie muss ne Entscheidung nach Featuresets in den Code, dass dieser Teil bei Software von Intel genau auf Intel Hardware zugeschnitten ist, ist keine aktive Benachteiligung Dritter.

Klar man könnte den Teil eleganter umsetzen, muss Intel an der Stelle aber nicht.
 
  • Gefällt mir
Reaktionen: ZeroStrat
Piktogramm schrieb:
Die MKL fragt nicht nur den Vendor String ab, sondern auch die Prozessorfamilie (selfplug: such nach meinen vorhergehenden Post). Irgendwie muss ne Entscheidung nach Featuresets in den Code, dass dieser Teil bei Software von Intel genau auf Intel Hardware zugeschnitten ist, ist keine aktive Benachteiligung Dritter.
Auch die Prozessorfamilie müsste man nicht abfragen, eine reine Featureset Abfrage, die anschließend sowieso gemacht wird(aber eben nur, wenn der Vendor String vorher Genuineintel lautet), reicht völlig aus.
 
  • Gefällt mir
Reaktionen: usb2_2
Taxxor schrieb:
Demnach wäre es auch okay wenn AMD in einer eigenen Lib nach der Intel ID abfragen würde und in dem Fall den takt um 400MHz reduziert?
Immerhin wäre es ein Produktvorteil wenn man Intel CPUs ihr volles Potenzial nutzen lassen würde
Aktive Handlung zum Nachteil des Wettbewerbs -> Nicht zulässig.
Genau solche aktiven Maßnahmen zum Ausbremsen des Wettbewerbs hat Intel aber auch nicht im Code.

############

@Taxxor
Featuresets kann man auf zig Wege implementieren. Bei der MKL kann man es sogar begründen wieso man Prozessorfamilien abfragt, die spiegeln genau jene Architekturen wieder, für die der icc optimierte Profile hat.

Und nein, es werden keine Featuresets abgefragt: Siehe https://www.computerbase.de/forum/t...iziellen-amd-workaround.1933817/post-23909007

Featuresets abfragen und daran entscheiden welche Pfade genommen werden würde mir als FOSSler auch gefallen, aber technisch notwendig ist es nicht.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: ZeroStrat
Piktogramm schrieb:
Aktive Handlung zum Nachteil des Wettbewerbs -> Nicht zulässig.
Genau solche aktiven Maßnahmen zum Ausbremsen des Wettbewerbs hat Intel aber auch nicht im Code.
Deaktivierung der Featureset Abfrage und damit nicht Nutzen von vorhandenen Resourcen der CPU bei nicht Intel CPUs ist genau so eine aktive Maßnahme wie das nicht Nutzen von zusätzlichem Takt bei nicht AMD CPUs.

Bzw. die Vendor ID Abfrage die nur dazu dient, die Featureset Abfrage danach entweder auszuführen oder eben nicht, ist die aktive Maßnahme.

Man könnte diese ID Abfrage sowie die Abfrage der Prozessorfamilie komplett aus dem Code entfernen und für Intel CPUs würde alles noch genau so laufen wie vorher, da es auch unterschiedliche Featuresets innerhalb einer Familie gibt und so ultimativ sowieso nach dem Featureset gefragt wird.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Volkimann
Piktogramm schrieb:
Klar man könnte den Teil eleganter umsetzen, muss Intel an der Stelle aber nicht.
Eleganter wäre es, das System in ein Fehler laufen zu lassen, sodass sowas gar nicht erst passiert und Entwicklung einfließen muss, falls die Software nicht auf einer CPU läuft.

Indem Fall hätte so eine fehlende Abfrage sogar zu mehr Performance geführt und das, so wie ich mich noch erinnere sogar bei den älteren Ryzen Modelle.

Ein guter Vergleich wäre, ein Auto auf Handbremse fahren zu lassen, nur weil ich keine Marken Reifen von Michelin (oder sonst Top bekannte Marke) habe.
 
Taxxor schrieb:
Deaktivierung der Featureset Abfrage und damit nicht Nutzen von vorhandenen Resourcen der CPU bei nicht Intel CPUs ist genau so eine aktive Maßnahme wie das nicht Nutzen von zusätzlichem Takt bei nicht AMD CPUs.
Es wurde nichts deaktiviert. Die von dir behauptete Abfrage von Featuresets gab es nie, also musste nie etwas deaktiviert werden.
Genauso wie deine herbeifantasierte Senkung irgendwelcher Betriebsfrequenzen nicht gab. Wenn du diskutieren willst, tu das bitte nicht anhand irgendwelcher nicht existenter Hirngespinster.

Bzw. die Vendor ID Abfrage die nur dazu dient, die Featureset Abfrage danach entweder auszuführen oder eben nicht, ist die aktive Maßnahme.
Es gibt und gab keine Abfrage von Featuresets in der MKL, sondern Abfragen nach Intel Prozessorfamilien.

Man könnte diese ID Abfrage sowie die Abfrage der Prozessorfamilie komplett aus dem Code entfernen und für Intel CPUs würde alles noch genau so laufen wie vorher, da es auch unterschiedliche Featuresets innerhalb einer Familie gibt und so ultimativ sowieso nach dem Featureset gefragt wird.
Wenn die Abfrage nach der CPU Familie deaktiviert wird, dann laufen alle CPUs den Default Path auf SSE2 Niveau. Was allen aktuellen X86 CPUs die Performance ganz gewaltig verhageln würde.
Die Massiv abweichenden Features innerhalb einer CPU-Familie. Da kann ich mich an nicht viel mehr als div. Featurelevels bei AVX512 erinnern. Da müsste man den Spaß echt detaillierter auseinandernehmen, ob da die MKL detaillierter vorgeht als icc -xCOMMON-AVX512 -mtune=xx oder ob es da nochmals einzelne Pfade für die Abweichenden Featurelevel von AVX512 vorgesehen sind.


pipip schrieb:
Eleganter wäre es, das System in ein Fehler laufen zu lassen, sodass sowas gar nicht erst passiert und Entwicklung einfließen muss, falls die Software nicht auf einer CPU läuft.
[...]
Programme so zu schreiben, dass sie illegale Befehle an eine CPU schicken, weil sie diesen vermeidbaren Fehlerfall nicht abfangen ist vieles, aber nicht elegant.
Ansonsten, Autovergleich? huiuiui
 
Piktogramm
Sowohl die Hersteller von Matlab, als auch AMD wussten, dass Ryzen irgendwann auf Matlab benützt wird, deshalb testet man das. Wenn es aber Passagen gibt, die sowieso alles auf default laufen lassen, wird es auch nie Optimierung geben.
Ich spreche da von einem Zeitpunkt noch vor dem gemeinen Otto.
 
Piktogramm schrieb:
Die MKL fragt nicht nur den Vendor String ab, sondern auch die Prozessorfamilie/Es gibt und gab keine Abfrage von Featuresets in der MKL, sondern Abfragen nach Intel Prozessorfamilien.

Interessant! Gibt es eine Prozessorfamilie "Ryzen" oder "Zen"?
 
  • Gefällt mir
Reaktionen: Iscaran und SVΞN
Matlab hat wie alle profitorientierten Unternehmen mit nahezu marktbeherrschender Stellung gewartet bis sie einen Arschtritt bekamen.
Und AMD, da sollte man nicht vergessen, dass sie lange Jahre massive Geldsorgen hatten und die Personaldecke noch lange nicht wieder so dick ist, dass sie an alles denken. Geschweige denn, dass sie die vielen Jahre wo ihr Support für Treiber, Compiler und Bibliotheken eher mäßig war hätten aufholen können.
Ergänzung ()

Ned Flanders schrieb:
Interessant! Gibt es eine Prozessorfamilie "Ryzen" oder "Zen"?
Post #110 hier oder irgendwo im Thread zur ersten Meldung zu deinem "Hack"...
Wie oft denn noch o.O
 
ZeroStrat schrieb:
Der Industrie ist das scheiß egal, die kaufen immer noch fast nur Intel.

Woher kommt eigentlich diese weitergetragene Intel-Arroganz?

"Die Industrie" ist doch kein homogener Haufen in dem alle die gleiche Meinung haben. Viele Unternehmen aus verschiedensten Branchen versuchen permanent Kosten zu senken, warum solten sie also (zukünftig) kein Interesse an günstigeren/effizienteren/schnelleren Konkurrenzprodukten haben? Dort sind doch nicht alle verblödet und folgen einem Dogma. Nicht jeder lässt sich einlullen und schmieren für kurzfristige Vorteile, wenn es langfristig ein Sägen am eigenen Ast ist.
 
  • Gefällt mir
Reaktionen: Kodak, Volkimann und Starkstrom
Piktogramm schrieb:
Wie oft denn noch o.O

Warum bist denn immer gleich so salty? Ist doch ne normale Frage. Wenn die MKL den Codepfad nach CPU Family entscheidet und nicht nach Feature Set Abfrage, dann muss es da ja einen entsprechenden Eintrag für Ryzen oder Zen geben, und den sehe ich in deiner Liste halt nicht. Ich würde es aber gerne genau wissen und nicht nur vermuten müssen.

Ich denke Mal letzteres teilen wir.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Der Lord und s0UL1
Zurück
Oben