News Intel MKL 2020.2: Neuer AMD-Workaround schneller als Zen-Kernel

[Riegelstriegel]

hat die Redaktion noch einmal seine entsprechenden Kontakte

 

[von Schnitzel]

Mit Intel will ich nichts mehr zu tun haben.
Wenn Intel nichts macht um ihre Lib für andere zu optimieren, kann man ihnen keinen Vorwurf machen, denn dann behindern sie die andere nicht aktiv. Wenn AMD in dem Fall nicht in die Pötte kommt und die eingene Lib optimiert, selber Schuld. Aber wenn aktiv behindert wird, absolutes No-Go.

 

[DocWindows]

Tendenziell eher vergleichbar mit dingen wie NVIDIA Turf Effects/Waterworks (mir fällt grad der Oberbegriff nicht ein).

Middleware?

Der Vergleich paßt zwar sowieso nicht zum Thema, aber nein: i.d.R. will man gerade Kunden der Konkurrenz rüberziehen und lockt diese zu einem. Vgl Neukundenrabatte in der Telefonanbieterbranche.

Auch ne schöne Idee. Hey, AMD User: Wenn du die MKL vollperformant nutzen willst, dann komm doch rüber und werde Intel Kunde.

Ist jetzt sogar schon ohne weiteres möglich. Musst dir nur ne Intel-CPU kaufen.

Aber offenbar will er das gar nicht verstehen

Du willst doch auch seinen Punkt auch gar nicht verstehen.

Eben, was Intel hier macht, ist aktive Behinderung der Mitbewerber durch Manipulation.

Wenn hier jemand irgendwen anders behindert, dann Mathworks indem sie eine Bibliothek verwenden die nur auf Intel performant läuft. Hätten ja was anderes verwenden können.

 

[HaZweiOh]

Wenn hier jemand irgendwen anders behindert, dann Mathworks

Da kommt der nächste, der vom Problem ablenkt, indem er nur auf andere zeigt, die Schuld sein sollen.

 

[Kacha]

1. Falsch. In der Bibliothek sind Zen-Pfade enthalten. Man findet auch Pfade die "Barcelona" heißen.
Barcelona-CPUs sind ja schon etwas älter.

Falsch. Du nimmst an nur weil ein Pfad vorhanden ist, dass auch Optimierungen vorhanden sind. Ein Pfad heisst noch lange nicht Optimierung.

2. Falsch. Intel ignoriert die Extensions aller CPUs die nicht von Intel kommen.

Ok, ich erweitere: Intel behindert aktiv alle anderen CPU Hersteller. Aendern tut sich nicht viel

3. Falsch. Es gibt Featureabfragen im Code

Fast richtig. Es gibt Featureabfragen NACH der Vendorabfrage. Letzteres kann man sich aber sparen wenn man nur ersteres macht.

4. Weiß ich nicht. Aber es gibt auf jeden Fall noch ein alternatives Projekt OpenBLAS

Richtig, was auch AMD unterstuetzt. Fuer Intel kaeme sowas natuerlich nicht in Frage, wie will man da noch aktiv bescheissen koennen?

Es ist eher eine aktive Bevorzugung von Intel CPUs als eine aktive Benachteiligung anderer CPUs, weil der Generische Weg der Default-Weg ist und der optimierte Weg explizit gewählt wird wenn eine Intel-CPU drin ist. Aber das geht schon in Richtung Haarspalterei.

Falsch. Es ist und bleibt aktive Benachteiligung wenn man explizit Features die vorhanden sind nicht nutzt. Optimierungen sind davon komplett unabhaengig, da kann Intel fuer ihre Prozessoren machen was sie wollen.

Sowas kann aber 1:1 vom Intel Pressesprecher kommen.

Wenn man den Unterschied von generischer Software für eine Prozessorarchitektur und spezieller Software für eine bestimmte CPU-Reihe nicht versteht, wird man nie begreifen warum die Dinge sind wie sie sind und warum das nicht sonderlich schlimm ist.
Das alles ist keine technische Frage, sondern eine strategische/kaufmännische Frage.

Merke, Reflektion bei DocWindows nicht vorhanden. Wenn man allerdings von generischer Software fuer eine Prozessorarchitektur schreibt (oder zaehlen Befehlssaetze ploetzlich nicht mehr darunter?) und dann meint aktives nicht nutzen der Features waere voll in Ordnung, dem kann man getrost Realitaetsverlust unterstellen.

Und nur wegen der Vollstaendigkeit halber, es sind Pfade in der Software fuer erstens, den Hersteller, zweitens, wenn Intel, dann die verschiedenen CPU Reihen. Wenn man schon klugscheissen moechte.

Wenn es keine technische Frage ist, dann soll Intel die Lib einfach nur auf Intel Prozessoren ausfuehrbar machen. Problem komplett umgangen, aber man kann halt den Mitbewerber nicht mehr schlecht aussehen lassen, schon doof. Das es bei Intel Strategie ist zu bescheissen und Marktmanipulation zu betreiben ist in der Tat keine Frage, das ist bekannt.

@HaZweiOh Nimm es Holt nicht krumm, er muss halt nicht arbeitsintensiv sein Hirn einschalten. Aber gibt genug die auf dem gleichen Trip sind.

 

[calluna]

Es ist und bleibt aktive Benachteiligung wenn man explizit Features die vorhanden sind nicht nutzt.

Genau dieses Verhalten ist seit über 10 Jahren kein Problem gewesen, weil es eben rechtlich keine aktive Benachteiligung war und vor allem deswegen erlaubt gewesen ist, weil die MKL offiziell nur Intel-CPUs unterstützt hat.

Wäre vielleicht gut, wenn wir hier zwischen unseren Moralvorstellungen und der rechtlichen Situation unterscheiden.

 

[HaZweiOh]

Du machst es dir zu einfach. Das Wettbewerbsrecht ist immer auch eine Frage der Bewertung.

Es liegt in der Natur einer Standard-Bibliothek, dass mit vielen Software- und Hardwarekombinationen funktionieren muss, nicht nur mit einer.

 

[DocWindows]

Falsch. Du nimmst an nur weil ein Pfad vorhanden ist, dass auch Optimierungen vorhanden sind. Ein Pfad heisst noch lange nicht Optimierung.

Ach ja. Ich vergaß Intels Niedertracht. Die brauen 5 Weichen ein, die aber alle das gleiche machen. 5x Copy&paste

Merke, Reflektion bei DocWindows nicht vorhanden. Wenn man allerdings von generischer Software fuer eine Prozessorarchitektur schreibt (oder zaehlen Befehlssaetze ploetzlich nicht mehr darunter?) und dann meint aktives nicht nutzen der Features waere voll in Ordnung, dem kann man getrost Realitaetsverlust unterstellen.

Es ist eine Software die für Intel Kunden gedacht ist und nicht für AMD Kunden. Wenn du nicht mal diese einfache Tatsache zur Kenntnis nehmen willst, dann erzähl mir keinen von Reflektion.
Wüßte auch nicht wo geschrieben steht dass jeder der eine Software entwickelt gezwungen ist alle Features jeder CPU zu nutzen.

Ich weiß nicht auf welcher Basis du deine Bewertungen triffst, aber es ist definitiv nicht meine. Soviel steht fest.
Ich als Entwickler entscheide was ich wann von wem nutze und sonst niemand.

indem er nur auf andere zeigt, die Schuld sein sollen.

Wenn du mir keinen Hinweis nennen kannst, dass Mathworks in irgendeeiner Weise gezwungen wurde MKL zu nutzen, dann kann ich die Schuldfrage leider nicht anders beantworten.

 

[calluna]

Es liegt in der Natur einer Standard-Bibliothek, dass mit vielen Software- und Hardwarekombinationen funktionieren muss.

Nur ist die MKL keine Standard-Bibliothek, sondern eine explizit nur für Intel-Systeme gedachte Mathebibliothek.

PS: und es wäre nett, wenn das beharren auf so einfachen Tatsachen nicht gleich als "Du verteidigst Intel... wieso machst du das!?" ausgelegt wird. Ganz einfach, weil ich als jemand mit einer AMD CPU im Desktop, der unter Linux NumPy mit OpenBLAS verwendet, niemals den Anspruch gehabt habe, die MKL verwenden zu dürfen / können.

 

[Miuwa]

Warum müssen sie das? Ich arbeite in der Medizindiagnosetechnikbranche. Wir haben z.B. einen Test, der verschiedene Marker bei Krebs analysiert. 4 Marker sind dabei validiert, 3 nicht. Der Kunde kann den Test für die 4 Marker direkt zur Diagnose verwenden. Will er die anderen auch verwenden, muß er seober validieren.
Dies kann Intel auch machen: mkl ist nur für Intel Chips validiert.

Ich beziehe mich dabei auf @Holt's post, der davon ausgeht man müsste alle supportete Platformen auch validieren. Man kann generell darüber diskutieren, was "supported" genau heißt (bloß weil meine Software auf Platform X läuft heißt das noch lange nicht, dass ich sie auch supporte) und man wird sicherlich in verschiedenen Zusammenhängen zu verschiedenen Antworten kommen. Ich hab ja durchaus drauf hingewiesen, dass Intel die Validierung auch einfach sein lassen kann. Das entscheidende war: Ob MLK auf AMD jetzt nur "normale" x64 Instruktionen nutzt oder z.B. AVX wenn vorhanden ändert nichts daran ob Validierung auf AMD Prozessoren vorgenommen werden muss oder nicht.

 

[HaZweiOh]

nur für Intel-Systeme gedacht

Behaupten kann man viel, aber diese Ausrede dürfte wettbewerbsrechtlich kaum haltbar sein. Vor allem, wenn zur marktbeherschenden Stellung (im Volksmund Monopol genannt) die aktive Manipulation dazu kommt.

Wie gesagt ist das eine Frage der Bewertung, über die am Ende nicht Intel entscheidet.

 

[DocWindows]

Diese Ausrede dürfte wettbewerbsrechtlich kaum haltbar sein.

Darum funktioniert die Bibliothek ja auch auf AMD-Systemen.
Noch einen Schritt und wir haben uns einmal komplett im Kreis gedreht.

 

[HaZweiOh]

Ja lustig, sie wird auf AMD CPUs "nur" durch Manipulation verschlechtert.

Dann ist ja alles gut .

 

[calluna]

Davon abgesehen gibt es die MKL-DNN bzw. oneDNN von Intel, bei der direkt steht:

oneDNN supports platforms based on the following architectures:

• Intel 64 or AMD64,
• Arm 64-bit Architecture (AArch64).
• OpenPOWER / IBM Power ISA.
• IBMz z/Architecture (s390x).

Und in so einem Fall darf es keine Benachteiligung geben.

 

[Ned Flanders]

Ganz einfach, weil ich als jemand mit einer AMD CPU im Desktop, der unter Linux NumPy mit OpenBLAS verwendet, niemals den Anspruch gehabt habe, die MKL verwenden zu dürfen / können.

Und das finde ich beispielsweise eine völlig legitime Sichtweise auf die Sache. Andere sind aber leider nicht in der gleicherart komfortablen Situation, einfach weil sie Matlab, Microsoft R oder Ansys nicht auf OpenBlas oder BLIS umstellen können. Zumindest von Matlab (bzw. einem Dev dort) weiss ich, dass die sich von Intel schon durchaus hinters Licht geführt fühlten, als klar wurde das die MKL aktiv und undokumentiert Performance auf Intel Systeme beschränkt. Und seien wir ehrlich, dieser Aufschrei darum ist durchaus konstruktiv, denn wenn Intel sich jetzt anfängt zu bewegen (und danach siehts ja schwer aus), dann sicher nicht weil alle super finden wie das bisher gelaufen ist.

Und in so einem Fall darf es keine Benachteiligung geben.

die MKL-DNN ist aber afaik auch OSS

 

[calluna]

Ja lustig, sie wird auf AMD CPUs "nur" durch Manipulation verschlechtert.

Sie wird nicht angewandt.

 

[Spandi]

Und in so einem Fall darf es keine Benachteiligung geben.

vorallem ist es ein einfacher 0 oder 1 Rückgabewert der so einen Leistungsunterschied bewirkt^^

 

[HaZweiOh]

von Intel, bei der direkt steht:

Du spielst hier Intels Spiel mit, aber behaupten kann man viel.

Die anderen Architekturen sind sogar ein Beweis für die universelle(!) Einsetzbarkeit der Bibliothek (wofür Bibliotheken auch per se gedacht sind!), also mitnichten ein "wurde von Anfang an nur auf Intel-CPUs zugeschnitten".

 

[DocWindows]

Und seien wir ehrlich, dieser Aufschrei darum ist durchaus konstruktiv, denn wenn Intel sich jetzt anfängt zu bewegen (und danach siehts ja schwer aus), dann sicher nicht weil alle super finden wie das bisher gelaufen ist.

Naja, bis jetzt haben sie die Lücke mit der man die für Intel-Systeme vorgesehene Leistung auch auf AMD-Systemen nutzen kann entfernt und bei der Linuxversion eine neue Funktion eingeführt die eine alte Funktion nutzt. Jetzt reicht eine Umgebungsvariable nicht mehr aus. Man muss schon den BLOB manipulieren. Siehe Post 82.

Sieht für mich unterm Strich nicht nach Lockerung aus, sondern nach Absicherung.

also mitnichten "funktioniert aus technischen Gründen nur mit Intel".

Behauptet doch keiner. Es ist eine ganz klare Businessentscheidung. Und das ist vollkommen OK.

 

[calluna]

@Spandi

Ich glaube, fast jedem hier ist klar, dass eine AMD CPU, welche dieselben Instruktionen implementiert wie das Intel-Gegenstück, ohne Probleme mit der MKL funktionieren sollte... und dass es Absicht ist, die rechtliche Lage soweit auszureizen, dass die MKL nur auf Intel Produkten gut performt.

Wir sind uns hier doch nur uneinig, ob das moralisch verwerflich ist oder nicht.

Die anderen Architekturen sind sogar ein Beweis für die universelle(!) Einsetzbarkeit der Bibliothek (wofür Bibliotheken per se gedacht sind!),

Also wofür die Bibliothek gedacht ist und wie sie benutzt werden kann, legt ja wohl derjenige, der sie zur Verfügung stellt, über seine Nutzungs- / Lizenzbedingungen fest.