News Intel MKL: Matlab R2020a beinhaltet offiziellen AMD-Workaround

[Teralios]

Mir ist an der Stelle nicht ganz klar warum Intel dafür in irgendeiner Form haftbar oder verantwortlich wäre, wenn Via oder AMD die von Intel lizensierte SIMD Extension fehlerhaft umsetzen.

Ich habe nun lange genug im Support gearbeitet und da auch Erfahrung gemacht, dass ich weiß, dass man in der Regel sich das erst beste Opfer sucht, statt mal nach zuschauen, woran es denn wirklich hakt.

Wie oft darf ich mir anhören, dass Hersteller X, Y oder Z scheiße ist, obwohl das Problem an einer ganz anderen Stelle ausgelöst wurde oder vor dem Monitor sitzt.

Selbst als "Entwickler" kenne ich es, dass man auf mir rum hackte, obwohl das Problem an ganz andere Stelle ausgelöst wurde. Und das nur, weil ja manche Menschen nach dem Motto handeln, dass etwas nicht sein kann, was nicht sein darf.

Aber mir geht es da auch um das US-System, ich kenne da zu viele wilden Storys. Am Ende hat man zwar oft recht, aber musste erst mal Anwälte bemühen.

Es ist aber nur eine "mögliche" Ansicht, die durch meine Erfahrungen mit Kunden/Nutzern im Support geprägt ist.

Wenn Intel sich normal verhalten würde (im Sinne von keine solchen den Mitbewerb ausschließenden Merkwürdigkeiten verteilen), dann wären sie auch eine Company wie alle anderen auch.

Ich kenne das leider etwas anders. Dieses "Ausschließen" von Mitbewerbern hat leider in der letzten Zeit überhandgenommen, weil jeder um Kunden kämpft und diese möglichst halten will. Da werden einem immer mehr Steine in den Weg gelegt.

Schade ist es, aber Intel und nVidia sind hier nur sehr prominente Beispiele.

Das Argument, das Intel die MKL auf AMD validieren müsste gilt zum einen auch so, denn der SSE Codepfad unterscheidet sich in der Hinsicht ja nicht vom AVX Codpfad, zum anderen gilt das für alle Hersteller von Hardware, aber Intel ist der einzige, der meint einen Vendor Check des Systems durchführen zu müssen.

Oh, da stimme ich dir absolut, habe ich ja auch in meinem Beitrag.

Die eigentlichen Optimierungen - also die Vektorisierung - ist in weiten Teilen in jedem Pfad gleich und die eigentliche Hauptarbeit. Die spezifischen SSE, AVX und AVX512 "Optimierungen" wiederum sind 08/15 und selbst ein Anfänger in der Lehre versteht dahinter die Konzepte.

Also ja, der Vendor-Check hier ist absolut unnötig und du hast recht - aus meinen Augen - hier findet eine ungerechtfertigte Benachteiligung statt.

So eine Vendor String Abfrage brauchts doch in diesem Fall garnicht, die sorgt nur für massenhaft negative Presse und mach AMD ohne deren eigenes Zutun zum Robin Hood. Das lohnt sich doch nie!

Anscheinend ja doch. Es ist ja nicht nur Intel die so handeln. nVidia ist da auch immer als prominentes Beispiel zu nennen bei den GameWorks-Effekten.

Und du siehst doch auch hier, dass es genug Nutzer gibt, die Intel als auch nVidia verteidigen. Die Welt ist leider nichts für Idealisten und ebenso nichts für idealistisches Verhalten. Auch eine Lektion, die ich leider nun lernen musste.

Da es sich um lizenzierte SIMD Erweiterungen handelt, ist das Argument meiner Meinung nach nicht gültig. Mit der selben Argumentation könnte man ja auch die Nutzung von SSE unterbinden und irgendwann landen wir dann beim 8086

Es war auch nur ein Gedankenspiel und wie man es sehen kann. Deswegen hab ich mir ja die MKL angeschaut und mal die einzelnen Funktionen angesehen, wo die Unterschiede liegen usw.

Stellt für mich wie es Ned Flanders ausdrückt eine "Pessimierung" dar und damit einen legitimen Grund zur Kritik.

Für mich auch, ich dachte, es wäre raus gekommen, als ich im letzten Absatz schrieb, dass die eignetlichen Unterschiede oft nur den Aufruf der spezifischen x86-Befehle geschuldet sind, in weiten Teilen aber die eigentlichen Optimierungen zur Vektorisierung die gleichen sind und man am Ende mit SSE kompliziert die einfacheren AVX und AVX512-Befehle nachbildet.

Deswegen noch mal: In dem Fall stimme ich den Kritikern zu. Die eigentlichen Optimierungen für die Vektorisierung sind sowohl für Intel als auch andere Hersteller vorgenommen worden. Es gibt keine spezifischen Optimierungen auf AVX oder AVX512, sondern nur, dass man da Befehle nutzt, die hier in wenigen Takten durchgeführt werden, während man bei SSE durch das Verbinden von Befehlen mehrere Takte benötigt.

Ich befürchte da muss ich leider widersprechen, jahrelanges "AMD ist scheiße in MATLAB/SciPy etc" ist wohl effektiver als die paar Leute, die jetzt davon erfahren wie das zustande gekommen ist.

Ist es immer. Vollste Zustimmung.

 

[Schattenspender]

@Ned Flanders

Wenn Intel jetzt den Debug Modus entfernen würde dann wäre klar, das sie AMD ausbremsen wollten. Der Debug Modus ist vorhanden und der Workaround ist nicht auf ihrem "Mist" gewachsen. Also keine Verantwortung dafür.

Wenn Sie es machen würden, dann müssten sie sich schon ne ganz ganz mächtig gute Begründung dafür einfallen lassen.


@Teralios

Was den Entwickler als Prellbock angeht, da hast du sicherlich recht. Nur in diesem Falle beschreibt Intel die MKL eindeutig als für Intel CPUs vorgesehen. Und da muß man sich als Programmierer schon mal fragen "Und was passiert mit dem Rest?"

 

[Ned Flanders]

Nur in diesem Falle beschreibt Intel die MKL eindeutig als für Intel CPUs vorgesehen. Und da muß man sich als Programmierer schon mal fragen "Und was passiert mit dem Rest?"

Wohl der Hauptgrund dafür das Intel auf der ersten Seite des Developer Guides schreibt: "... also performs well on non Intel processors" womit ein Grossteil der Fragen wohl erstmal ausgeräumt sind.

Ich will Matlab beispielhaft auch garnicht aus der Verantwortung entlassen. Im Gegenteil, die haben bislang wohl einfach gepennt oder es war ihnen egal, oder beides.

Wie sagt man auf Englisch so schön: Never attribute to malice that which is adequately explained by stupidity.

 

[Helle53]

Es verwundert mich schon sehr das hier nur auf Abfrage(n) des Instruction-Sets herumgeritten wird. Zu einer maximalen Optimierung gehört doch wesentlich mehr. Als Beispiel habe ich mir mal die mkl_avx2.dll von numpy angeschaut. Diese DLL enthält genau 2 CPUID-Abfragen:
http://www.mdcc-fun.de/k.helbing/MKL/MKL_CPUID.PNG
Die erste Abfrage ist der Vendor; na klar. Die zweite (eax=2) bei Intel_CPUs betrifft Cache und TLB-Infos; zwingend notwendig z.B. für optimales Prefetching. Nun kommts: Diese Abfrage mit eax=2 existiert bei AMD-CPUs nicht ("Reserved")! Es gibt sicher noch weitere Differenzen, die durchaus ein optimales Code-Abarbeiten auf AMD-CPUs verhindern (muss nicht, kann aber).
Ich bin AMD durchaus nicht abgeneigt, aber Intel hier an den Pranger zu stellen finde ich unfair. AMD sollte endlich mal einsehen, das man mit eigener Software durchaus publikumswirksam punkten kann. Wer eine AMD-Grafikkarte nutzt wird dafür ja auch keine Nvidia-Treiber vewenden wollen !

 

[.Sentinel.]

AMD sollte endlich mal einsehen, das man mit eigener Software durchaus publikumswirksam punkten kann.

This! Genau darum geht es.
Viele heulen z.B. wegen nvidia- Exclusives wie die Gameworks- Libraries rum.
Aber die kümmern sich halt einfach massivst mit ihrer Software und der Unterstützung von Entwicklern darum, dass ihre Karten glänzen können und dass das Zeug implementiert wird. Ist ja auch hübsch anzusehen!

Dem Hersteller daraus einen Strick drehen zu wollen oder zu fordern, dass die Entwicklungen Allgemeingut sein sollten bzw. für die Konkurrenz optimiert nutzbar etc., ist einfach nicht rational begründbar.
Es geht ums Geschäft bzw. Alleinstellungsmerkmale. Das sind Wirtschaftsunternehmen, die davon leben.
Dazu gehört sowohl die Hardware, als auch die dafür entwickelte Software.

Und ja- Es geht natürlich auch um Kundenbindung. Ganz klar- Ein wichtiger Pfeiler, wenn man ein Unternehmen führt.

LG
Zero

 

[Iscaran]

Es verwundert mich schon sehr das hier nur auf Abfrage(n) des Instruction-Sets herumgeritten wird. Zu einer maximalen Optimierung gehört doch wesentlich mehr. Als Beispiel habe ich mir mal die mkl_avx2.dll von numpy angeschaut. Diese DLL enthält genau 2 CPUID-Abfragen:
http://www.mdcc-fun.de/k.helbing/MKL/MKL_CPUID.PNG
Die erste Abfrage ist der Vendor; na klar. Die zweite (eax=2) bei Intel_CPUs betrifft Cache und TLB-Infos; zwingend notwendig z.B. für optimales Prefetching. Nun kommts: Diese Abfrage mit eax=2 existiert bei AMD-CPUs nicht ("Reserved")! Es gibt sicher noch weitere Differenzen, die durchaus ein optimales Code-Abarbeiten auf AMD-CPUs verhindern (muss nicht, kann aber).
Ich bin AMD durchaus nicht abgeneigt, aber Intel hier an den Pranger zu stellen finde ich unfair. AMD sollte endlich mal einsehen, das man mit eigener Software durchaus publikumswirksam punkten kann. Wer eine AMD-Grafikkarte nutzt wird dafür ja auch keine Nvidia-Treiber vewenden wollen !

Aber das passt doch wunderbar. Warum also die Vendor ID prüfen ? Wenn man hinterher konkret abfragt. Wenn AMD CPUs hier nicht alles zurückliefern per Abfrage und man deshalb nur einen "Generischen" oder "nicht-optimierten" AVX Pfad nimmt. Ist doch alles in Butter. Diese interne auf Cachegröße etc. INTEL spezifische Optimierung spricht doch niemand ab.

Nur daß das halt nicht 200% Leistung ausmacht wie der Unterschied zwischen generischem SSE-Pfad und Generischem AVX-Pfad.
Etwas das hier die MKL JEDEM non-Intel Prozessor aufdrückt, und zwar nur weil vor der gezielten Abfrage die generische Vendor ID geprüft wird.

So etwas nennt man wohl schon absichtliche Pessimierung.

 

[.Sentinel.]

So etwas nennt man wohl schon absichtliche Pessimierung.

Genau- Gegen die nichts einzuwenden ist, da es sich um einer herstellerspezifische Software handelt.
So wäre es von AMD auch legitim ebenso Bibliotheken zu entwerfen, die auf Intel Prozesoren überhaupt nicht laufen. Also sogar einen waschechten Vendor- Lock darstellen würden.

Und wenn man Intels Seite aufruft, wird auch völlig klar, für welche Produkte diese Bibliothek entwickelt wurde:
https://software.intel.com/en-us/mkl

Das heißt es wäre auch dann legitim, WENN man absichtlich pessimieren würde, was sie allerdings nicht tun, da sie lediglich den Zusatzaufwand nicht betrieben haben die Featureset- Abfragen für andere Hersteller optimiert ablaufen zu lassen. Es ist eine Abfrage Intel Ja/Nein.
Alles andere wäre ein Zusatzaufwand, für den den Intel keine Veranlassung hat, ohne sich Bösartigkeit unterstellen lassen zu müssen, diesen zu betreiben.

Es wäre etwas komplett anderes, dass wenn die Abfrage auf den anderen Hersteller verweist, dahingehend gehandelt würde, dass manipulierend in die Verarbeitung eingegriffen wird. Sprich ein kompatibler Codepfad aktiv ausgebremst würde.

Diesbezüglich gehen die Meinungen aber wohl einfach auseinander.
Ich mache da aber keinen Hehl draus (ist ja auch offensichtlich), dass ich das aus der Entwickler- Sicht bzw. Hersteller- Sicht sehe.
Schließlich ist es meine Software, welche von meinen Mitarbeitern von meinem Geld entwickelt wurde, um mein Produkt zu komplementieren

LG
Zero

 

[Ned Flanders]

da sie lediglich den Zusatzaufwand nicht betrieben haben die Featureset- Abfragen für andere Hersteller optimiert ablaufen zu lassen. Es ist eine Abfrage Intel Ja/Nein.

Zero, eine Feature Set Abfrage muss man nicht optimieren. Und das einzige wo sie Arbeit zusätzlich reingesteckt haben ist die Venor ID Abfrage. Wenn man den Vendor String patched, läuft die Feature Set Abfrage 1a.

Ich verstehe, dass wir eine unterschiedliche Sichtweise auf das Ganze haben und ich find das auch ok, aber bitte nicht ständig davon ausgehen, dass Intel hier den extra Aufwand der Optimierung auf AMD scheut. Das müssen sie nicht und sie scheuen auch nicht den Extraaufwand zu pessimieren.

 

[Argoth]

Kannst du bitte einen Autovergleich machen.

Die Analogie stimmt aber insofern nicht überein, als dass eben Intel die Logik nie geändert hat.
Und VW hätte dafür sorgen müssen, dass deren Auto eben nicht nur im ersten Gang fährt oder das Getriebe reklamieren. Das muss denen doch SOFORT auffallen.
Ansonsten sind sie unfähig oder einfach nur unaufmerksam bzw. uninteressiert.

Meine Analogie war so gemeint:
Logik Verändert im sinne von, von Anfang an zu ungunsten der Lizenzierten Mitbewerber.

1. Gang - x86/x64
2. Gang - SSE/SSE2..
3. Gang - AVX
4. Gang - AVX2
5. Gang - AVX512

Je nach gefahrener Strecke/Testszenario brauchst du nur die ersten 2 Gänge. Pauschal für alle Testfälle "weil jedes Auto 2 Gänge hat" nur die ersten zwei zu verwenden ist aber fraglich.
Insbesondere dann, wenn der Fahrer/Automatik (MKL) auch die anderen (nach Lizenzen gebauten) Gänge gekennzeichnet sieht, ihm aber das Ford (Intel) logo fehlt. Ja es ist für den Anwender dann u.U. nicht so einfach den Fahrer als Problem zu erkennen, wenn er von der Industrie als quasi Standard anerkannt ist.
Und wenn jetzt beim Verwenden einer dieser unter Lizenz gebauten Gänge das Auto Kaputt geht, ist es ja nicht im Zusammenhang mit Ford sondern VW.

Ich hoffe es ist mit dieser Ausführung besser verständlich worauf ich hinaus wollte.

 

[.Sentinel.]

Zero, eine Feature Set Abfrage muss man nicht optimieren. Und das einzige wo sie Arbeit zusätzlich reingesteckt haben ist die Venor ID Abfrage. Wenn man den Vendor String patched, läuft die Feature Set Abfrage 1a.

Alles gut... Dabei darf man aber auch nicht vergessen, dass man das Testing auch auf die Via Prozessoren, Haoxin WuDaoKou und was weiss ich auch noch immer durchführen müsste.

Erbesenzählerei, ich weiß. Dennoch- Ich empfinde das nicht im geringsten als anstößig, gemein oder gar manipulierend, dass man seine eigene Bibliothek gegenüber den Mitbewerbern dann in einen Kompatiblitätsmodus schaltet, ohne speziell auf deren Fähigkeiten einzugehen.

So hält man sich potenziell einen haufen Ärger vom Hals.
Und wenn sie die Vendor Abfrage rausnehmen und ein Prozessor aus was für einem Grund auch immer, dann falsch rechnet oder irgendein anderer Mist passiert. Was darf sich Intel dann erst anhören?

Manipulationsvorwürfe sind da noch das Geringste...
Ich würd das Risiko ehrlich gesagt auch nicht gehen und auch keinen Zusatzaufwand für eine geänderte/mehrfach gestaffelte Abfrage gehen warum auch?

LG
Zero

Ergänzung (3. April 2020)

Insbesondere dann, wenn der Fahrer/Automatik (MKL) auch die anderen (nach Lizenzen gebauten) Gänge gekennzeichnet sieht, ihm aber das Ford (Intel) logo fehlt.

Nur umfasst die Lizenz eben nicht, dass Intel seine gesamte Softwarebatterie auf AMD Prozessoren optimal lauffähig macht.

LG
Zero

 

[Ned Flanders]

Manipulationsvorwürfe sind da noch das Geringste...
Ich würd das Risiko ehrlich gesagt auch nicht gehen und auch keinen Zusatzaufwand für eine geänderte/mehrfach gestaffelte Abfrage gehen warum auch?

Wie gesagt, ich hab da kein Problem mit anderen Meinungen. Mich stören dabei nur Falschaussagen, wie "müssen ja nicht auf AMD optimieren". Klar müssen sie nicht. Das hat nie einer verlangt.

Aber auch an Dich nochmal interessehalber die Frage wie du zu dem oben zitierten stehst wenn Intel jetzt den Debug Mode entfernen würde. Wäre das dann immernoch eine Frage Support, denn der Debug Mode ist inoffiziell und damit so oder so nicht supportet... Oder wäre das dann auch in Deinen Augen ein klares Indiz das Intel mit der Vendor Abfrage non Intel einfach performance seitig bremsen will.

In meinen Augen das beste wäre, und das hab ich hier schonmal geschrieben, wenn Intel entweder nicht mehr nach Vendor diskriminiert oder aber wenn Intel die Lauffähigkeit der MKL auf non Intel Systemen einfach aufhebt, alla CUDA.

 

[.Sentinel.]

Wie gesagt, ich hab da kein Problem mit anderen Meinungen. Mich stören dabei nur Falschaussagen, wie "müssen ja nicht auf AMD optimieren". Klar müssen sie nicht. Das hat nie einer verlangt.

Muss ich an den ursprünglichen Code Hand anlegen und sei es nur ein Byte, das zu ändern wäre, ist es abseits eines Kompatibilitätsmodus bereits ein Optimieren auf eine andere Hardware hin.
Wie gesagt- Es gibt ja auch noch andere X86 Prozessoren.

Oder wäre das dann auch in Deinen Augen ein klares Indiz das Intel mit der Vendor Abfrage non Intel einfach performance seitig bremsen will.

Wie gesagt- Ich sehe einen Unterschied in der expliziten Ausnutzung von Features, also eine Anpassung, dass auch andere Systeme abseits maximaler Kompatibilität nach ihren Features möglichst schnell laufen und einem aktiven Einbremsen.

In meinen Augen das beste wäre, und das hab ich hier schonmal geschrieben, wenn Intel entweder nicht mehr nach Vendor diskriminiert oder aber wenn Intel die Lauffähigkeit der MKL auf non Intel Systemen einfach aufhebt, alla CUDA.

So sieht es aus.

Wobei ich da wieder unterscheide. Es ist in meinen Augen kein Diskriminieren, da der Konkurrenzhersteller der CPUs nicht auch nur den geringsten Anspruch gegenüber der Funktionalität dieser Bibliothek auf seiner Hardware hat.

Die Bibliothek ist auf anderen CPUs im "Kompatibilitätsmodus" einsatzfähig und wird in ihrer Standardfunktionalität auch nicht eingebremst.
Es werden aber Extensions Außen vorgelassen. Und wenn Intel ein Strick draus gedreht wird, dass sie die Software auf Fremdhardware funktional lassen, aber nicht ausreizen, dann würde ich an Stelle Intels tatsächlich die Unterstützung für Fremdcpus vollständig streichen, schon allein um jeder Negativunterstellung aus dem Weg zu gehen.

Aber das sind nur meine 2 cents... und ich sehe ein, dass das ganze "streitbar" ist.

LG
Zero

 

[Ned Flanders]

Wie gesagt- Ich sehe einen Unterschied in der expliziten Ausnutzung von Features, also eine Anpassung, dass auch andere Systeme abseits maximaler Kompatibilität nach ihren Features möglichst schnell laufen und einem aktiven Einbremsen.

Du beantwortest meine Frage leider nicht. Nochmal, wäre des entfernen des Debug Modes für Dich ein Indiz das Intel auf keinen Fall auf non Intel Systemen schnellen Code ausgeworfen sehen will? Die Frage nach dem Support wäre ja hinfällig. Mir reicht da ein Ja/Nein.

Diskriminieren bedeutet unterscheiden und die MKL unterscheidet nach Vendor String ist also nach Vendor String diskriminierend. Du hast wirklich Schwierigkeiten ein schlechtes haar an Intel zuzulassen, do you?

Muss ich an den ursprünglichen Code Hand anlegen und sei es nur ein Byte, das zu ändern wäre, ist es abseits eines Kompatibilitätsmodus bereits ein Optimieren auf eine andere Hardware hin.

Gut, dann wirst du ja sicherlich auch anerkennen, dass das Programieren einer Vendor String Abfrage und einem Jump to SSE eine Pessimierung ist. Und auch wenn man dafür verständnis aufbringen will, wie in deinem Fall, so muss man immernoch erkennen, dass das ein einzigartiger Vorgang ist.

Ansonsten einigen wir uns doch einfach drauf das wir uns nicht einigen können. Die Argumente sind ja bereits mehrfach ausgetauscht. Ich habe damit kein Problem.

 

[ZeroStrat]

Gut, dann wirst du ja sicherlich auch anerkennen, dass das Programieren einer Vendor String Abfrage und einem Jump to SSE eine Pessimierung ist.

Mir stellt sich die Frage, was dein Motivation ist. Meinst du, dass Intel in irgendeiner Form (moralisch, juristisch) verpflichtet ist, AMD Prozessorren vollumfänglich zu supporten?

AMD sollte sich bemühen was eigenes auf die Beine zu stellen. Das ist meine Meinung dazu.

 

[Tzk]

AMD sollte sich bemühen was eigenes auf die Beine zu stellen. Das ist meine Meinung dazu.

Du meinst sowas wie AMD AOCL?
https://developer.amd.com/amd-aocl/

nützt nur nix wenn das keiner in sein Produkt einbaut...

 

[aldaric]

Mir stellt sich die Frage, was dein Motivation ist. Meinst du, dass Intel in irgendeiner Form (moralisch, juristisch) verpflichtet ist, AMD Prozessorren vollumfänglich zu supporten?

Nach dem Cross-Licensing Abkommen ist Intel dazu verpflichtet keine Maßnahmen zu treffen, die irgendwie die Leistung von Produkten anderer Hersteller bremsen. Das tut die Vendor-ID Abfrage jedoch. Denn AVX ist Teil dieses Abkommens.

AMD sollte sich bemühen was eigenes auf die Beine zu stellen. Das ist meine Meinung dazu.

AMD hat sowas schon längst, was das aber mit der Intel MKL und der Vendor-ID Abfrage zu tun hat, musst du uns dann mal erklären.



Ihr würdest es dann wohl auch ganz toll finden, wenn AMD die x86-64 Befehlssatzerweiterung mit solchen Maßnahmen torpedieren würde ? (Achtung, überspitzt dargestelltes, beispielhaftes Argument)

 

[ZeroStrat]

Du meinst sowas wie AMD AOCL?
https://developer.amd.com/amd-aocl/

nützt nur nix wenn das keiner in sein Produkt einbaut...

Diese Lib wurde ja schon häufiger erwähnt in diesem Thread. Das ist mir auch bekannt. Es geht auch darum, dass AMD die Software attraktiv macht und für eine Verbreitung sorgt. Vieles wird stiefmütterlich behandelt, dass sogar OpenSource Projekte teilweise besser sind als das, was AMD macht. Dabei entsteht die Software sogar unter widrigeren Umständen (keine oder kaum Dokumentation).

Nach dem Cross-Licensing Abkommen ist Intel dazu verpflichtet keine Maßnahmen zu treffen, die irgendwie die Leistung von Produkten anderer Hersteller bremsen. Das tut die Vendor-ID Abfrage jedoch. Denn AVX ist Teil dieses Abkommens.

Irgendwie dreht sich die Diskussion auch im Kreis. @Piktogramm hat doch analysiert, dass es gar keine Vendor-Abfrage gibt. Also jetzt doch? Mir war das selbst gar nicht bekannt. Außerdem werden hier juristische Dinge als selbstverständlich angenommen, wo ich große Schwierigkeiten habe, das genau so zu sehen. Wo sind denn die eindeutigen Belege dazu? Es wäre auch wichtig, dass das von Rechtsexperten beurteilt wird und nicht von Laien wie uns. Einfach zu sagen, ja, das ist das gleiche wie bei den Compilern damals, passt halt hinten und vorne nicht.

 

[.Sentinel.]

Nach dem Cross-Licensing Abkommen ist Intel dazu verpflichtet keine Maßnahmen zu treffen, die irgendwie die Leistung von Produkten anderer Hersteller bremsen

Genau- Welchen Vertragsgegenstand hat das Cross-Licensing Abkommen? Ist Intel dazu verpflichtet jedwede eigens- Programmierte Software optimal an AMD Prozessoren anzupassen?

Zweitens- Wo greift Intel aktiv "bremsend" ein? ->Genau überhaupt nicht.
Sie gehen lediglich bei anderen als Intel- Prozessoren in einen Kompatibilitätsmodus.

Wie inzwischen mehrfach angemerkt- Wir drehen uns hier im Kreis. Und es ist eben einfach nicht so eindeutig oder einfach, wie es hier von einigen dargestellt wird.

nützt nur nix wenn das keiner in sein Produkt einbaut...

Und das soll jetzt Intels Problem sein?

LG
Zero

 

[ZeroStrat]

Mir geht's übrigens nicht darum, Intel heilig zu sprechen, sondern eine neutrale Sichtweise auf die Dinge zu haben. Dass das hier teils ein bisschen aus dem Ruder gelaufen ist, auch meinerseits, bitte ich zu entschuldigen.

 

[Ned Flanders]

Meinst du, dass Intel in irgendeiner Form (moralisch, juristisch) verpflichtet ist, AMD Prozessorren vollumfänglich zu supporten?

Nein, deswegen schrieb ich ja bereits, dass eine der möglichen Lösungen ist, die Lauffähigkeit für nicht Intel CPUs komplett einzutellen. Das wäre transparent. Alternativ können sie die Vendor String Abfrage in Rente schicken. Beides fände ich praktikabel.

Ich schrieb auch bereits mehrfach, dass sich jeder hier in den allerwertesten beissen wird, wenn dieses Beispiel: Libraries intransparent nach Vendor kriterien bestimmtem performance outcome zuzuweisen schule machen würde. Projiziere das doch einfach mal abstrakt auf OCAT. ok, das war OSS und ich weiss nicht ob du dazu auch eine closed source AMD Basis verwendet hättest, aber eventuell hätte dir ja eine Aussage wie OCAT also works well on non AMD Graphics Cards erstmal gereicht sie zu benutzen.

Aber du würdest dich vermutlich jetzt nicht hinstellen und sagen, dass Nvidia halt was eigenes hätte programieren sollen wenn sie gewollt hätten das CFX auf Nvidia karten besser laufen sollte.

Was ich meine... wir wollen da einfach nicht hin. Das ist einfach eine bescheuerte Welt.