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

Ja... und der Artikel bei heise ist wesentlich besser recherchiert bzw. musste die Person ja nur diesen Thread hier lesen, in dem auch der Link zu Agner Fog ist.

heise schrieb:
Die Benachteiligung von AMD-Prozessoren durch Intel-Compiler wurde zudem von der US-Wettbewerbsaufsicht FTC untersucht, weshalb Intel seither darauf hinweisen muss. Dass die optimierte Intel-MKL trotzdem in gängigen Programmpaketen zum Einsatz kommt, liegt letztlich in der Verantwortung von deren Entwicklern.
 
calluna schrieb:
Ja... und der Artikel bei heise ist wesentlich besser recherchiert.
Und noch keiner einer hat gemerkt, dass die vielfach zitierte "Matlab MKL AVX2 on AMD.bat" von @Ned Flanders auf den "normalen" MatLab-Rechnern gar nicht funktionieren kann, weil die Leute normalerweise keine extra MKL installiert haben und daher auch kein "call "%MKLROOT%\bin\mklvars.bat" MKL_DEBUG_CPU_TYPE=5" klappen kann. Hmmm.
 
Jesterfox schrieb:
Sach mal... hier wird nirgends gefordert das Intel für AMD optimieren soll. Sie sollen nur nicht die von AMD unterstützten Featuresets (die sie ja auch auf ihren CPUs nutzen) brach liegen lassen mit ihren bescheuerten Abfragen.
Das hat AMD zu regeln und nicht Intel, und wenn sie dazu nicht im Stande sind, und es dann erst irgendwelcher Nerds bedarf , die das für sie hinfrickeln ,dann haben sie eben Pech gehabt

Konkurrierende Konzerne werden den Teufel tun ,und auch noch Arbeit in den Support des Konkurrenten zu stecken

Denn funktioniert das Programm dann nämlich nicht wie gewünscht , weil AMD irgendwelche Abweichungen/Absonderheiten in der AVX Implementierung ihrer CPU haben , kommen gleich die nächsten an und vordern das Intel noch den Code optimiert oder was?!

Fall Back Layer für alle nicht Intel CPUs und fertig, und wenn sich der Konkurrent dann Jahre nen feuchten Furz drumm kümmert,das solch ein Programm optimiert wird für AMD, dann ist das bestenfalls deren Problem!

Aber dank Community bekommen sie ja immer den A... gerettet ,wie auch kürzlich bei der Boostthematik
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Piktogramm
blöderidiot schrieb:
Und noch keiner einer hat gemerkt, dass die vielfach zitierte "Matlab MKL AVX2 on AMD.bat" von @Ned Flanders auf den "normalen" MatLab-Rechnern gar nicht funktionieren kann, weil die Leute normalerweise keine extra MKL installiert haben und daher auch kein "call "%MKLROOT%\bin\mklvars.bat" MKL_DEBUG_CPU_TYPE=5" klappen kann. Hmmm.

hat glaube ich einige Seiten vorher in diesem Thread schon jemand auf diesen Umstand hingewiesen, aber ja sollte man in dem Artikel nochmal hervorheben.

captain kirk schrieb:
Das hat AMD zu regeln und nicht Intel, und wenn sie dazu nicht im Stande sind, und es dann erst irgendwelcher Nerds bedarf , die das für sie hinfrickeln ,dann haben sie eben Pech gehabt

Konkurrierende Konzerne werden den Teufel tun ,und auch noch Arbeit in den Support des Konkurenten zu stecken

das ganze bekommt einen fahlen beigeschmakt bedenkt man das Intel 2010 deswegen bereits eine Milliarden Strafe an die FTC zahlen hat müssen ;-)

und Sie diesbezüglich ein Agreement unterzeichnet haben --> Zitat: Deshalb verpflichte man Intel mit einer umfangreichen Anordnung nun zu Maßnahmen, die fairen Wettbewerb sicherstellen sollen.
 
captain kirk schrieb:
Das hat AMD zu regeln und nicht Intel, und wenn sie dazu nicht im Stande sind, und es dann erst irgendwelcher Nerds bedarf , die das für sie hinfrickeln ,dann haben sie eben Pech gehabt
AMD soll also ernsthaft in Intels Bibliotheken rumpfuschen und die Abfrage entfernen obwohl sie das laut Urheberrecht gar nicht dürfen (ist ja nicht ihr Code) oder wie stellst du dir das vor? Das was da "Nerds hingefrickelt" haben ist übrigens genau das: ein Hack über undokumentierte Debugvariablen. Das ist nichts was man (als AMD) offiziell rausgeben kann.
 
  • Gefällt mir
Reaktionen: Tapion3388 und HaZweiOh
Benji18 schrieb:
2010 deswegen bereits eine Milliarden Strafe an die FTC zahlen hat müssen ;-)
Und 2010 ist jetzt 9 Jahre her, heute (oder erst Recht Ende 2016) würde man das nochmal anders bewerten.
Insbesondere müsste man konstatieren, dass die damaligen Maßnahmen Intel nicht von weiteren Taten abgehalten haben, und die Schlüsse daraus ableiten.

Leider ist juristischer Sachverstand im Technik-Bereich wohl ziemlich schwach ausgeprägt. Selbst in einem alten c't-Artikel kam der Autor mit der fixen Idee um die Ecke, dass Intel kein Monopol bei Compilern hätte. :freak:
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Benji18
captain kirk schrieb:
Aber dank Community bekommen sie ja immer den A... gerettet ,wie auch kürzlich bei der Boostthematik

Ich fass es immer noch nicht wie du so viel Mist in so wenigen Sätzen verpacken kannst und das immer und immer wieder.

Um es mal für dich verständlich zu halten:
"Hat Google nicht kürzlich durch Retpoline Intel den Arsch gerettet ?"
 
  • Gefällt mir
Reaktionen: Salamimander und cbmik
Jesterfox schrieb:
. Das ist nichts was man (als AMD) offiziell rausgeben kann.
Dann muss man sich eben mit Intel an einen Tisch setzten , und was offizielles entwickeln,aber mit der eigenen Manschaft u nicht der des Mitbewerbers!.

Nur man sollte nicht so vermessen sein zu glauben das einen hier die gebratenen Tauben immer in den Mund fliegen

Oder gar nen Aufstand proben wenn mal wieder ein Nerd nen Hack für sie bastelt

Das ist immer noch Marktwirtschaft ,und da hat jeder die Arbeit für sein Produkt zu erledigen, und nicht umgekehrt!

Intel hat den Teil für seine CPUs erledigt ,und mehr müssen sie auch nicht !
 
Eigentlich sind wir mit dem Thema jetzt durch, oder?

Es ist moralisch verwerflich, aber verständlich aus Geschäftssicht, da Produktpflege... und rechtlich offensichtlich kein Problem, da Intel 2010 dazu verpflichtet wurde, darauf hinzuweisen, was auch geschieht, wovon sich jeder AMD Nutzer überzeugen kann, wenn er versucht die MKL zu installieren.

Aber diesen Hinweis sieht man nicht, wenn die MKL als Mitbringsel mit anderer Software ausgeliefert wird - dafür ist dann aber nicht Intel verantwortlich.

Worauf kann man als Nutzer von AMD hoffen? Auf bessere Unterstützung Seitens AMD (AOCL) und eine gute Verbreitung durch einen größeren Marktanteil.
 
  • Gefällt mir
Reaktionen: tony_mont4n4 und Benji18
captain kirk schrieb:
Nur man sollte nicht so vermessen sein zu glauben das einen hier die gebratenen Tauben immer in den Mund fliegen
Das erwartet hier auch keiner. Nochmal (weil schon mal irgendwo hier geschrieben): eine handoptimierte Version für AMD CPUs erwartet hier keiner von Intel. Aber sie sollen die Featuresets sauber abfragen und nicht nach Vendor ID.
 
  • Gefällt mir
Reaktionen: Benji18 und Cobra975
Jesterfox schrieb:
Aber sie sollen die Featuresets sauber abfragen und nicht nach Vendor ID.
Nochmal das ist nicht deren Pflicht noch Aufgabe , wenn das AMD gerne möchte , müssen sie ihren A... hoch bekommen und ne Coder Delegation zu Intel senden, um das anzupassen, und dann auch verdammt nochmal die Garantie dafür übernehmen, das das Programm mit ihrer AVX Version der CPU zurecht kommt

Nur weil da jetzt jemand was gehackt hat , ist das noch lange kein Support wie er sein sollte ,und der liegt nicht bei Intel basta!

Das selbe blöde Spiel , wird ja auch immer bei Nvidias Gameworks gefordert , alle sollen am besten immer AMD zuarbeiten, damit die Faulpelze sich ins gemachte Nest setzen können, und nur nicht irgendwelche Mannstunden auf dem roten Konto auflaufen für sowas wie aktiven Support am eigenen Produkt
 
Zuletzt bearbeitet:
@Jesterfox

Spar dir die Zeit. Er wird Intel als Unschuldslamm bis zum bitteren Ende darstellen.
 
  • Gefällt mir
Reaktionen: washieiko, Tapion3388 und darkcrawler
blöderidiot schrieb:
Und noch keiner einer hat gemerkt, dass die vielfach zitierte "Matlab MKL AVX2 on AMD.bat" von @Ned Flanders auf den "normalen" MatLab-Rechnern gar nicht funktionieren kann, weil die Leute normalerweise keine extra MKL installiert haben und daher auch kein "call "%MKLROOT%\bin\mklvars.bat" MKL_DEBUG_CPU_TYPE=5" klappen kann. Hmmm.

Im Wissenschaftlichen Bereich, ist es gar nicht so unüblich, dass da noch ein Haufen Libraries auf den Rechnern rummschwiert.
 
blöderidiot schrieb:
Nochwas: ich habe eine schöne Vega56 von Sapphire. Wieso läuft da kein CUDA drauf - obwohl die das technisch ohne weiteres könnte? Kannst Du dich da mal kümmern? Oder: ich habe keinen Fernseher und höre auch keinen öffentlich-rechtlichen Rundfunk. Diese eigenartige Steuer muss ich trotzdem bezahlen. Hilfst Du mir?

Du vergleichst hier Äpfel mit Birnen. Wenn AMD und Nvidia dieselbe ISA hätten, könnten wir vergleichen. Dann sähe es so aus, dass CUDA auf deiner Karte laufen würde, aber die schnellen Funktionen würden nicht genutzt werden weil die nur dann genutzt werden wenn der Vendor Nvidia wäre.

Intel behindert hier absichtlich die Konkurrenz. Wenn sie die MKL auf AMD CPUs komplett blockieren würden, hätte alle mehr davon. Denn dann würde man sie schlicht nicht benutzen wenn ich so oder so noch eine andere Lib als Fallback einbauen müsste. Wie gesagt, als Entwickler gehst du nicht von dem Verhalten aus. Einen gewissen Unterschied wird man erwarten, da man davon ausgehen wird, die Lib sei speziell für intel Optimiert, dabei werden die generellen Optimierungen bei AMD CPUs einfach deaktiviert, obwohl die CPU es könnte.

Und schau dir den decompilierten Code an, das passiert nicht einfach durch den Compiler. Zumal solch ein Verhalten Intel auch untersagt wurde wenn ich mich richtig an die Klagebeilegung erinnere.
 
  • Gefällt mir
Reaktionen: Tapion3388, Benji18, blöderidiot und eine weitere Person
Es ist ja generell ironisch eine Vendor Abfrage zu machen, obwohl man dann eine Feature Abfrage macht.... man weiß schon was man da tut, vor allem in Hinblick darauf, dass man Tech-Magazine darauf hinweist doch bitte diese Software für Benchmarks zu benutzen.

Ich glaub das ist eigentlich das dreckigste an der Sache. Man verkrüppelt per Vendor-Abfrage den Konkurrenten und will dann auch noch das Programm in die Benchmarks aufnehmen. Das ist ja fast noch besser als "Cascade Lake X ist sicher!" (obwohl sie schon auf die Sicherheitslücken hingewiesen wurden und damit den Tatbestand der arglistigen Täuschung erfüllt haben.)
 
@nille02

Lies doch bitte, was bisher geschrieben und verlinkt wurde. Der Intel Compiler kann genau solchen Code einfügen und Intel muss bei der Installation der MKL darauf hinweisen, was auch geschieht. Jeder Entwickler, der direkt die MKL verwendet und mit seiner Software vertreibt, weiß davon.

@aldaric

Intel ist keine Person und nicht jeder bei Intel weiß alles... erst recht nicht jemand aus dem Marketing... zumal Matlab auch die MKL-DNN verwendet und dort AMD nicht benachteiligt wird, außer die Entwickler von Mathworks haben es falsch kompiliert.

Kannst du bitte noch einmal die Quelle Posten, was für ein Benchmark da und von wem vorgeschlagen wurde?
 
nille02 schrieb:
Du vergleichst hier Äpfel mit Birnen. Wenn AMD und Nvidia dieselbe ISA hätten, könnten wir vergleichen. Dann sähe es so aus, dass CUDA auf deiner Karte laufen würde, aber die schnellen Funktionen würden nicht genutzt werden weil die nur dann genutzt werden wenn der Vendor Nvidia wäre.
Ja und nein. Das bezogene Posting war natürlich eher ironisch gemeint, aber wenn Du schon beim Thema bist: AMD hatte vor 4 (oder sowas) Jahren angefangen, einen Wrapper für CUDA zu bauen (HIP). Leider ist der Fortschritt eher schleppend und das ganze funktioniert nur im ROCm-Framework und leider nur unter Linux, spezifisch auch nur unter Ubuntu-derivaten (IIRC). => https://github.com/ROCm-Developer-Tools/HIP/blob/master/INSTALL.md
Also nicht ganz so utopisch wie es scheint. Ich verweise außerdem auf: Otoys CUDA-wrapper für den Octane-Renderer.
Wenn sie die MKL auf AMD CPUs komplett blockieren würden, hätte alle mehr davon. Denn dann würde man sie schlicht nicht benutzen
Das halte ich für schlichtweg falsch. Bis auf die paar Routinen, die auf Intel durch AVX sehr deutlich schneller sind, laufen alle anderen Funktionen auf AMD sehr gut und werden sehr gerne benutzt. Es ist mir schlichtweg Wumpe, ob ich ab und zu bei Berechnungen 0,05 oder 0,5 Sekunden warten muss. Selbst gelegentlich 5 Sekunden wären mir völlig egal. Im Mix aller Aufgaben fällt das wenig ins Gewicht. Ich habe hier MatLab R2019.B auf einem 1700X laufen und weiß inzwischen schon, welche Routinen auf der Mühle langsamer sind als auf dem i7-2600K gegenüber. Es ist mir aber, wie schon angedeutet, im Grunde egal. Die MKL ist hinreichend schnell und auch auf AMD-Rechnern zuverlässig einsetzbar. Wird sie in Zukunft auf meiner Mühle schneller, akzeptiere ich das, mache aber meinen seelischen Gesundheitszustand nicht davon abhängig.
 
Zuletzt bearbeitet:
Zurück
Oben