News Intel MKL: Matlab R2020a beinhaltet offiziellen AMD-Workaround

aldaric schrieb:
Und diese Transparenz passiert auch nur, weil sie sonst rechtlich angreifbar bleiben. Wer jetzt noch glaubt das Intels Verhalten legal und fair ist, hat den Schuss immer noch nicht gehört.
Wenn es illegal wäre, hätten sie im Zuge des anti Trust Verfahrens schon lange zwingend wettbewerbswidrige Codestellen geändert.

LG
Zero
 
@ZeroZerp

Ist dir selbst noch nicht aufgefallen das dein beispiel für deine Argumentation für die Tonne ist?
Wenn Intel das Auto (Hardware) entwickelt hat und AMD die Rechte für der Nutzung erhalten hat dann frage ich mich warum sie nicht mit der glechen Bereifung (Befehlssätze) auf der gleichen Straße (Software) fahren dürfen sondern dafür eine erheblich schlechtere vorgeschrieben wird obwohl eine gleichwertige vorhanden wäre.

Damit schließt sich dann wieder der Kreis zu meinem Beispiel. ;)

Du ignorierst fleißig das die Hardware und Software zur Ausführung vorhanden ist aber deren Nutzung bei der Konkurrenz künstlich verhindert wird. Passt halt nicht zum eigenen Konzept.

So nebenbei, Intel hatte schonmal wegen Compiler Tricks zur Wettbewerbsverzerrung bei regulärer Software einen vor den Latz bekommen und auch die Umstände waren damals ähnlich. Intel war seitens der Hardware im Rückstand und wollte sich so die Konkurrenz vom Leib halten. Der einzige ernsthafte Unterschied den ich sehe ist das man nun nicht direkt bei dem Hauptprogramm ansetzt sondern bei den dazu gehörigen Unterprogrammen.
 
  • Gefällt mir
Reaktionen: Iscaran
ZeroZerp schrieb:
Ja- Weil ich es nicht als Ausbremsung sehe. Die Gründe habe ich in diesem Thread schon mehrfach genannt.
Das Ding prüft, obs ein Intel Prozessor ist- Wenn nein->maximale kompatibilität, altes Instruction Set.
Wenn ja- Was kann das Ding alles -> optimiertes Instruction Set.

Sorry aber genau diese Art Abfrage passiert doch gar nicht.

Außerdem stellt ja schon allein die NICHT-Verwendung eines "optimierten" Instruction Sets das zudem als Standard definiert ist in meinen Augen eine ganz klare Performancebremse dar.

Eine AMD CPU kann ja das optimierte Instruction Set AVX ganz genauso wie eine Intel CPU. Sie wird nur nicht dazu aufgefordert dieses zu benutzen weil die Vendor ID Abfrage, diese Verhalten seitens der MKL blockiert.

Das ist absichtliches Pessimieren eines "Konkurrenten" bzw. Vorenthalten gemeinsamer Standards nur weil nicht der passende "Sticker" auf dem Produkt ist.

Der Autovergleich mit den Notreifen vs. Normalreifen ist leider ziemlich nahe dran an dem was da läuft.

SSE, SSE2, usw. AVX, AVX-2, AVX-512 sind alles definierte Standards. Deswegen heissen die Dinger auch "Instruction Sets". Und dabei ist es egal wer diese zuerst aufgebracht oder eingebracht hat. Zumal ja gerade bezüglich dieser Dinge auch der PatentNutzungsvertrag existiert.
https://en.wikipedia.org/wiki/X86_instruction_listings
"The x86 instruction set refers to the set of instructions that x86-compatible microprocessors support. "
Da steht nix von Intel only....

Wenn also eine AMD eine CPU baut die auf die Abfrage "kannst du AVX" ein "JA" liefert, dann ist es nicht Sache der MKL zu sagen "dududu - ne das machen wir nicht, weil du nix Intel"....

EDIT: Ansonsten kann ich da wirklich nur empfehlen müssen wir User druck auf die Entwickler ausüben und bis diese den Druck sich hier "vernünftig" zu verhalten auch gegenüber Intel ausüben. Oder die Entwickler eben auf die Verwendung einer absichtliche diskriminierenden Software pfeiffen und sich eben gleich ordentlich Standards zuwenden - auch wenn diese in manchen Fällen langsamer auf Intel CPUs laufen....tja da schiesst man sich halt eben selbst ins Bein (als Firma Intel).
Ergänzung ()

Nachtrag:

Im übrigen wurden AVX gemeinsam von Intel und AMD im July 2008 entwickelt und eingereicht:
https://de.wikipedia.org/wiki/Advanced_Vector_Extensions
"Advanced Vector Extensions (AVX) ist eine Erweiterung des x86-Befehlssatzes für Mikroprozessoren von Intel und AMD, die von Intel im März 2008 vorgeschlagen wurde. "

Der AMD Name dafür (bzw. für einen teil dessen was später AVX wurde) war SSE5:
https://en.wikipedia.org/wiki/SSE5
Aus Kompatibilitätsgründen hat AMD dann sich an AVX-Intel angepasst und ihr SSE5 "verworfen".
"AMD chose not to implement SSE5 as originally proposed. In May 2009, AMD replaced SSE5 with three smaller instruction set extensions named as XOP, FMA4, and F16C, which retain the proposed functionality of SSE5, but encode the instructions differently for better compatibility with Intel's proposed AVX instruction set. "
 
Zuletzt bearbeitet:
Wadenbeisser schrieb:
Ist dir selbst noch nicht aufgefallen das dein beispiel für deine Argumentation für die Tonne ist?
Das Kompliment kann ich zurück geben.

Wenn Intel das Auto (Hardware) entwickelt hat und AMD die Rechte für der Nutzung erhalten hat dann frage ich mich warum sie nicht mit der glechen Bereifung (Befehlssätze) auf der gleichen Straße (Software) fahren dürfen sondern dafür eine erheblich schlechtere vorgeschrieben wird obwohl eine gleichwertige vorhanden wäre.
Wo schreibt Intel irgendjemandem vor die gleiche Bereifung nutzen zu müssen?

Damit schließt sich dann wieder der Kreis zu meinem Beispiel. ;)
Zu meinem auch.

Regt man sich im AMD- Lager hier ernsthaft auf, dass einem hier keine spezialisierten Softwarelösungen auf dem Silbertablett serviert werden?
Nachdem man minimum 15 Jahre verschlafen hat, seine eigene Software für dir eigenen Prozessoren zu entwickeln?

Das ist erbärmlich und ein Armutzszeugnis...

Du ignorierst fleißig das die Hardware und Software zur Ausführung vorhanden ist aber deren Nutzung bei der Konkurrenz künstlich verhindert wird. Passt halt nicht zum eigenen Konzept.
Und Du igorierst fleißig, dass Intel in keiner Art und Weise verpflichtet ist, Software und Bibliotheken für einen Fremdhersteller zu entwickeln.

So nebenbei, Intel hatte schonmal wegen Compiler Tricks zur Wettbewerbsverzerrung bei regulärer Software einen vor den Latz bekommen und auch die Umstände waren damals ähnlich.
Das hat man versucht und ist wie immer offiziell daran gescheitert.

LG
Zero
Ergänzung ()

Iscaran schrieb:
Außerdem stellt ja schon allein die NICHT-Verwendung eines "optimierten" Instruction Sets das zudem als Standard definiert ist in meinen Augen eine ganz klare Performancebremse dar.
Natürlich bremst es die Performance für den Fremdprozessor, wenn man dessen Fähigeiten nicht abfragt und nicht nutzt. Das habe ich doch selbst in meinem reverse Enginering- Beitrag bereits herausgestellt.

Eine AMD CPU kann ja das optimierte Instruction Set AVX ganz genauso wie eine Intel CPU.
Behauptest Du. Sind die Schaltungen und das Laufzeitverhalten identisch?

Sie wird nur nicht dazu aufgefordert dieses zu benutzen weil die Vendor ID Abfrage, diese Verhalten seitens der MKL blockiert.
In Deiner "einfachen" Welt funktioniert das so, genauso wie ich einen übertakteten 9900K auch auf einem Z170 Mainboard laufen lassen kann. Oder einen 3950x auf einem klapprigen B350.

Das ist absichtliches Pessimieren eines "Konkurrenten" bzw. Vorenthalten gemeinsamer Standards nur weil nicht der passende "Sticker" auf dem Produkt ist.
Das ist doch eine reine Unterstellung/Vermutung Deinerseits.
Ruf die Leute von Intel an und gib denen eine Generalbürgschaft für die Funktion auf anderen Prozessoren und für die Kosten an Support, die das für sich nachziehen kann.

Ich weiss, dass Du trotz Deiner 100%ige Überzeugung zu feige dafür bist, den Kopf dafür hinzuhalten. Solange man im Warmen sitzt, kann man den Eskimos vortrefflich moralische Tipps verteilen.

Der Autovergleich mit den Notreifen vs. Normalreifen ist leider ziemlich nahe dran an dem was da läuft.
Absoluter Blödsinn. Wenn es irgendetwas gibt, bei dem der Hersteller selbst entscheiden kann, was Sache ist, dann ist es Software. Als ob Intel AMD vorschreiben würde, den Intel Compiler oder deren Bibliotheken nutzen zu müssen. Auf diesen Link bzw. Referenz bin ich echt gespannt.
Noch weltfremder gehts nicht.

EDIT: Ansonsten kann ich da wirklich nur empfehlen müssen wir User druck auf die Entwickler ausüben und bis diese den Druck sich hier "vernünftig" zu verhalten auch gegenüber Intel ausüben. Oder die Entwickler eben auf die Verwendung einer absichtliche diskriminierenden Software pfeiffen und sich eben gleich ordentlich Standards zuwenden - auch wenn diese in manchen Fällen langsamer auf Intel CPUs laufen....tja da schiesst man sich halt eben selbst ins Bein (als Firma Intel).
Und wieso ist es plötzlich korrekt und moralisch in Ordnung, dass AMD den Usern Standards verwehrt, wie DXR? Wird hier auch von absichtlicher "Pessimierung" gesprochen?
Kommt doch mal bitte in der Realität an und bewegt Euch aus Eurer sektenartigen Blase raus!

Im übrigen wurden AVX gemeinsam von Intel und AMD im July 2008 entwickelt und eingereicht:
https://de.wikipedia.org/wiki/Advanced_Vector_Extensions
"Advanced Vector Extensions (AVX) ist eine Erweiterung des x86-Befehlssatzes für Mikroprozessoren von Intel und AMD, die von Intel im März 2008 vorgeschlagen wurde. "
Peugeot und Citroen nutzen im Zuge des PSA- Konzerns auch die gleichen Plattformen für ihre Autos.
Müssen sie deswegen gleich sein?
Denkt doch einfach mal ein wenig weiter....

LG
Zero
 
Zuletzt bearbeitet:
AMD's CPUs können auch AVX2, also muss Intel das in seiner Software voll unterstützen, ansonsten sind sie böse Saboteure. Auf die Logik muss man erstmal kommen. an den Kopf klatsch
 
  • Gefällt mir
Reaktionen: .Sentinel.
@ZeroZerp

Ah du willst es nicht bzw. falsch verstehen. ;)
Intel schreibt hier vor das die Konkurrenz eine deutlich schlechtere "Bereifung" zu bekommen hat obwohl sie alle Vorauusetzungen für die richtige besitzen.

Aber wie wäre es wenn Intel bei modernen Spiele untersagt werden würde den x64 Befehlssatz nutzen zu können obwohl Hard- und Software es unterstützen? Das ist aber vermutlich was gaaanz anderes, gelle?
 
Wadenbeisser schrieb:
Ah du willst es nicht bzw. falsch verstehen. ;)
Intel schreibt hier vor das die Konkurrenz eine deutlich schlechtere "Bereifung" zu bekommen hat.
Wie kommst Du eigentlich auf die schiefe Ebene, dass AMD die schlechte Bereifung von Intel überhaupt verwenden muss? Die haben doch ein ansonsten überlegenes Rennfahrzeug im Rennen?

Wären aber plötzlich zu blöd eigene Reifen dafür zu entwickeln? Und Intel ist schuld daran?
Na das musst Du mir mal erklären...
Intel schreibt hier garnix vor. Niemand wird gezwungen deren Software zu nutzen.

LG
Zero
 
@ZeroZerp

Weil du trotz des aufgeschlüsselten und von dir mit zitierten Vergleichs ignorierst das die Bereifung für den Befehlssatz steht. ;)
Zudem ignorierst du konsequent das es nicht um eine Optimierung für die Architektur der Konkurrenz sondern lediglich um die Nutzung des vorhandenen und unterstützten Funktionsumfangs geht. Die Nutzung vorhandener Standards ist keine Optimierung, dafür sind Standards schließlich da.
 
  • Gefällt mir
Reaktionen: Iscaran
Also ich verabschiede mich aus dem Thread offiziell. Mir wird das hier zu dämlich.

Da hatte ich mit Impfgegnern und Kreationisten schon ergiebigere Diskussionen.

Viel Spass noch...
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: ghecko, Iscaran und .Sentinel.
Ned Flanders schrieb:
Also ich verabschiede mich aus dem Thread offiziell. Mir wird das hier zu dämlich.

Ich folge deinem Beispiel. Wir drehen uns eh im Kreis. Die Mods dürften ohnehin hier bald dicht machen.
 
  • Gefällt mir
Reaktionen: .Sentinel.
Bin dabei- Ab jetzt kommt nur Blödsinn raus.

Wobei das hier
Da hatte ich mit Impfgegnern und Kreationisten schon ergiebigere Diskussionen.
halt auch überflüssig ist... ;)
Nach unserem Fazit kann ja auch nicht mehr "mehr" dabei rumkommen.
 
ZeroZerp schrieb:
Und wieso ist es plötzlich korrekt und moralisch in Ordnung, dass AMD den Usern Standards verwehrt, wie DXR? Wird hier auch von absichtlicher "Pessimierung" gesprochen?

Häh `???

AMD "verwehrt" doch niemandem DXR! Das ist überhaupt kein Vergleich mit der Pessimierung der MKL.
Sie können es (DXR) nur nicht. Wenn du es brauchts, dann wirst du eben eine nVidia Karte kaufen müssen die das explizit bereits kann. Ich schreibe bereits. Denn Navi2x bzw. RDNA2 wird ebenfalls DXR können.
Das wäre imho wenn AMD eben sagt. Die CPU kann kein AVX. Dann benutzt MKL dieses eben nicht.
Genau das Gegenteil ist aber der Fall. Die CPU kann das Standardfeature AVX - die Software nutzt es aber nicht.

Das entspräche also eher dem Fall du hast eine 2080 Ti und Microsoft sagt: "Ne die Karte darf DXR-Feature in DX12 nicht nutzen, weil ....ist halt so".

EDIT: Außerdem wird der Feature Stand der Hardware ja Offen kommuniziert.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Heschel und Ned Flanders
@Iscaran

Egal denn kein Vergleich ist für die "aber die" Taktik zu sehr an den Haaren herbei gezogen. ;)
 
  • Gefällt mir
Reaktionen: Iscaran und Ned Flanders
Also ich muss da @Ned Flanders absolut zustimmen.

Eine wirklich merkwürdige Logik wird hier vertreten.

Vendor-ID Abfragen sind absolut in Ordnung laut eurer Logik. Also wäre es ja auch nur in Ordnung wenn AMD solche Bremsklötze in ihre x86-64 Befehlssatzerweiterung gebaut hätte.

Treiben wir es noch weiter, zukünftige Software, sponsored by Firma X, wird durch die Vendor ID Abfrage auf Firma Y nicht mehr lauffähig sein.

Solch ein Verhalten sollte kritisiert werden und nicht als "in Ordnung" angesehen werden. Sonst kann man das Medium PC bald völlig in die Tonne kloppen.
 
  • Gefällt mir
Reaktionen: Heschel
Ein solches Verhalten ist ganz einfach eines der kundenfeindlichsten Verhalten schlechthin und dient einzig und allein der Wettbewerbsverzerrung indem es den selbigen unterbindet.
Für den Kunden bedeutet es am Ende immer zu viel für überteuerte Produkte zu bezahlen.

So gesehen ist es tatsächlich besser wenn sie die konkurrenz Modelle komplett geblockt hätten denn es kommt am Ende auf das Gleiche raus, macht das Vorgehen aber offensichtlich.

Damit bleibt am Ende nur der fade Beigeschmack der Wettbewerbsverzerrung durch künstliche und versteckte Ausbremsung der Konkurrenz.
 
  • Gefällt mir
Reaktionen: Argoth, Iscaran und aldaric
ZeroZerp schrieb:
Gerne- Intel erfindet das Auto (Hardware) und übergibt AMD das Recht dazu, dieses auch herstellen zu dürfen.
Nun überlegt sich Intel aber, wie man das Auto optimal auf der Straße hält. Unter Anderem optimieren sie die Gummimischung in den Reifen, so dass das Auto geradezu auf der Straße klebt (Software).
Anschließend wird die Radaufhängung so modifiziert, dass die Reifen nicht auf das Konkurrenzmodell passen.
Wie oft wechselst du die Reifen beim Fahren?

Wie oft wechselt der Codepfad zwischen SSE/AVX etx. während der laufzeit?

Bestimmt wesentlich öfter als du die Reifen wechselst.. daher hinkt der Vergleich ziemlich imho.

Es gibt nicht DEN Reifen, genauso wenig wie es DIE Befehlssatzerweiterung gibt.
 
Ned Flanders schrieb:
Sehr schön, dann schaffen wir es ja endlich hier darüber überein zu kommen, dass wir darüber nicht übereinkommen.
Ich bin fasziniert das du dir das hier antust.
Ich werte deine Zeit als viel zu wertvoll um hier im Forum Idioten zu belehren. Das solltest du auch.
Ned Flanders schrieb:
Also ich verabschiede mich aus dem Thread offiziell. Mir wird das hier zu dämlich.
Ups, ich komme zu spät.
 
  • Gefällt mir
Reaktionen: Ned Flanders
Ich bin gespannt wann diese Konstelation mal wieder auftritt. Ich würde ja Einige gern bei der Vorstellung des nächsten Telefons mit geschlossenem Bootloader, Winows only Software, Konsolenspiel und Plasterouter wiedersehen. Mit dem selben Elan bitte :)


@Ned Flanders
Wo AMD mit mischt ist glaube https://github.com/flame/blis wo AMD auch ein eigenen Fork pflegt: https://github.com/amd/blis
Da ist AMD mit dem Aufkommen von Zen deutlich aktiver geworden. Was ich sehr begrüße
 
  • Gefällt mir
Reaktionen: Ned Flanders
Hm, meine Uni hat aktuell Matlab 2019a. Schätze mal, dann muss ich mir den Workaround ansehen, wenn ich Matlab/Simulink auf dem Ryzen-Laptop schneller laufen lassen möchte.
 
  • Gefällt mir
Reaktionen: Ned Flanders
Zurück
Oben