News Wall Street Journal: Qualcomm soll Intel übernehmen wollen

[chithanh]

Das ist vollkommener Unsinn. Erstens würde das Kündigen des Abkommens nur zukünftige Chips betreffen. Anwender könnten also einfach weiterhin bereits verfügbare AMD-Chips benutzen.

Das ist es was ich mit "x86 auslaufen lassen" meinte. Nicht sofort den Verkauf stoppen. Heutige Chips können weiter verkauft werden, aber danach ist Schluss.

Weiterhin liefen sie Gefahr von AMD verklagt zu werden, wenn sie deren Anteil an x86 zu emulieren versuchen.

Also beim oben verlinkten Arstechnica-Artikel liest sich das anders, da wird AMD als Ziel von Intel-Patentklagen dargestellt und nicht andersrum. Da du eine Gefahr siehst: Welche relevanten AMD-Technologien nutzt Intel denn, und insbesondere: hat sich AMD wie Intel auch die Emulationstechniken patentieren lassen?

Zweitens könnte AMD angepasste x86-CPUs herstellen, die auf alle noch gültigen Intel-Patente verzichtet

Ja, AMD könnte ohne Intel-Patente eine x86-64 CPU mit SSE2 bauen wie den originalen Athlon 64 von 2003. So einer bootet aber nicht mal Windows 11 (das braucht eine Reihe von neueren Instruktionen wie SSE4.2) und wird viele existierende x86-Programme nicht ausführen können. Und da sind noch nicht mal die Patente berücksichtigt, die Interna des Designs betreffen.

und trotzem bessere Kompatibilität und Leistung bietet als emuliertes x86 auf ARM. Drittens würde ich erwarten, dass im Falle eines x86-Untergangs viele der großen Player in der Industrie eher auf eine offene Architektur drängen würden. Keiner will sich von einzelnen Firmen abhängig machen. Das hat man gesehen als Nvidia ARM kaufen wollte.

Das wäre das dümmste was Qualcomm tun könnte. x86 bietet für Intel und AMD ein recht bequemes Duopol mit garantierten Einnahmen ohne viel Konkurrenz. Warum sollte Qualcomm das einfach wegwerfen nachdem sie viele Milliarden dafür bezahlt haben?

Vielleicht habe ich mich nicht klar genug ausgedrückt. Das Szenario ist dass Qualcomm gar kein Interesse an der Fortführung von x86 hat, sondern möglichst viel Geld aus dem geistigen Eigentum Intel herauspressen will. Dass x86 danach am Ende ist, ist Qualcomm dann egal solange sie ihr Geld rausbekommen.

Und wenn Snapdragons die einzigen CPUs sind die x86 inkl. SSE4.2 usw. performant ausführen können, dann ist das ein massives Verkaufsargument für institutionelle und private Anwender, die auf existierende x86-Software angewiesen sind.

Gleichzeitig erhält Qualcomm Intels Design- und Chipherstellungspatente, die man gegen die aufstrebende RISC-V-Konkurrenz einsetzen kann.

Guck dir mal an wie die Übernahme von Sun Microsystems durch Oracle ablief, da hatte Oracle genau die gleichen Ziele. Jedes Sun-Produkt von damals ist tot oder nur noch ein Schatten seines früheren selbst. Oracle hat auch nur knapp den Jackpot verfehlt als Google im letzten Moment noch den Kopf aus der Schlinge ziehen konnte.

fast alle Software, die diese benutzt bietet Compiler-Optionen um die Software auch auf älteren CPUs ohne diese benutzen zu können.

Klar, könnte man ohne die Instruktionen neu kompilieren. Wenn man schon dabei ist, könnte man auch für ARM neu kompilieren. Das passiert aber in ausreichend vielen Fällen nicht: x86 Code ausführen ist ein massives Feature ohne dass es nicht geht, weder unter Windows (Prism) noch auf dem Mac (Rosetta). Auch Valve arbeitet an proton-arm64, einstweilen denke ich für Chromebooks, langfristig möglicherweise für ein ARM-basiertes Steam Deck.

 

[HerrRossi]

Welche relevanten AMD-Technologien nutzt Intel denn

x64 aka AMD64.

 

[stefan92x]

@HerrRossi Allerdings wurde das 1999 patentiert und ist damit mittlerweile nicht mehr geschützt.

 

[Limit]

Ja, AMD könnte ohne Intel-Patente eine x86-64 CPU mit SSE2 bauen wie den originalen Athlon 64 von 2003.

Naja, das SSE4 Patent läuft in knapp 2 Jahren aus, SSE4.2 etwa ein Jahr später. Problematischer wären AVX und Nachfolger.

So einer bootet aber nicht mal Windows 11 (das braucht eine Reihe von neueren Instruktionen wie SSE4.2) und wird viele existierende x86-Programme nicht ausführen können.

Die SSE4.2 Anforderung kommt erst mit dem 24H2-Update. Fast jede Software, die "neuere" Befehlssatzerweiterungen benutzen haben eine Fallback-Option für ältere CPUs. Für die Software-Entwickler wäre es also problemlos möglich eine Version ohne die neueren Befehlssatzerweiterungen herauszubringen falls nötig.

Vielleicht habe ich mich nicht klar genug ausgedrückt. Das Szenario ist dass Qualcomm gar kein Interesse an der Fortführung von x86 hat, sondern möglichst viel Geld aus dem geistigen Eigentum Intel herauspressen will. Dass x86 danach am Ende ist, ist Qualcomm dann egal solange sie ihr Geld rausbekommen.

Wie soll das funktionieren? Wenn sie Intels x86-IP verkaufen, dann würde der Käufer x86 weiterführen. Wenn Qualcomms Ziel es wäre x86 sterben zu lassen, dürften sie die IP eben gerade an niemanden verkaufen/lizensieren. Nur dafür bekommt man kein Geld. In letzterem Fall dürfte AMD der große Profiteur sein, denn Intels Patente laufen mittelfristig aus bzw. ließen sich ersetzen. Damit hätte Qualcomm AMD praktisch ein Monopol in einem riesigen Markt geschenkt.

Und wenn Snapdragons die einzigen CPUs sind die x86 inkl. SSE4.2 usw. performant ausführen können, dann ist das ein massives Verkaufsargument für institutionelle und private Anwender, die auf existierende x86-Software angewiesen sind.

Die bereits existierenden Intel und AMD Chips wären die einzige CPUs, die x86 inkl. aller Befehlssatzerweiterungen ohne jegliche Probleme ausführen könnten. Emulatoren haben immer einen gewissen Overhead und Einschränkungen bei der Kompatibilität. Daran würde auch eine Übernahme Intels nichts ändern sofern sie die Snapdragons nicht zu einer Art Hybrid-CPU mit Unterstützung beider ISAs entwickeln wollen.

Gleichzeitig erhält Qualcomm Intels Design- und Chipherstellungspatente, die man gegen die aufstrebende RISC-V-Konkurrenz einsetzen kann.

Ich könnte mich irren aber glaube nicht, dass die derzeitigen RISC-V Chips viele Intel-Patente benutzen. Von Chipherstellungspatenten wären sie überhaupt nicht betroffen. Da wären TSMC, GloFo, Samsung und Co die potentiellen Nutzer, aber wenn sie bisher keine Lizenzen gebraucht haben, dürfte sich daran durch die Übernahme auch nichts ändern.

Guck dir mal an wie die Übernahme von Sun Microsystems durch Oracle ablief, da hatte Oracle genau die gleichen Ziele. Jedes Sun-Produkt von damals ist tot oder nur noch ein Schatten seines früheren selbst. Oracle hat auch nur knapp den Jackpot verfehlt als Google im letzten Moment noch den Kopf aus der Schlinge ziehen konnte.

Das ist mMn nur sehr eingeschränkt vergleichbar, nämlich in Hinsicht auf MySQL. Oracle wollte verhindern, dass MySQL sich zu einer ernsthaften Konkurrenz zur eigenen DBMS entwickelt und das haben sie auch mehr oder weniger geschafft. Aber der Wert von MySQL war im Vergleich zur Java-IP vernachlässigbar gering. Mit dem Java-Ökosystem wollten sie einfach nur Geld machen und das funktioniert eben nur, wenn es weiterhin bestehen bleibt.

Klar, könnte man ohne die Instruktionen neu kompilieren. Wenn man schon dabei ist, könnte man auch für ARM neu kompilieren.

Das sind zwei ganz verschiedene Paar Schuhe. Für das entfernen der Befehlssatzerweiterungen ist in der Regel wirklich nur ein Recompile notwendig. Eine Portierung auf ARM hingegen bedeutet fast immer Änderungen am Sourcecode selbst und damit einen deutlichen Mehraufwand.

 

[chithanh]

Die SSE4.2 Anforderung kommt erst mit dem 24H2-Update. Fast jede Software, die "neuere" Befehlssatzerweiterungen benutzen haben eine Fallback-Option für ältere CPUs.

Nein. Problem ist dass das was du "Fallback" nennst (aka. CPU dispatcher) einen gewissen Nichtdeterminismus in das Programm einbringt. Und das will man in vielen Programmen nicht, insbesondere nicht in Spielen.

Für die Software-Entwickler wäre es also problemlos möglich eine Version ohne die neueren Befehlssatzerweiterungen herauszubringen falls nötig.

"Problemlos möglich" heißt nicht dass sie es auch tun werden, oder bald.

In Erinnerung sind da noch bestimmte Ubisoft-Spiele die zum Release nicht auf Phenom-CPUs liefen (wegen fehlendem SSE4.1). Far Cry 5 zum Beispiel: Release im März 2018, und es hat bis November 2019 gedauert bis Ubisoft das gepatcht hat.

Wie soll das funktionieren? Wenn sie Intels x86-IP verkaufen, dann würde der Käufer x86 weiterführen. Wenn Qualcomms Ziel es wäre x86 sterben zu lassen, dürften sie die IP eben gerade an niemanden verkaufen/lizensieren.

Nochmal: Es ist in keinem denkbaren Szenario Qualcomms Ziel, x86 sterben zu lassen. Es ist ihnen einfach egal.

Das Patentportfolio sorgt einfach dafür, dass nur auf Snapdragons die Emulation von x86 wirtschaftlich ist, alle anderen Anbieter müssen extra dafür bezahlen (was deren Plattform teurer und somit weniger konkurrenzfähig macht) oder sie verzichten von vorne herein. Die bisherigen x86-Kunden kommen dann von alleine zu Snapdragon.

Intels bisheriges Geschäft fortzusetzen wird kurz- und mittelfristig sicher nicht viel Gewinn einbringen. Die Fabs verbrennen Geld, 20A ist gecancelt, 18A noch nicht erprobt. Intels sagenhafte Margen im Datacenter kommen auch nicht wieder. Consumer und Unternehmenskunden sind angefressen wegen dem Raptor Lake Überspannungsproblem. Das wird Qualcomm also ziemlich sicher nicht planen.

Nur dafür bekommt man kein Geld. In letzterem Fall dürfte AMD der große Profiteur sein, denn Intels Patente laufen mittelfristig aus bzw. ließen sich ersetzen. Damit hätte Qualcomm AMD praktisch ein Monopol in einem riesigen Markt geschenkt.

Ich denke nicht, dass AMD so ohne weiteres moderne CPUs ohne Intel-Patente bauen kann. Die existierenden CPUs können sie weiter verkaufen, aber bei vielen Design-Techniken ist Intel Pionier gewesen und hat ensprechende Patente. Alles was in der Pipeline ist müsste auf dann "verbotene" Techniken abgeklopft werden.

Die bereits existierenden Intel und AMD Chips wären die einzige CPUs, die x86 inkl. aller Befehlssatzerweiterungen ohne jegliche Probleme ausführen könnten. Emulatoren haben immer einen gewissen Overhead und Einschränkungen bei der Kompatibilität. Daran würde auch eine Übernahme Intels nichts ändern sofern sie die Snapdragons nicht zu einer Art Hybrid-CPU mit Unterstützung beider ISAs entwickeln wollen.

Reine Softwarelösungen für x86-Emulation mittels binary translation erreichten schon vor 30 Jahren rund 40% der nativen Ausführungsgeschwindigkeit, siehe DEC FX!32. Heute ist man bei rund 80% bei fantastischer Kompatibilität, siehe Rosetta. Dabei helfen inzwischen auch Hardwareinstruktionen, die die Effizienz der x86-Emulation noch weiter steigern.

Ich könnte mich irren aber glaube nicht, dass die derzeitigen RISC-V Chips viele Intel-Patente benutzen. Von Chipherstellungspatenten wären sie überhaupt nicht betroffen. Da wären TSMC, GloFo, Samsung und Co die potentiellen Nutzer, aber wenn sie bisher keine Lizenzen gebraucht haben, dürfte sich daran durch die Übernahme auch nichts ändern.

Das ist so nicht richtig. Richtig ist vielmehr dass Qualcomm, falls sie entsprechende Patente haben die verletzt werden, sich aussuchen können, welches Unternehmen in der Wertschöpfungskette sie verklagen.

Das ist mMn nur sehr eingeschränkt vergleichbar, nämlich in Hinsicht auf MySQL. Oracle wollte verhindern, dass MySQL sich zu einer ernsthaften Konkurrenz zur eigenen DBMS entwickelt und das haben sie auch mehr oder weniger geschafft. Aber der Wert von MySQL war im Vergleich zur Java-IP vernachlässigbar gering. Mit dem Java-Ökosystem wollten sie einfach nur Geld machen und das funktioniert eben nur, wenn es weiterhin bestehen bleibt.

MySQL ist nur ein Beispiel unter vielen.
Solaris
StarOffice/OpenOffice
SPARC
usw.

Das was genug Community hinter sich hatte wurde geforkt. Praktisch alles andere ist mehr oder weniger eingegangen.

Java gibt es noch, aber es hat massiv an Bedeutung verloren verglichen mit den 2000ern. Wer damals Informatik studiert hat, hat typischerweise große Teile seines Studiums mit Java verbracht. Heutzutage ist Java aus Universitäten weitgehend verschwunden. Es ist noch für Enterprise und Android relevant, aber auch dort abnehmend.

Das sind zwei ganz verschiedene Paar Schuhe. Für das entfernen der Befehlssatzerweiterungen ist in der Regel wirklich nur ein Recompile notwendig. Eine Portierung auf ARM hingegen bedeutet fast immer Änderungen am Sourcecode selbst und damit einen deutlichen Mehraufwand.

Interessanterweise ist die Portierung auf ARM (so denn überhaupt Anpassungen notwendig sind) oft schon vorhanden, wenn es eine macOS-Version der Software gibt. Nur unter Windows und Linux ziert man sich, den ARM-build herauszubringen, obwohl es da wirklich nur eine Neukompilation wäre.

Und eines der Hautprobleme für die Portierung auf ARM ist wenn im Code intrinsics für SSE/AVX/usw. verwendet wurden - und da ist ebenso eine Anpassung am Sourcecode erforderlich, wenn man den Code auf x86-CPUs ohne diese Erweiterungen nutzen will.

 

[Boimler]

Woher kommt der Gedanke, Intel sei in irgendeiner Weise der Schlüssel zu jedem funktionierenden x86-Prozessor? Patente stellen kein Nutzungsverbot dar, sondern schützen geistiges Eigentum. Wenn Qualcomm tatsächlich Intel kaufen wollte, würden sie nicht automatisch Eigentümer der Patente oder könnten willkürlich über die Nutzungsrechte entscheiden. So etwas muss gesondert festgestellt werden - für jedes Patent einzeln. Das ist nicht trivial und kein Automatismus bei einem Unternehmenskauf.

Abgesehen davon sind die Patente selbst Teil des Unternehmenswertes (vgl. Coca-Cola oder SAP). Es könnte also sein, dass Qualcomm einige Patente gar nicht haben möchte, um weniger zahlen zu müssen. Das wäre wahrscheinlich wirtschaftlicher als Patente zu kaufen und dann (nicht) zu nutzen.

Und als Letztes: Patente können schnell angefochten werden, wenn sie tot herumliegen. Sollte Qualcomm also Know-How vorenthalten wollen, wäre das einerseits sehr durchsichtig und andererseits dumm, wenn man - was ja offenkundig ist - damit Geld machen kann.

 

[HerrRossi]

Wenn Qualcomm tatsächlich Intel kaufen wollte, würden sie nicht automatisch Eigentümer der Patente oder könnten willkürlich über die Nutzungsrechte entscheiden.

Warum erwirbt man nicht auch die Patente, wenn man ein Unternehmen als Ganzes kauft? Ist das eine Besonderheit im US-Recht?

Hier widersprichst du dir imho:

Abgesehen davon sind die Patente selbst Teil des Unternehmenswertes (vgl. Coca-Cola oder SAP).

 

[Boimler]

Juristisch gibt es einen Unterschied zwischen dem Erwerb eines Unternehmens oder dem Erwerb eines Teils des Unternehmens. Wenn Qualcomm Intel als Ganzes kauft, werden sie auch Eigentümer der Patente. Trotzdem müsste das vertraglich neu geregelt werden, weil so etwas erfahrungsgemäß anfechtbar ist. Wenn die Patente nicht extra im Kaufvertrag erwähnt werden, sind Intels Vereinbarungen von früher einerseits hinfällig, weil es Intel nicht mehr gibt, andererseits gibt es ein berechtigtes Interesse anderer Unternehmen, die Patente zu benutzen. Wie das im US-Recht ist, weiß ich nicht, aber es ist tendenziell problematischer als im deutschen Recht, würde ich mal sagen. Qualcomm muss sich also gut überlegen, was sie vorhaben.

Das ist auch kein Widerspruch dazu, dass Patente Werte an sich sind. Theoretisch kannst du Coca Cola kaufen und die Patente nicht mit einbeziehen. Dann gehören dir die Arbeitsmittel und du beschäftigst die Mitarbeiter. Das wäre in diesem Fall aber sinnlos, weil die Patente sicherstellen, dass du auch Cola produzieren kannst, mal ganz vereinfacht gesagt. Bei Intel ist es teilweise auch so, würde ich sagen. Qualcomm könnte aber auch nur das kaufen, was sie haben möchten und den Rest außen vor lassen. Wenn ihnen x86 egal ist, müssten sie dann diese Sparte (inkl. Foundries und Fabriken) außen vor lassen. Ansonsten ist das ein Milliarden-Grab.

Ich hab das selbst mal miterlebt im Bekanntenkreis, als es um ein kleines Unternehmen ging, das gekauft wurde. Ansonsten finde ich auf die Schnelle noch das.

 

[Limit]

Nein. Problem ist dass das was du "Fallback" nennst (aka. CPU dispatcher) einen gewissen Nichtdeterminismus in das Programm einbringt. Und das will man in vielen Programmen nicht, insbesondere nicht in Spielen.

Ich bin nicht ganz sicher was du meinst. Unter Windows oder einem "normalen" Linux bist du immer nicht-deterministisch. Außerdem meine ich mit Fallback, dass Software, die Befehlssatzerweiterungen benutzen fast immer über zusätzliche Codepfade verfügen um diese auszuschalten, manchmal zur Runtime, häufig aber auch zur Compiletime.

"Problemlos möglich" heißt nicht dass sie es auch tun werden, oder bald.

In Erinnerung sind da noch bestimmte Ubisoft-Spiele die zum Release nicht auf Phenom-CPUs liefen (wegen fehlendem SSE4.1). Far Cry 5 zum Beispiel: Release im März 2018, und es hat bis November 2019 gedauert bis Ubisoft das gepatcht hat.

Das lag aber sicherlich nicht daran, dass es so aufwendig war.

Nochmal: Es ist in keinem denkbaren Szenario Qualcomms Ziel, x86 sterben zu lassen. Es ist ihnen einfach egal.

Das Patentportfolio sorgt einfach dafür, dass nur auf Snapdragons die Emulation von x86 wirtschaftlich ist, alle anderen Anbieter müssen extra dafür bezahlen (was deren Plattform teurer und somit weniger konkurrenzfähig macht) oder sie verzichten von vorne herein. Die bisherigen x86-Kunden kommen dann von alleine zu Snapdragon.

Erkennst du hier nicht den Widerspruch? Wenn sie wollen, dass die x86-Nutzer auf Snapdragon wechseln wegen der deiner Meinung nach besten Emulation, dann dürfen sie die x86-IP nicht verkaufen/lizensieren, denn der Käufer würde diese auch nutzen wollen, sprich x86-CPUs herstellen. Aber warum sollte dann jemand eine x86-Emulation benutzen wollen, wenn es weiterhin echtes x86 gibt?

Intels bisheriges Geschäft fortzusetzen wird kurz- und mittelfristig sicher nicht viel Gewinn einbringen. Die Fabs verbrennen Geld, 20A ist gecancelt, 18A noch nicht erprobt. Intels sagenhafte Margen im Datacenter kommen auch nicht wieder.

Da stimme ich dir größtenteils zu. Falls es wirklich zu einer Übernahme käme (was ich nicht glaube), würde man versuchen die Fabs loszuwerden. GloFo oder Samsung könnten ein Interesse daran haben.
Intels Margen im x86-Geschäft mögen zwar nicht ganz so hoch sein wie z.B. Nvidias, aber sind trotzdem immer noch ganz ordentlich obwohl man technologisch zur Zeit etwas hinterher hinkt. An der Börse würde man wohl sagen Intel ist ein Value- und kein Growth-Investment.

Ich denke nicht, dass AMD so ohne weiteres moderne CPUs ohne Intel-Patente bauen kann. Die existierenden CPUs können sie weiter verkaufen, aber bei vielen Design-Techniken ist Intel Pionier gewesen und hat ensprechende Patente. Alles was in der Pipeline ist müsste auf dann "verbotene" Techniken abgeklopft werden.

Natürlich würde es eine ganze Weile dauern, aber da Intel als einziger x86-Konkurrent das gleiche Problem hätte, wäre das verkraftbar, da man in der Zwischenzeit einfach die alten CPUs weiterverkaufen kann.

Heute ist man bei rund 80% bei fantastischer Kompatibilität, siehe Rosetta. Dabei helfen inzwischen auch Hardwareinstruktionen, die die Effizienz der x86-Emulation noch weiter steigern.

Wenn ich mir die Tests zu den Snapdragon-Windows-PCs anschaue würde ich die Kompatiblität keinesfalls als fantastisch bezeichnen. Außerdem, wenn Rosetta ohne die Intel-Patente so toll funktioniert, wozu braucht Qualcomm diese dann überhaupt?

Das ist so nicht richtig. Richtig ist vielmehr dass Qualcomm, falls sie entsprechende Patente haben die verletzt werden, sich aussuchen können, welches Unternehmen in der Wertschöpfungskette sie verklagen.

Die Frage ist allerdings, wenn TSMC, Samsung oder GloFo Intel-Patente verletzen, warum hat Intel bisher nichts dagegen unternommen? Außerdem ist es fast sicher, dass die Fertiger sich in einen Rechtsstreit, in dem ihre Kunden auf Grund von Patenten auf Fertigungs-IP verklagt werden, einmischen würden und da diese über ebenfalls riesige Patentpools verfügen, könnte so etwas für Qualcomm schnell nach hinten losgehen.

MySQL ist nur ein Beispiel unter vielen.

Das ist aber das einzige, das für Oracles Kern-Geschäft potentiell ein Risiko hätte werden können.

Solaris
StarOffice/OpenOffice
SPARC
usw.

Das alles war für Oracle vollkommen uninteressant.

Java gibt es noch, aber es hat massiv an Bedeutung verloren verglichen mit den 2000ern. Wer damals Informatik studiert hat, hat typischerweise große Teile seines Studiums mit Java verbracht. Heutzutage ist Java aus Universitäten weitgehend verschwunden. Es ist noch für Enterprise und Android relevant, aber auch dort abnehmend.

Das ist Oracle vollkommen egal. Sie haben den Kaufpreis bereits wieder reingeholt. Jetzt versuchen sie nur noch mit möglichst wenig Aufwand den Cashflow so lange wie möglich aufrecht zu erhalten.

Interessanterweise ist die Portierung auf ARM (so denn überhaupt Anpassungen notwendig sind) oft schon vorhanden, wenn es eine macOS-Version der Software gibt.

Einen großen Teil der Software für Windows gibt es nicht für Mac.

Nur unter Windows und Linux ziert man sich, den ARM-build herauszubringen, obwohl es da wirklich nur eine Neukompilation wäre.

Das ist falsch. Mac, Windows und Linux bringen ihre jeweils eigenen Bibliotheken mit sich, die nicht miteinander kompatibel sind. Linux-Software auf Mac oder Windows zu portieren ist recht einfach (bei gleicher CPU-Architektur), da die Bibliotheken open-source sind, sprich man portiert nicht nur die eigentliche Software, sondern alle benötigten Bibliotheken gleich mit. Das funktioniert aber eben nicht für Mac- oder Windows-Software. Man müsste die Software umschreiben und dabei alle Bibliotheks-Aufrufe durch ihr Equivalent auf der jeweilgen Zielplattform ersetzen. Wenn dann auch noch Bibliotheken von Drittanbietern ins Spiel kommen wird es noch schwieriger oder sogar unmöglich ohne diese komplett zu ersetzen.

Und eines der Hautprobleme für die Portierung auf ARM ist wenn im Code intrinsics für SSE/AVX/usw. verwendet wurden - und da ist ebenso eine Anpassung am Sourcecode erforderlich, wenn man den Code auf x86-CPUs ohne diese Erweiterungen nutzen will.

Üblicherweise werden Funktionen erst einmal in reinem C/C++/... Code geschrieben den der Compiler mit oder ohne Befehlssatzerweiterungen übersetzen kann. Die Inline-Assembler-Optimierungen werden dann in der Regel als alternative Codepfade implementiert, die per Macros ein- und auszuschalten sind.

 

[chithanh]

Ich bin nicht ganz sicher was du meinst. Unter Windows oder einem "normalen" Linux bist du immer nicht-deterministisch. Außerdem meine ich mit Fallback, dass Software, die Befehlssatzerweiterungen benutzen fast immer über zusätzliche Codepfade verfügen um diese auszuschalten, manchmal zur Runtime, häufig aber auch zur Compiletime.

Ich meine dass die Software andere Rechenergebnisse liefert wenn man SSE/AVX/usw. benutzt als wenn man das nicht tut. Bei Gleitkommaberechnungen ist das immer eine lästige Sache. Hier ist eine gute Einführung in die Problematik.

Wenn du nun z.B. ein Multiplayerspiel hast wo der Server und jeder Client eine Simulation der Spielwelt laufen lassen, dann ist jeder Unterschied fatal, da mit dem Schmetterlingseffekt die Abweichungen schnell anwachsen.

Im Zuge der Raptor-Lake-Probleme wurde das auch nochmal thematisiert. Level1Techs hat berichtet, dass Leute in Multiplayer-Spielen verbannt wurden weil ihre Raptor Lakes falsch gerechnet haben (relevante Stelle bei 21:54 min).

Das lag aber sicherlich nicht daran, dass es so aufwendig war.

Nein, das lag und liegt daran, dass die Unternehmen sich nicht darum scheren.

Erkennst du hier nicht den Widerspruch? Wenn sie wollen, dass die x86-Nutzer auf Snapdragon wechseln wegen der deiner Meinung nach besten Emulation, dann dürfen sie die x86-IP nicht verkaufen/lizensieren, denn der Käufer würde diese auch nutzen wollen, sprich x86-CPUs herstellen. Aber warum sollte dann jemand eine x86-Emulation benutzen wollen, wenn es weiterhin echtes x86 gibt?

Es gibt zwei verschiedene Kategorien an Patenten.
Einmal um die Befehlssätze auf anderen CPUs zu implementieren.
Und einmal die um Befehlssätze auf anderen CPUs zu emulieren.
Intel hat sich ausdrücklich auch zweiteres gesichert.

Wenn Intel das cross-licensing Agreement mit AMD beendet, hindert es beide, neue x86-CPUs auf den Markt zu bringen.

Wenn die Patente auf die Emulation gültig sind, dann setzt der neue Eigentümer Qualcomm einfach die Lizenzierungskosten so hoch, dass es für andere Anbieter unwirtschaftlich wird.

Wenn ich mir die Tests zu den Snapdragon-Windows-PCs anschaue würde ich die Kompatiblität keinesfalls als fantastisch bezeichnen. Außerdem, wenn Rosetta ohne die Intel-Patente so toll funktioniert, wozu braucht Qualcomm diese dann überhaupt?

Ob Microsoft und Apple die Intel-Patente verletzten ist nicht geklärt.
Apple ist auch vorsichtig und hat erstmal kein AVX bei Rosetta aktiv, obwohl es technisch kein Problem wäre.

Die Frage ist allerdings, wenn TSMC, Samsung oder GloFo Intel-Patente verletzen, warum hat Intel bisher nichts dagegen unternommen? Außerdem ist es fast sicher, dass die Fertiger sich in einen Rechtsstreit, in dem ihre Kunden auf Grund von Patenten auf Fertigungs-IP verklagt werden, einmischen würden und da diese über ebenfalls riesige Patentpools verfügen, könnte so etwas für Qualcomm schnell nach hinten losgehen.

Intel ist weitaus weniger klagefreudig als Qualcomm. TSMC direkt zu verklagen wäre ein Fehler, da Intel und Qualcomm auf die Geschäftsbeziehung zu TSMC angewiesen sind.
TSMC-Kunden zu verklagen kommt drauf an. Sind es nur kleine Kunden (wie RISC-V Hersteller) dann wird TSMC eher nicht reagieren.
Ungefähr so wie Nokia gerade Amazon und andere wegen H.264/H.265 verklagt, aber noch keiner der Zulieferer sich da eingemischt hat,

Das alles war für Oracle vollkommen uninteressant.

Und x86 ist für Qualcomm uninteressant. Ihr Kerngeschäft ist es, überteuerte ARM-CPUs zu verkaufen und das x86 IP ist dafür nur Mittel zum Zweck.

Das ist falsch. Mac, Windows und Linux bringen ihre jeweils eigenen Bibliotheken mit sich, die nicht miteinander kompatibel sind.

Wenn man Mac auf ARM und x86 unterstützt, und Windows und Linux auf x86, dann wäre es praktisch kein großer Aufwand, auch Windows und x86 auf ARM zu unterstützen. Es gibt eine Reihe von Programmen wo das so ist, und die Nutzer seit Jahren auf die Firmen einreden bitte doch ARM-builds für Windows und Linux, aber es passiert einfach nicht.

Üblicherweise werden Funktionen erst einmal in reinem C/C++/... Code geschrieben den der Compiler mit oder ohne Befehlssatzerweiterungen übersetzen kann. Die Inline-Assembler-Optimierungen werden dann in der Regel als alternative Codepfade implementiert, die per Macros ein- und auszuschalten sind.

Das gilt genau für die erste Version. Wenn der C/C++/... Codepfad nicht mehr benutzt wird dann wird er oft auch nicht mehr gepflegt und divergiert dann, sobald man Änderungen am Assembler vornimmt.

 

[Limit]

Ich meine dass die Software andere Rechenergebnisse liefert wenn man SSE/AVX/usw. benutzt als wenn man das nicht tut. Bei Gleitkommaberechnungen ist das immer eine lästige Sache. Hier ist eine gute Einführung in die Problematik.

Das kann eine lästige Sache sein, aber eine Grundregel beim Umgang mit Gleitkommazahlen ist, dass man diese niemals direkt vergleichen, sondern mit einem Delta arbeiten sollte. Wenn man darauf angewiesen ist, dass wirklich exakt das gleiche Ergebnis herauskommt, muss man entsprechende Vorkehrungen treffen. So lässt sich die FPU mittels Control-Word dazu bringen ebenfalls nur mit 32- bzw. 64-Bit Genauigkeit zu rechnen wodurch das Ergebnis dann identisch wäre.

Nein, das lag und liegt daran, dass die Unternehmen sich nicht darum scheren.

Wenn alle neuen x86-CPUs den Befehlssatz nicht mehr unterstützen werden die Unternehmen sich darum scheren.

Es gibt zwei verschiedene Kategorien an Patenten.
Einmal um die Befehlssätze auf anderen CPUs zu implementieren.
Und einmal die um Befehlssätze auf anderen CPUs zu emulieren.
Intel hat sich ausdrücklich auch zweiteres gesichert.

Wobei erstere die wertvollen sind und letztere bestenfalls eine Ergänzung um Konkurrenz durch Emulatoren zu behindern.

Wenn Intel das cross-licensing Agreement mit AMD beendet, hindert es beide, neue x86-CPUs auf den Markt zu bringen.

Zeitweise ja, mittel- und langfristig hingegen nicht.

Wenn die Patente auf die Emulation gültig sind, dann setzt der neue Eigentümer Qualcomm einfach die Lizenzierungskosten so hoch, dass es für andere Anbieter unwirtschaftlich wird.

Das wäre ein Problem für Apple und MS, aber nicht für AMD und den möglichen Käufer der x86-Patente.

Intel ist weitaus weniger klagefreudig als Qualcomm. TSMC direkt zu verklagen wäre ein Fehler, da Intel und Qualcomm auf die Geschäftsbeziehung zu TSMC angewiesen sind.
TSMC-Kunden zu verklagen kommt drauf an. Sind es nur kleine Kunden (wie RISC-V Hersteller) dann wird TSMC eher nicht reagieren.

Das wäre für TSMC aber im höchsten Maße geschäftsschädigend. Es stünde dann sogar im Raum, dass TSMC schadenersatzpflichtig gegenüber dem Kunden wäre, da in einem solchen Fall ja TSMC die eigentliche Patentrechtsverletzung begangen hätte. Falls TSMC oder irgendein anderer Fertiger Intel-Patente verletzen würde (worauf es keinerlei Hinweise gibt), würde ich in Qualcomms Situation mich nicht um die kleine Fische kümmern, sondern gleich Nvidia, Apple und Co verklagen, da gibt es viel mehr zu holen.

Ungefähr so wie Nokia gerade Amazon und andere wegen H.264/H.265 verklagt, aber noch keiner der Zulieferer sich da eingemischt hat

Der Fall ist etwas anders gelagert, da Amazon über mehr als genug Mittel verfügt sich selbst zu verteidigen und wenn sie die Zulieferer um Hilfe bitte würde, z.B. für Beweismittel oder ähnliches, werden sie die vermutlich auch bekommen. Ein Gegenbeispiel wäre z.B. das patent defense program von AOMedia.

Und x86 ist für Qualcomm uninteressant. Ihr Kerngeschäft ist es, überteuerte ARM-CPUs zu verkaufen und das x86 IP ist dafür nur Mittel zum Zweck.

Das Problem daran ist nur, dass sie eben fast 100Mrd.$ dafür ausgeben. Wenn sie die wertvollen x86-Patente nicht selbst nutzen und nicht weiterverkaufen, werden sie diese Kosten nie refinanzieren.

Wenn man Mac auf ARM und x86 unterstützt, und Windows und Linux auf x86, dann wäre es praktisch kein großer Aufwand, auch Windows und x86 auf ARM zu unterstützen.

Es würde die Sache leichter machen, weil man dann schon viele der Fallstricke kennt, aber man müsste immernoch einige Arbeit hineinstecken. Unabhängig davon dürfte die Menge der Software die auf x86 und ARM Mac sowie auf x86 Windows und Linux verfügbar ist eher gering sein. Die beste Chance hätte man vermutlich mit Software, die primär für Linux entwickelt wurde. Da diese Software aber generell leichter zu portieren ist, ist das in der Regel nicht die Software, wegen der man an eine bestimmte Plattform gebunden ist.

Das gilt genau für die erste Version. Wenn der C/C++/... Codepfad nicht mehr benutzt wird dann wird er oft auch nicht mehr gepflegt und divergiert dann, sobald man Änderungen am Assembler vornimmt.

Handoptimierter Assembler-Code wird in der Regel nur für kleine Codefragmente mit ganz speziellen Aufgaben genutzt. Daher kommt es eher selten vor, dass sich das gewünschte Ergebnis ändert. Aber selbst wenn, für gewöhnlich wird bei automatisierten Unit-Tests das Ergebnis des Assembler-Codes mit der Referenz-Implementierung verglichen und wenn diese nicht übereinstimmt, schlägt der commit fehlt.

 

[chithanh]

Wenn man darauf angewiesen ist, dass wirklich exakt das gleiche Ergebnis herauskommt, muss man entsprechende Vorkehrungen treffen.

Und eine dieser Vorkehrungen ist, dass alle Instanzen des Programms den gleichen Codepfad benutzen, und nicht eine die FPU, die andere SSE und die dritte AVX.

So lässt sich die FPU mittels Control-Word dazu bringen ebenfalls nur mit 32- bzw. 64-Bit Genauigkeit zu rechnen wodurch das Ergebnis dann identisch wäre.

Das bei der x87 FPU für 64-bit Genauigkeit richtig, aber für 32-bit falsch. Für deterministische 32-bit Float-Berechnungen braucht man SSE.

Wenn alle neuen x86-CPUs den Befehlssatz nicht mehr unterstützen werden die Unternehmen sich darum scheren.

Wenn aber einstweilig keine neuen x86-CPUs herauskommen und die Zukunft ARM ist, dann ist fraglich, ob sie je wieder damit anfangen werden, sich darum zu scheren.

Das wäre ein Problem für Apple und MS, aber nicht für AMD und den möglichen Käufer der x86-Patente.

Für AMD wäre bereits das Ende des Cross-licensing agreements das Problem. Aber AMD hat bereits gesagt, wenn die Kunden wollen, dann verkaufen sie ihnen auch ARM-CPUs, also denke ich ist AMD auf diese Eventualität vorbereitet.

Das wäre für TSMC aber im höchsten Maße geschäftsschädigend. Es stünde dann sogar im Raum, dass TSMC schadenersatzpflichtig gegenüber dem Kunden wäre, da in einem solchen Fall ja TSMC die eigentliche Patentrechtsverletzung begangen hätte. Falls TSMC oder irgendein anderer Fertiger Intel-Patente verletzen würde (worauf es keinerlei Hinweise gibt), würde ich in Qualcomms Situation mich nicht um die kleine Fische kümmern, sondern gleich Nvidia, Apple und Co verklagen, da gibt es viel mehr zu holen.

Nokia hat bereits praktisch alles was in der PC-Industrie Rang und Namen hat zu H.264/H.265 Lizenzzahlungen gezwungen. Keiner der Zulieferer hat sich da für die Beklagten eingesetzt.

Qualcomm ist natürlich nicht blöde und verklagt ohne guten Grund Firmen, die auch relevante Patente haben und mit Gegenklagen reagieren würden. RISC-V Anbieter würden nicht verklagt um Geld herauszupressen, sondern damit sie keine Konkurrenz mehr sind und sich nicht wehren können.

Ein Gegenbeispiel wäre z.B. das patent defense program von AOMedia.

Ja es gibt das, und auch noch idemnification aber in dem Geschäftsbereich gibt es soweit mir bekannt nichts derartiges.

Das Problem daran ist nur, dass sie eben fast 100Mrd.$ dafür ausgeben. Wenn sie die wertvollen x86-Patente nicht selbst nutzen und nicht weiterverkaufen, werden sie diese Kosten nie refinanzieren.

Doch. Sie müssen halt nur entsprechend mehr Snapdragons dadurch verkaufen und die nutzen ja dann die x86-Emulationspatente. Kommt dann ganz auf die Konversionsrate der bisherigen Intel-Kunden zur Chipsparte QCT an.
Abgesehen davon trägt die IP-Sparte QTL bereits 15% zum Umsatz und fast 50% zum Gewinn von Qualcomm bei, und mit den Intel-Patenten wird das sicher noch eine Ecke mehr.

Es würde die Sache leichter machen, weil man dann schon viele der Fallstricke kennt, aber man müsste immernoch einige Arbeit hineinstecken. Unabhängig davon dürfte die Menge der Software die auf x86 und ARM Mac sowie auf x86 Windows und Linux verfügbar ist eher gering sein. Die beste Chance hätte man vermutlich mit Software, die primär für Linux entwickelt wurde. Da diese Software aber generell leichter zu portieren ist, ist das in der Regel nicht die Software, wegen der man an eine bestimmte Plattform gebunden ist.

Oh, da gibt es zahlreiche Beispiele von verbreiteter und wichtiger Standardsoftware. Und eine auffällige Häufung gab es, nachdem Microsoft verfügt hatte, dass für die Copilot+-Zertifizierung auch eine ARM-Version nötig ist, wenn ich mich recht entsinne. Dann waren plötzlich ganz viele mit dabei. Von Adobe über DaVinci Resolve bis Slack, alle innerhalb weniger Monate, nachdem ihre Anwender sie teils jahrelang bekniet und angefleht haben.

 

[Limit]

Und eine dieser Vorkehrungen ist, dass alle Instanzen des Programms den gleichen Codepfad benutzen, und nicht eine die FPU, die andere SSE und die dritte AVX.

Und dennoch gibt es solche alternativen Codepfade in sehr vieler Software.

Das bei der x87 FPU für 64-bit Genauigkeit richtig, aber für 32-bit falsch. Für deterministische 32-bit Float-Berechnungen braucht man SSE.

Die Frage nach der Relevanz bleibt aber weiterhin bestehen. Im 32-Bit Modus der FPU kann es zwar noch zu geringfügigen Abweichungen kommen, aber diese gäbe es z.B. auch wenn man das ganze auf einem ARM-Chip ausführen würde, d.h. bei deinem vorher genannten Beispiel bräuchte man, sollte man ARM unterstützen wollen, separate Server je nach Prozessorarchitektur sofern man wirklich auf identische Ergebnisse bei Gleitkommaberechnungen angewiesen ist und das nicht einfach nur ein Bug war. Weiterhin ist SSE1/2/3? bereits patent-frei und SSE4/4.2 werden in 2-3 Jahren folgen. Spätestens dann wäre das Problem sowieso erledigt, zumindest auf x86-Seite.

Wenn aber einstweilig keine neuen x86-CPUs herauskommen und die Zukunft ARM ist, dann ist fraglich, ob sie je wieder damit anfangen werden, sich darum zu scheren.

Sollte Qualcomm die x86-Patente weiterverkaufen, dürfte der Käufer ein neues Abkommen mit AMD anstreben. In dem Fall würde es also bestenfalls eine kurze Zeit keine neuen x86-CPUs geben, evtl. werden die Kunden das wegen des Release-Zyklus überhaupt nicht merken. Sollte Qualcomm diese Patente weder verkaufen noch selbst nutzen (für x86-CPUs), dann hätte sie das aktuell wertvollste an Intel praktisch wertlos gemacht. Die Frage wäre dann wie lange AMD bräuchte um die Intel-Patente aus ihren Chips zu entfernen. Das ist sehr schwer von außen abzuschätzen, aber ich denke, dass AMD weniger Zeit braucht die Intel-Patente aus ihren CPUs zu entfernen als ARM-Anbieter brauchen um ernsthafte Alternative zu den x86-Chips zu bringen und dazu eine gut funktionierende Emulation von x86. Auch könnte ich mir vorstellen, dass die Regulierungsbehörden dann ein Wort mitsprechen werden was am Ende dazu führen könnte, dass Qualcomm zum Verkauf oder Lizenzierung der x86-Patente gezwungen wird.

Für AMD wäre bereits das Ende des Cross-licensing agreements das Problem. Aber AMD hat bereits gesagt, wenn die Kunden wollen, dann verkaufen sie ihnen auch ARM-CPUs, also denke ich ist AMD auf diese Eventualität vorbereitet.

Wenn ich als Kunde sowieso auf eine neue Architektur umstellen müsste, würde ich eine offene Architektur vorziehen, schon allein um ein vendor lock-in wie bei x86 und potentiell auch ARM (siehe versuchter Übernahmeversuch durch Nvidia) zu vermeiden.

Doch. Sie müssen halt nur entsprechend mehr Snapdragons dadurch verkaufen und die nutzen ja dann die x86-Emulationspatente.

Um die Kosten für die Übernahme wieder hereinzuholen müsste die Snapdragon-Käufe sich vervielfachen und das in relativ kurzer Zeit, denn mittelfristig könnte AMD wieder x86 Chips herausbringen. Aber selbst wenn die Kunden in großen Masse die Architektur wechseln wollen, hielte ich es für sehr viel wahrscheinlicher, dass sie echte x86-CPUs für Legacy-Software weiternutzen und dann für neue Software einen sauberen Schnitt machen wollen. Das bedeutet aber eben nicht zwangsweise, dass diese neue Architektur ARM sein muss und selbst wenn, dürfte das dazu führen, dass die Konkurrenz im ARM-Markt für Desktop-/Server sehr schnell sehr viel größer werden dürfte, denn es gäbe ja dann den ganzen x86-Marktanteil neu zu verteilen. Am Ende könnte sogar Apple der große Profiteur davon sein.

Oh, da gibt es zahlreiche Beispiele von verbreiteter und wichtiger Standardsoftware. Und eine auffällige Häufung gab es, nachdem Microsoft verfügt hatte, dass für die Copilot+-Zertifizierung auch eine ARM-Version nötig ist, wenn ich mich recht entsinne. Dann waren plötzlich ganz viele mit dabei. Von Adobe über DaVinci Resolve bis Slack, alle innerhalb weniger Monate, nachdem ihre Anwender sie teils jahrelang bekniet und angefleht haben.

Du redest hier von 0815-Standardsoftware, aber das ist eben nur die Spitze des Eisbergs. Bei der geht es nur darum ob genügend Kunden Interesse an Versionen für andere Architekturen/Betriebssysteme gibt. Diese waren nie der Grund warum es bislang keinen Weg an x86 vorbei gab, sondern Spezialsoftware. Diese hat zwar sehr viel weniger Nutzer, für diese ist sie aber häufig nicht zu ersetzen. Deswegen laufen in vielen Firmen auch immer noch uralte Systeme mit Windows 95/98/XP.

 

[chithanh]

Und dennoch gibt es solche alternativen Codepfade in sehr vieler Software.

Und in sehr vieler Software auch nicht. So setzt Microsoft Edge ab Version 128 zwingend SSE3 voraus.
Warum nehmen sie nicht einfach einen CPU dispatcher? Weil diese alternativen Codepfade auch mit Nachteilen wie größeren Binärdateien verbunden sind, selbst wenn Determinismus nicht erforderlich ist.

Die Frage nach der Relevanz bleibt aber weiterhin bestehen. Im 32-Bit Modus der FPU kann es zwar noch zu geringfügigen Abweichungen kommen,

Und jede noch so geringfügige Abweichung ist ein Problem wenn man Determinismus will.

aber diese gäbe es z.B. auch wenn man das ganze auf einem ARM-Chip ausführen würde,

Wenn man Emulation benutzt dann nicht, denn die Emulation ist genau.
Wenn man in cross-platform-Software-Determinismus will, dann nimmt man entsprechende Libraries wie streflop.

Sollte Qualcomm die x86-Patente weiterverkaufen,

Das halte ich für abwegig, sie wollen damit lock-in in ihre Snapdragons oder wenigstens Lizenzeinnahmen erzielen.

Auch könnte ich mir vorstellen, dass die Regulierungsbehörden dann ein Wort mitsprechen werden was am Ende dazu führen könnte, dass Qualcomm zum Verkauf oder Lizenzierung der x86-Patente gezwungen wird.

Die FTC unter Lina Khan würde wohl einschreiten, aber gegen sie läuft gerade die massive Lobbykampagne von US-Technologiefirmen, um sie durch jemanden zu ersetzen, der Übernahmen freundlicher gegenübersteht.
EU ist politisch gerade zu schwach gegenüber den USA und würde denke ich auf Druck der selben Leute, die gerade auf die FTC einwirken, einknicken.
China ist mittelfristig nicht an westlichen CPUs interessiert und baut lieber eigene, da würde es wohl ausreichen wenn Qualcomm und Zhaoxin sich einig werden.

Um die Kosten für die Übernahme wieder hereinzuholen müsste die Snapdragon-Käufe sich vervielfachen und das in relativ kurzer Zeit, denn mittelfristig könnte AMD wieder x86 Chips herausbringen. Aber selbst wenn die Kunden in großen Masse die Architektur wechseln wollen, hielte ich es für sehr viel wahrscheinlicher, dass sie echte x86-CPUs für Legacy-Software weiternutzen und dann für neue Software einen sauberen Schnitt machen wollen.

Nach Einschätzung von Analysten kommt Qualcomm auf rund 70% des Markts für AI-PCs dieses und nächstes Jahr. Das müssten sie fortsetzen auf den Rest des PC-Markts indem sie die Kunden vor die Wahl stellen: Eure x86-Software läuft entweder langsam oder gar nicht, oder auf unseren Snapdragons. Und sie können Intels bestehende x86-Chips weiterverkaufen.

Und wie gesagt, wenn sie nur Intels bisheriges Geschäft fortführen wird das auf absehbare Zeit nichts mit dem Kaufpreis hereinholen.

Das bedeutet aber eben nicht zwangsweise, dass diese neue Architektur ARM sein muss und selbst wenn, dürfte das dazu führen, dass die Konkurrenz im ARM-Markt für Desktop-/Server sehr schnell sehr viel größer werden dürfte, denn es gäbe ja dann den ganzen x86-Marktanteil neu zu verteilen. Am Ende könnte sogar Apple der große Profiteur davon sein.

Die einzige ernstzunehmende Alternative zu ARM ist RISC-V.
SPARC und MIPS sind am Markt bedeutungslos.
POWER wurde in einige HPC-Nischen verdrängt.
LoongArch, Sunway, usw. gibt es quasi nur in China.

Aber zu RISC-V muss erstmal das Ökosystem da sein, und daran arbeiten momentan viele kleine Hersteller, die gegenüber Qualcomm+Intel-Patenten verwundbar sind. Größere Unternehmen wie Google zieren sich noch; trotz gegenteiliger Ankündigungen haben sie es noch nicht einmal geschafft, Android offiziell für RISC-V herauszubringen (aber immerhin arbeiten sie dran). Bei Microsoft ist es noch schlimmer, da musste .NET erst durch eine kleine Drittfirma auf RISC-V portiert werden, und an Windows ist noch gar nicht zu denken. Microsoft ist im Client-Markt zudem auch abhängiger von Qualcomm als umgekehrt.

 

[Limit]

Und in sehr vieler Software auch nicht. So setzt Microsoft Edge ab Version 128 zwingend SSE3 voraus.

Sehr schlechtes Beispiel. Wenn Version 127 noch ohne SSE3 lief und Version 128 keine komplette Neuentwicklung darstellt, dann werden die Non-SSE3 Codepfade mit sehr hoher Wahrscheinlichkeit weiterhin vorhanden sein nur MS hat sich entschlossen zukünftig mit SSE3-Zwang zu compilieren.

Warum nehmen sie nicht einfach einen CPU dispatcher? Weil diese alternativen Codepfade auch mit Nachteilen wie größeren Binärdateien verbunden sind, selbst wenn Determinismus nicht erforderlich ist.

Wenn die Binary-Größe so wichtig ist, kannst du auch je nach Befehlssatzerweiterung eine andere Binary compilieren.

Und jede noch so geringfügige Abweichung ist ein Problem wenn man Determinismus will.
Wenn man Emulation benutzt dann nicht, denn die Emulation ist genau.

Mich würde es nicht überraschen, wenn das zumindest aktuell nicht der Fall ist, denn man könnte FP-Operationen von SSE nicht mittels FP-Operation von ARM ausführen,, sondern müsste das Vorgehen der SSE-Einheit in Software zumindest teilweise nachbauen. Das wäre Gift für die Performance.

Wenn man in cross-platform-Software-Determinismus will, dann nimmt man entsprechende Libraries wie streflop.

Die würde auch mit x86 ohne SSE funktionieren.

Das halte ich für abwegig, sie wollen damit lock-in in ihre Snapdragons oder wenigstens Lizenzeinnahmen erzielen.

Das dürfte schwierig werden. Der Lizenznehmer von Intels x86-Patenten könnte ohne AMDs Patente nicht ohne weiteres x86-CPUs herstellen. Wenn es also kein Abkommen zwischen Qualcomm, dem Lizenznehmer und AMD zustande käme, würde das den Wert der Patente stark mindern.

Die FTC unter Lina Khan würde wohl einschreiten, aber gegen sie läuft gerade die massive Lobbykampagne von US-Technologiefirmen, um sie durch jemanden zu ersetzen, der Übernahmen freundlicher gegenübersteht.
EU ist politisch gerade zu schwach gegenüber den USA und würde denke ich auf Druck der selben Leute, die gerade auf die FTC einwirken, einknicken.
China ist mittelfristig nicht an westlichen CPUs interessiert und baut lieber eigene, da würde es wohl ausreichen wenn Qualcomm und Zhaoxin sich einig werden.

Es geht nicht nur um die FTC. Es gibt Gesetze nach denen eine Firma die Erteilung einer Zwangslizenz beantragen kann, wenn der Patentinhaber keine ausreichende Nutzung des Patents nachweisen kann. In manchen Ländern geht es sogar soweit, dass ein über längere Zeit ungenutztes Patent von jedem ohne Lizenz genutzt werden kann.

Nach Einschätzung von Analysten kommt Qualcomm auf rund 70% des Markts für AI-PCs dieses und nächstes Jahr.

Was ist ein AI-PC? Jede moderne CPU und GPU kann AI-Berechnungen ausführen. Ich vermute die 70% beziehen sich darauf, was MS zertifiziert. Das Qualcomm da führt ist daher eher nur eine politische Entscheidung Microsofts und hat nichts mit der eigentlichen Hardware zu tun. Wenn man dann noch berücksichtigt, dass die meisten Nutzer überhaupt kein Interesse an den AI-Funktionen von Windows haben, würde sich der Wert dieses Ergebnisse weiter relativieren, selbst wenn sie so eintreffen sollten.

Das müssten sie fortsetzen auf den Rest des PC-Markts indem sie die Kunden vor die Wahl stellen: Eure x86-Software läuft entweder langsam oder gar nicht, oder auf unseren Snapdragons.

Also kurzfristig hätte man eher die Wahl zwischen Software läuft problemlos und performant auf "echten" x86-CPUs oder langsamer bzw. gar nicht auf Snapdragons. Das dürfte für die meisten eine einfache Entscheidung sein.

Und wie gesagt, wenn sie nur Intels bisheriges Geschäft fortführen wird das auf absehbare Zeit nichts mit dem Kaufpreis hereinholen.

Das widerspreche ich nicht, nur würde mMn ein Vorgehen wie du es vorschlägst die Erträge auf der Intel-Seite mittelfristig gegen 0 gehen lassen ohne dafür auch nur eine ansatzweise vergleichbare Steigerung der Erträge bei den Snapdragons zu bewirken.

Die einzige ernstzunehmende Alternative zu ARM ist RISC-V.
SPARC und MIPS sind am Markt bedeutungslos.
POWER wurde in einige HPC-Nischen verdrängt.
LoongArch, Sunway, usw. gibt es quasi nur in China.

Sollte x86 vom Desktop- und Servermarkt verschwinden werden die Karten neu gemischt. RISC-V wäre aber auch für mich der wahrscheinlichste Konkurrent von ARM, obwohl ich OpenPOWER geringe Außenseiterchancen zugestehe.

Aber zu RISC-V muss erstmal das Ökosystem da sein, und daran arbeiten momentan viele kleine Hersteller, die gegenüber Qualcomm+Intel-Patenten verwundbar sind.

Das ist korrekt, aber du lässt außer Acht, dass im Falle eines x86-Endes eine ganz neue Situation entsteht. Für einige Zeit wird es einen Konkurrenzkampf um die x86-Nachfolge geben und der wird vermutlich mit mehreren Architekturen ausgetragen werden. Arm hat dabei sicherlich die besten Chancen, aber ich würde sie keinesfalls bereits jetzt zum Sieger erklären und selbst wenn Arm gewinnen sollte, muss Qualcomm nicht der Gewinner sein.

Größere Unternehmen wie Google zieren sich noch; trotz gegenteiliger Ankündigungen haben sie es noch nicht einmal geschafft, Android offiziell für RISC-V herauszubringen (aber immerhin arbeiten sie dran).

RISC-V ist für diese Firmen bisher eher nur eine mögliche Option für die Zukunft. Man beobachtet die Situation, probiert hier und da mal was aus, aber im Endeffekt wartet man nur ab. Das gilt aber unter der aktuellen Situation mit x86 fest im Sattel im Desktop und Server-Bereich und würde sich bei einem x86-Ende sehr schnell ändern und ich sehe durchaus die Möglichkeit dass einige Techfirmen lieber RISC-V als Arm unterstützen würden.

Bei Microsoft ist es noch schlimmer, da musste .NET erst durch eine kleine Drittfirma auf RISC-V portiert werden, und an Windows ist noch gar nicht zu denken. Microsoft ist im Client-Markt zudem auch abhängiger von Qualcomm als umgekehrt.

Microsoft zähle ich nicht zu dem Kreis an Firmen. Die haben sich ja bereits mehr oder weniger für Arm und gegen RISC-V entscheiden. Allerdings bröckelt die Position von Windows ein wenig in letzter Zeit. MS kann nicht mehr so einfach alles durchdrücken was sie wollen. Das sieht man an dem mangelnden Erfolg von Windows on Arm.

 

[chithanh]

Sehr schlechtes Beispiel. Wenn Version 127 noch ohne SSE3 lief und Version 128 keine komplette Neuentwicklung darstellt, dann werden die Non-SSE3 Codepfade mit sehr hoher Wahrscheinlichkeit weiterhin vorhanden sein nur MS hat sich entschlossen zukünftig mit SSE3-Zwang zu compilieren.

Vielleicht bist du im Thema verrutscht. Bei Edge geht es genau um Kompilieren mit CPU dispatcher und mehrere Kodepfade für verschiedene Instruktionssätze, und warum man das meistens nicht in Software die an Anwender raus geht will. Daher ein hervorragendes Beispiel.

Das mit der Neuentwicklung wurde im Rahmen der ARM-Portierung thematisiert.

Wenn die Binary-Größe so wichtig ist, kannst du auch je nach Befehlssatzerweiterung eine andere Binary compilieren.

Den CPU dispatcher nimmt man für bestimmte Spezialsoftware und performancekritische Bibliotheken noch in Kauf. Mehrere Releases der Software zu produzieren und allesamt an die Kunden zu verteilen wäre auch noch zusätzlich Aufwand. Dann hätte man das schlechteste aus beiden Welten, und das macht daher praktisch niemand.

Mich würde es nicht überraschen, wenn das zumindest aktuell nicht der Fall ist, denn man könnte FP-Operationen von SSE nicht mittels FP-Operation von ARM ausführen,, sondern müsste das Vorgehen der SSE-Einheit in Software zumindest teilweise nachbauen. Das wäre Gift für die Performance.

Genau das passiert aber.
x87 FPU wird in Software emuliert, da hat man keine Wahl wenn man genau sein will. Einfach auf die FPU der Host-CPU abbilden ist möglich aber ungenau.
SSE/SSE2/... lässt sich gut auf die ARMv8-Vektoreinheiten abbilden.
AVX/AVX2 braucht wiederum Tricks, weil ARMv8 nur 128-bit Vektoreinheiten hat aber AVX 256-bit benutzt. Die CPU-Emulatoren box86 und FEX können es inzwischen beide. Nur Apple und Microsoft sind entweder langsam oder scheuen eine mögliche Patentverletzung.

Die würde auch mit x86 ohne SSE funktionieren.

Die Aussage hat doch keine Relevanz zu meiner Aussage wie man auf x86 und ARM plattformübergreifend deterministische Berechnungen hinbekommt?
Und mit x87 FPU ohne SSE gibt es nach wie vor keinen Determinismus für 32-bit floats.

Das dürfte schwierig werden. Der Lizenznehmer von Intels x86-Patenten könnte ohne AMDs Patente nicht ohne weiteres x86-CPUs herstellen.

Ich meine Qualcomm lizenziert nicht zum Herstellen, sondern zum emulieren.

Es geht nicht nur um die FTC. Es gibt Gesetze nach denen eine Firma die Erteilung einer Zwangslizenz beantragen kann, wenn der Patentinhaber keine ausreichende Nutzung des Patents nachweisen kann.

Qualcomm wird sicher noch lange x86-CPUs bauen, aber eher nicht weiterentwickeln. Von daher sehe ich keine Handhabe für eine Zwangslizenz.

Was ist ein AI-PC?

Es ist ein Marketing-Begriff für das was sich Microsoft unter der Zukunft der PCs vorstellt, und aktuell sind sie fast ausschließlich mit hochpreisigen Qualcomm-CPUs ausgestattet. AMD und Intel kommen gerade erst dazu, mit noch höherpreisigen Modellen.

Jede moderne CPU und GPU kann AI-Berechnungen ausführen.

Das ist richtig, aber die Fähigkeit ist nicht das entscheidende. Das Vorhandensein einer NPU ist wichtig, weil nur damit AI effizient nebenbei möglich ist, während der Benutzer am System arbeitet. Würde man damit die CPU oder GPU beanspruchen, dann drehen die Lüfter hoch, und die Systemauslastung steigt, und die Akkulaufzeit sinkt.

Wenn man dann noch berücksichtigt, dass die meisten Nutzer überhaupt kein Interesse an den AI-Funktionen von Windows haben, würde sich der Wert dieses Ergebnisse weiter relativieren, selbst wenn sie so eintreffen sollten.

Die Nutzer haben in der Tat kein Interesse, und von daher schrieb ich auch dass Qualcomm die 70% auf den gesamten bisherigen x86-Markt ausdehnen muss um den Kaufpreis wieder reinzuholen.
Und das geht nur, wenn sie die Kunden erfolgreich von x86 vertreiben und genug davon zu Snapdragon wechseln.
Es geht insbesondere nicht, wenn sie lediglich Intels bisheriges Geschäft fortführen.

Das widerspreche ich nicht, nur würde mMn ein Vorgehen wie du es vorschlägst die Erträge auf der Intel-Seite mittelfristig gegen 0 gehen lassen ohne dafür auch nur eine ansatzweise vergleichbare Steigerung der Erträge bei den Snapdragons zu bewirken.

Qualcomm müsste wegen der laufenden Kosten wahrscheinlich die Fabs mittelfristig dafür abstoßen, aber ich denke das würde Intel auch ohne Übernahme tun.

 

[Limit]

Wir hatten eine lange und denke ich recht aufschlussreiche Diskussion. Ich glaube nicht, dass hier einer den anderen von seiner Sichtweise überzeugen wird, daher wird das mein letzter Post zu dem Thema.

Vielleicht bist du im Thema verrutscht. Bei Edge geht es genau um Kompilieren mit CPU dispatcher und mehrere Kodepfade für verschiedene Instruktionssätze, und warum man das meistens nicht in Software die an Anwender raus geht will. Daher ein hervorragendes Beispiel.

Mehrere Releases der Software zu produzieren und allesamt an die Kunden zu verteilen wäre auch noch zusätzlich Aufwand. Dann hätte man das schlechteste aus beiden Welten, und das macht daher praktisch niemand.

Es geht doch darum, dass MS, sollte SSE3 und andere Befehlssatzerweiterungen aus welchem Grund auch immer zukünftig nicht mehr nutzbar sein, ohne weiteres in kurzer Zeit eine Version ohne eben diese Erweiterungen herausbringen könnte. Natürlich wäre eine einzige Version die zur Laufzeit die Erweiterungen ein-/ausschalten kann bequemer, aber falls es wirklich nötig ist, werden sie (und viele andere) auch mit verschiedenen Versionen arbeiten (siehe Übergang x86 -> x86-64).

Genau das passiert aber.
x87 FPU wird in Software emuliert, da hat man keine Wahl wenn man genau sein will. Einfach auf die FPU der Host-CPU abbilden ist möglich aber ungenau.
SSE/SSE2/... lässt sich gut auf die ARMv8-Vektoreinheiten abbilden.

Meine Kenntnisse im Bereich FP-Operationen von SSEx und ARM-v8 sind begrenzt, aber laut ChatGPT kann man diese nicht direkt abbilden ohne unterschiedliche Ergebnisse zu riskieren. Auch was ich in Intels Guide zum Portieren von Arm Neon nach SSE gelesen habe, würde darauf hindeuten. Um gleiche Ergebnisse garantieren zu können, müsste man also entweder wie bei x87 in Software emulieren oder die Beschränkungen bei Nutzung von SSE bzgl. Portierbarkeit nach Neon einhalten.

Die Aussage hat doch keine Relevanz zu meiner Aussage wie man auf x86 und ARM plattformübergreifend deterministische Berechnungen hinbekommt?
Und mit x87 FPU ohne SSE gibt es nach wie vor keinen Determinismus für 32-bit floats.

Was ich meinte ist, dass du die selbe Bibliothek auch auf einem x86-Chip ohne SSE benutzen könntest. Die Software-FP-Implementierung ist zwar langsam, aber das ist sie auf Arm ebenso. Aber ich weiß nicht, warum wir überhaupt darüber reden. SSE1/2/3 sind bereits patent-frei, SSE4/4.2 werden es bald sein. Die AVX-Patente laufen zwar noch eine Weile, aber werden selten zwingend vorausgesetzt.

Ich meine Qualcomm lizenziert nicht zum Herstellen, sondern zum emulieren.

Niemand wird dauerhaft einen Emulator verwenden wollen. Entweder man bleibt bei den echten x86-CPUs oder man portiert. Zudem gibt es bereits Emulatoren, die ohne die Patente auskommen. Die Patente haben daher nur einen begrenzten Nutzen für eine begrenzte Zeit. Damit kann Qualcomm vielleicht ein wenig Geld für die Kaffeekasse einnehmen, mehr aber auch nicht.

Qualcomm wird sicher noch lange x86-CPUs bauen, aber eher nicht weiterentwickeln. Von daher sehe ich keine Handhabe für eine Zwangslizenz.

Daran habe ich nicht gedacht. Da müssten die Behörden dann tatsächlich über das Wettbewerbsrecht an die Sache herangehen und da stimme ich dir zu, dass das eine langwierige und keinesfalls sichere Sache wäre.

Es ist ein Marketing-Begriff für das was sich Microsoft unter der Zukunft der PCs vorstellt, und aktuell sind sie fast ausschließlich mit hochpreisigen Qualcomm-CPUs ausgestattet. AMD und Intel kommen gerade erst dazu, mit noch höherpreisigen Modellen.

Die Tests von Snapdragon Elite und Ryzen AI hier auf computerbase liegen nicht mal einen Monat auseinander. Es liegt also nicht daran das AMD bzw. Intel mit der Hardware so langsam ist, sondern einzig und allein daran, dass Microsoft Windows on Arm pushen will.

Die Nutzer haben in der Tat kein Interesse, und von daher schrieb ich auch dass Qualcomm die 70% auf den gesamten bisherigen x86-Markt ausdehnen muss um den Kaufpreis wieder reinzuholen.

Das mit AI kannst du dann doch gleich weg lassen und sagen, dass Qualcomm 70% des x86-Marktes braucht, d.h. praktisch fast 100% der Nutzer von Intel x86-Chips müssten zu Qualcomm wechseln. Das ist ein recht ambitioniertes Vorhaben.

Und das geht nur, wenn sie die Kunden erfolgreich von x86 vertreiben und genug davon zu Snapdragon wechseln.
Es geht insbesondere nicht, wenn sie lediglich Intels bisheriges Geschäft fortführen.

Wenn sie Intel bisheriges Geschäft fortführen, hätte sie so 70-75% des Marktes, das würde also durchaus aufgehen.

Qualcomm müsste wegen der laufenden Kosten wahrscheinlich die Fabs mittelfristig dafür abstoßen, aber ich denke das würde Intel auch ohne Übernahme tun.

Das Problem wird sein einen Käufer zu finden. Für die älteren Fabs würden sie vermutlich recht einfach Käufer finden, denn die haben ihre Kosten bereits wieder hereingespielt und könnten daher entsprechend günstig verkauft werden. Bei den neueren könnte es schwieriger werden. Der Kreis der potentiellen Käufer ist hier deutlich kleiner und da die Fabs nicht leading edge sind, werden sie diese vermutlich nur mit Verlusten verkaufen können. Ich denke, dass Intel deswegen bisher auch eher über eine Abspaltung als einen Verkauf nachgedacht hat.