Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
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 nicht. Was machen Leute, die Matlab und nen Ryzen haben? Dann ginge ja gar nichts mehr. Intel könnte den Featuresupport voll freischalten, müssen sich aber nicht (meiner Einschätzung nach). Besser wäre es, AMD hat was eigenes, was MathWorks als Alternativpfad implementiert.
Ned Flanders schrieb:
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.
Hm, das geht ein wenig gegen "romantische Wunschvorstellung". Es wird ja immer was geben, was vendor-gebunden ist. Treiber z.B. oder Profiler mitunter. Ich hätte auch gerne, dass Nsight auf AMD Karten läuft, aber das wird nie passieren.
OCAT basiert übrigens auf PresentMon, was komplett Open Source ist. Sogar Nvidia nutzt PresentMon für ihr FrameView. Das ist aber auch kein Millionenprojekt.
Wir haben uns auch für PresentMon entschieden, weil es auf allen Systemen top läuft. Der Support von Intel ist auch top!
Zuletzt bearbeitet von einem Moderator:
(nie ergänzt)
Die aktuelle Version von Matlab hat die MKL 2019.3, also die ein jahr alte Version. Wenn Intel in der nächsten Version den Stecker zieht, dann hat Matlab also ein Jahr Zeit die OpenBLAS oder die aktuelle AMD Lib einzubinden. AMD würde da sicherlich behilflich sein. Beide Seiten haben Interesse daran, schon allein weil die aktuellen AMD CPUs in Matlab das schnellste sind was es für Geld zu kaufen gibt. Und AMD will die auch verkaufen.
Intel könnte den Featuresupport voll freischalten, müssen sich aber nicht (meiner Einschätzung nach). Besser wäre es, AMD hat was eigenes, was MathWorks als Alternativpfad implementiert.
OpenBLAS ist teilweise viel langsamer als die MKL.
Ich fänds geil, wenn AMD ne Pressemeldung raushaut: wir machen jetzt ne Kooperation mit MathWorks, Matlab rennt bald nur so auf Ryzen, dass einem schwindlig wird. ^^
Weniger auf Intel schauen, mehr auf die Hersteller und AMD.
Spricht hier irgendjemand außer dir davon das sie das müssten? Irgendjemand? Der einzige der das andauernd wiederholt bis Du Zero. Hat irgendjemand in diesem Thread schonmal geschrieben: Es ist scheisse das Intel ihre Software nicht optimal auf AMD anpasst. AFAIK Nein, oder?
Sie gehen lediglich bei anderen als Intel- Prozessoren in einen Kompatibilitätsmodus.
Und wo steht das eigentlich? In der MKL Dokumentation finde ich nichts davon. Ich hab das ganze File nach Compatibility oder Legacy Mode durchgeschaut, nix drinn.
Also weder bei den Contributoren, noch der Übersicht der Sponsoren gibt es Hinweise auf offizielle Hinweise, dass AMD bei OpenBLAS großartig mitmischen würde. Beim der Unterstützung für x86 CPUs steht auch da:
Code:
https://github.com/xianyi/OpenBLAS
Additional supported CPUs
x86/x86-64
[LIST]
[*]Intel Xeon 56xx (Westmere): Used GotoBLAS2 Nehalem codes.
[*]Intel Sandy Bridge: Optimized Level-3 and Level-2 BLAS with AVX on x86-64.
[*]Intel Haswell: Optimized Level-3 and Level-2 BLAS with AVX2 and FMA on x86-64.
[*]Intel Skylake-X: Optimized Level-3 and Level-2 BLAS with AVX512 and FMA on x86-64.
[*]AMD Bobcat: Used GotoBLAS2 Barcelona codes.
[*]AMD Bulldozer: x86-64 ?GEMM FMA4 kernels. (Thanks to Werner Saar)
[*]AMD PILEDRIVER: Uses Bulldozer codes with some optimizations.
[*]AMD STEAMROLLER: Uses Bulldozer codes with some optimizations.
[*]AMD ZEN: Uses Haswell codes with some optimizations.
[/LIST]
Was auch nicht darauf hindeutet, dass AMD CPUs da eher von Vorleistung Dritter profitiert.
Insofern, erlaube ich mir die Frage, wie kommst du darauf, dass AMD da der größte Sponsor ist?
Aus dem Tweet eines OpenBLAS Programierers (Martin Krakau oder so ähnlich) den ich jetzt aber leider wirklich zu müde und beschäftigt bin rauszusuchen. Man möge es mir vergeben und meinen Post oben solange mit einem ? versehen. Aber die Frage ist natürlich berechtigt, Pikto, ich reiche das bei Gelegenheit nach.
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.
Ähh nein!
Es gibt eine Abfrage der CPUID nach Vendor String. Das ist unbestritten.
Technisch ist das nicht schön, moralisch kann man davon halten was man will, ich halte es bei einer proprietären Softwarelösungen jedoch für rechtlich in Ordnung.
Es gab "lediglich" eine Diskussion wie die weitere Verzweigung ausgestaltet ist, die über exakte Codepfade entscheidet. Da könnte man ja nach CPU Familie gehen oder nach Abfrage der Features, beides gibt die CPUID her. Wie das genau abläuft weiß ich noch immer nicht. Den Code an der Stelle auseinander zu nehmen überschreitet gerade mein Wissen, Zeit und auch Hardwarekapazitäten (<- ernsthaft, Decompiling und Analyse einer der 20MB großen libmkl_core.so benötigt ordentlich Ressourcen).
Ja- Das gab es in dem Thread schon zu Hauf. Es ist eben eine Definitionssache und darauf will ich hinweisen.
Wenn man irgendjemandem ans Bein pinkeln will, sollte man sehr genau auf die eigene Ausdrucksweise und auf Definitionsunschärfen achten.
Und dazu wurde dieser Thread- Und meine Betonung liegt wieder auf:Nicht von Dir, Ned oder von Iscaran, hingeleitet.
Es gibt hier schlichtweg niemandem was vorzuwerfen. Es ist die Sache des Softwareentwicklers und nicht von Intel, die hier nur eine auf die eigenen Prozessoren optimierte Bibliothek stellt, das geradezurücken.
@Ned Flanders
Martin Kroeker meinst du wahrscheinlich, er ist 2. Maintainer neben Zhang Xianyi für OpenBLAS.
Kroeker wird von deutsche Steuergeldern finanziert (Angestellt in einer Uni in Freiberg, Fakultät Chemie)
Xianyi hat eine eigene Firma in China (I guess)
Wer ansonsten noch größere Brocken Code beigesteuert hat ist Werner Saar (aus Dresden), über den lässt sich aber nicht viel mehr herausfinden.
Korrektur: https://de.linkedin.com/in/werner-saar-7961a384
Der Mann hat laut linkedin eine beindruckende Historie an OSS Projekten an denen er mitwirkte. Da ist viel geiler scheiß dabei.
###################
Edit2:
Wo AMD als Sponsor gelistet ist, ist auf github.com/flame/blis da stehen sie aber nicht allein da.
Aktueller gesicherter Stand ist und da sind Pikto und ich uns völlig einig, dass es einer Vendor ID Abfrage gibt die man auch wegpatchen kann. Wie es danach weitergeht weiss von uns hier bislang keiner. Gesichert dazu ist bislang nur, dass bei gepatchter Vendor String Abfrage die MKL einen AMD FX 8320 erkennt und akzeptiert und den Codepfad korrekt auf AVX setzt sowie bei einem Zen+ 2600x den Codepfad korrekt auf AVX2. Das haben wir selbst getestet.
Imho deutet das auf eine Feature Set Abfrage hin, ich weiss aber nicht wie einig Pikto und ich uns da noch sind.
Darüber streite ich mich aber auch nicht, dass ist nicht weiter wichtig für meine Meinung, auch wenn es mich interessiert.
Piktogramm schrieb:
Martin Kroeker meinst du wahrscheinlich, er ist 2. Maintainer
Mensch ich habe da einen Vorschlag für dich.
Wir machen ein offentliches Wettrennen bei dem du von mir natürlich die Schuhe nehmen mußt die ich dir gebe, eine Nummer zu klein ist und in die Sohle ein Nagel getrieben wurde dessen Spitze mit der Innenseite der unbelastete Sohle abschließt und bevor alle Stricke reißen könnte man dir natürlich auch noch die Schnürsenkel zusammenbinden.
Intel kann intern machen was sie wollen aber sobald sie damit auf den freien Markt gehen sollen sie sich gefälligst an das halten was für alle gilt.
Funktionen der Hardware zu nutzen die von der Software unterstützt werden sind keine Optimierung. So wie ich das sehe ist das eine Grundvoraussetzung für den freien Wettbewerb.
Ok, ich war ein "ganz kleinen Hauch" naiv in meiner Annahme, dass sich da mal eben feststellen lässt was da genau geprüft wird. An einigen Stellen schaut es aus wie ein simpler Check auf die CPU Familie, an anderen Stellen ist es aber auch Voodoo (lies: Ich verstehe deutlich zu wenig von Assembler)
Hab mir das auch mal angetan-Da findet nach der Abfrage ein Shitload an Checks und bedingten Sprüngen statt.
So wie es auf den ersten Blick aussieht werden da doch die Features abgeklopft, was wiederum denjenigen Recht geben würde, dass die Abfrage des Vendors vermutlich nicht notwendig wäre, also eine funktional unnötige Beschränkung darstellen würde.
Somit erhärtet sich zumindest für mich der Verdacht, dass Intel sich beabsichtigt nur um seine eigenen CPUs kümmert und durch entfernen einer einfachen Prüfroutine alles auf Intel CPUs und AMD CPUs korrekt laufen würde.
Also ja- Es ist wohl Absicht. Was die Sachlage im Allgemeinen in meinen Augen aber nicht ändert.
Hinter all dem Blabla auf Intels Seite wird für mich allerdings auch nicht ersichtlich, wie überhaupt die Nutzungsbedingungen der Bibliothek aussehen...
LG
Zero
Ergänzung ()
Wadenbeisser schrieb:
Mensch ich habe da einen Vorschlag für dich.
Wir machen ein offentliches Wettrennen bei dem du von mir natürlich die Schuhe nehmen mußt die ich dir gebe, eine Nummer zu klein ist und in die Sohle ein Nagel getrieben wurde dessen Spitze mit der Innenseite der unbelastete Sohle abschließt und bevor alle Stricke reißen könnte man dir natürlich auch noch die Schnürsenkel zusammenbinden.
Es sind die ersten Olymischen Wettbewerbe. Jemand erfindet Laufschuhe und gestattet seinem Konkurrenten auch Laufschuhe zu benutzen.
Intel baut nun in ihre Schuhe besondere Polsterungen, Federungen leichte Materialien und sonstnochwas ein und passt sie für seinen Läufer an.
Die Anhänger des Konkurrenten schimpfen nun auf denjenigen, dessen Läufer durch die bessere Ausstattung der Schuhe schneller läuft, weil er sich erdreistet, all die Sonderanfertigungen und Anpassungen nicht für den konkurrierenden Läufer von vornherein integriert zu haben oder "freizuschalten", anstatt auf den Teamchef des Läufers mit dem unangepassten Material, der es versäumt hat seine Schuhe ebenso auszustatten.
Intel kann intern machen was sie wollen aber sobald sie damit auf den freien Markt gehen sollen sie sich gefälligst an das halten was für alle gilt.
unktionen der Hardware zu nutzen die von der Software unterstützt werden sind keine Optimierung. So wie ich das sehe ist das eine Grundvoraussetzung für den freien Wettbewerb.
Dann pfeiff mal AMD ordentlich an, dass die immernoch keine DXR bzw. Raytracing- Unterstützungen für ihre GPUs freigeschalten haben, obwohl deren Hardware es unterstützt und ein Standard dafür besteht. https://www.pcgamesn.com/amd/directx-raytracing-in-gpu-drivers
Aber da ist sicherlich auch nvidia schuld, weil sie für AMD keinen Treiber geschrieben haben, oder?
Wo ist denn da der Wille die Grundvoraussetzung eines freien Wettbewerbs zu erfüllen?
Noch schlimmer- Wenn man dem Link oben Glauben schenken darf, hielt AMD AKTIV durch einen Lock den Treiber davon ab, RTRT zu unterstützen, obwohl komplett funktional integriert.
Vermutlich ist es nur Taktik um zu verschleiern, dass der Konkurrent im Augenblick diesbezüglich meilenweit überlegen ist und man nicht unnötig Aufmerksamkeit auf ein Feature lenken will, in welchen man eben noch nicht so gut da steht?
Oh wie berechnend und schändlich... Da wird die eigene Klientel nur aus Marketinggründen und Eigennutz völlig verarscht und ihnen künstlich eine Technik vorenthalten.
Merkst Du, wie wenig sinnvoll solche einseitigen Diskussionen und hätte hätte Fahrradkette- Spielchen sind?
Natürlich ist er passend, auch wenn er dir nicht passen mag.
Öffentlicher Wettbewerb = freier Markt
zu kleine Schuhe = keine Optimierungen auf die Eigenschaften der Hardware der Konkurrenz
Nagel + Schnürsenkel = gezielte Behinderung um die Konkurrenz auszubremsen
In dem Moment wo sie mit ihrem Stück Software auf den freien Markt gegangen sind und nicht geschrieben haben das ihre Software beim Einsatz von Konkurrenzprodukten gezielt im Funktionsumfang beschnitten wird ist die Nummer durch denn was du so beharrlich ignorierst, die Software wird eben nicht nur intern von ihnen genutzt sondern auch externen Kunden für den externen Einsatz zur Verfügung gestellt und damit bricht dein argumentatives Kartenhaus in sich zusammen.
Ich bin mir aber auch fast sicher das du so neutral bist auch das zu ignorieren, lasse mich aber auch gern eines besseren belehren.
@Wadenbeisser
Genau da sind wir an einem Dead- End.
Wo steht geschrieben, dass Intel alle Software, die sie zur Nutzung für ihre Prozessoren geschrieben haben, überhaupt auf anderen CPUs lauffähig machen müssen?
Ist es besser, wenn sie einen kompletten Vendor- Lock integrieren? Wären dann alle zufrieden? (Ned Flanders wäre z.B. ein Befürworter)
Ansonsten werden hier Dinge angeprangert die auf dem "freien Markt" absoluter Usus sind und durch den offenen Wettbewerb befeuert werden bzw. Wettbewerb überhaupt erst entstehen kann...
Man sollte mit dem Begegriff "Ungerechtigkeit" aufpassen. Dass Intel den Markt teils dominiert, ist nicht ungerecht, sondern eine Konsequenz der Vorteile, die sie sich erarbeitet haben. Außerdem muss man davon ausgehen, dass dabei zumeist legal agiert wurde. Ausnahmen gabs in der Vergangenheit durchaus. Auch hier muss man aufpassen, dass die Ausnahmen nicht die Basis des Erfolgs darstellen. Wie groß der Anteil letztlich ist, kann man nur sehr schwer beurteilen als Außenstehender.
Und wie vermutet ignorierst du das es um Software für den freien Markt geht und das es nicht um Optimierung für die Konkurrenz sondern eine gezielte Behinderung der Konkurrenz geht. Passt halt nicht zur Argumentation.
Wenn du es aber so willst, einfach ein Popup mit Intel Logo und dem Hinweis hochkommen lassen das die Software auf Hardware der Konkurrenz im Funktionsumfang beschnitten wird.
Das ist offen, eindeutig und dürfte relativ schnell dafür sorgen das sie vom freien Markt verschwindet.
Rate mal warum genau das nicht passieren wird.
Mag sein, aber sicher wäre ich mir da ganz und garnicht...
Wie hoch ist denn der Nutzeranteil dieser Bibliothek in Blöcken AMD vs Intel?
Wieso sollte ich mit einem Intel System nicht auf eine optimierte Bibliothek zugreifen?
Ist zwar Whataboutism in Reinform, aber man sollte hier wirtschaftliche "Gepflogenheiten" bzw. deren Realitäten halt nicht nur einseitig betrachten.
Ja- AMD ist aktuell der symphatischere Player. Nur muss man der Konkurrenz keine Dinge negativ unterstellen, die in dem Metier zum Standard gehören.
Das ist für mich einfach nur gekünstelte Aufregung. Genau wie das Meckern über early- adopter- Preise oder das Einführen neuer Techniken, wenn sie nicht gleich zu 10000% optimiert und perfektioniert sind...
Ich mag undifferenziertes, plumpes Draufhauen einfach nicht. Das geht besser.
Was mich halt stört teilweise, ist, dass AMD als Opfer dargestellt wird und dann aber zu wenig Verantwortung eingefordert wird. Das betrifft insbesondere das Ökosystem und Softwarequalität. Hier hat AMD noch sehr großen Nachholbedarf.
