News Sound Wave: AMD soll an einer Arm-CPU für ein 2026er Surface arbeiten

Microsoft macht eins auf Apple mit den Surface-Geräten. Nur da Microsoft (wie immer) es nur halbherzig tut, denn sie leben nach wie vor aus ihrem alten quasi-Monopol und von uns allen, die aus Kompatibilitätsgründen an Windows festhalten (keiner will Windows, schon gar kein neues), wird es scheitern. Die drei ARM-Geräte, die andere Hersteller brachten, sind ja auch gefloppt. Die CPU ist ja auch nicht das Problem, sondern die Software. Wer verballert denn die ganzen Ressourcen für nix? Letztendlich bauen AMD und Intel CPUs, die immer mehr Kerne haben, die den ganzen Windows Müll in low power im Hintergrund abfrühstücken können während ein älteres Gerät da auf Volllast hochläuft nur weil Windows mal wieder Windows-Dinge tut.

AMD hat ne Sparte, die liefert was der Kunde will. Microsoft will ne ARM-CPU mit (mutmaßlich) ner Radeon GPU, why not? AMD wird darunter nicht leiden. Microsoft wird das Teil ohnehin fast nur unbedarften Anwendern andrehen können, die die MS-Bubble nicht verlassen und so gar nicht merken, was sie da haben (sofern MS ihre eigene Software in den Griff bekommt). Als Alternative zu anderen Geräten wird das keiner kaufen, außer vielleicht aus purer Neugier. Zudem: Da wird ARM draufstehen und nicht AMD.

Der Punkt, an dem sie auf ARM hätten gehen können, war als sie auch Windows Phone am Start hatten. Was war das für ein cooles Konzept mit dem Dock und dann hat man einen PC. Aber nö, statt das technisch gut und mit Durchhaltevermögen umzusetzen, kleistert man Desktopanwendern Kacheln hin. Es war so traurig. Das wäre Mehrwert gewesen. Wo ist denn heute da der Mehrwert? Die sollen ihr Windows mal hinbekommen, da haben sie genug zu tun, und sich nicht in so was verzetteln. Oder wieder Telefone bringen. Wär gut da einen weiteren Player zu haben. Aber das würde wahrscheinlich erneut floppen, weil das jeder noch in Erinnerung hat.
 
  • Gefällt mir
Reaktionen: Matthias B. V.
ETI1120 schrieb:
War sie tatsächlich auf dem Markt?
Ja, gab u.a. von der Firma SoftIron eine Produktreihe namens Overdrive. Ich hatte mir zum Release Anfang 2017 das Overdrive 1000 gekauft.
Bei heise gab es u.a. einen Bericht dazu.
 
  • Gefällt mir
Reaktionen: mae
Falls Du es noch immer nicht bemerkt hast, ich spiele auf Deine Aussage an, dass jetzt zwar keiner eigene Kerne entwickelt, dies aber in Zukunft geschieht.

Qualcomm aktuell der einzige Anbieter hat eigene Kerne die nächsten Anbieter nicht.
 
Diese Aussage ist offensichtlich falsch weil immer weniger Firmen eigene Arm Kerne entwickeln.

Und wie gesagt das ist offensichtlich das was Arm beabsichtigt.
 
ETI1120 schrieb:
Hinzu kommt dass alle Produktlinien die AMD von Xlinix übernommen hat und CPU-Kerne beihalten Arm Kerne verwenden.
Die ARM-Kerne die Xilinx als Hardware oder Softcores im Einsatz hat und hatte waren immer relativ klein. Das bringt AMD nahezu nichts wenn das Ziel größere Applikationsprozessoren sind.
ETI1120 schrieb:
Was Du beschreibst hat allerdings zu großen Anteil gar nichts mit der ISA und den CPU-Kernen zu tun, sondern damit welchen Softwarestack man unterstützen muss. Apple hat bei M1 komplett bei null angefangen. Apple musste nicht auf alte Software Rücksicht nehmen. Die Compiler konnten alle Features des M1 ausnützen.

X86 hat den Vorteil des riesigen Softwareangebots, was aber auf der anderen Seite bedeutet, dass in der Software jede Menge Altlasten stecken. Die einfach abzuschneiden geht nicht, weil dann alle schreien, dass die CPU inkompatibel ist.
Einen riesigen Katalog an (teils alter) Software zu haben ist im Zweifelsfall eben auch ein Nachteil, wenn diese Software gescheite Entwicklung ausbremst. Um es beim Namen zu nennen, bei der minimalen Größe der Pages bremst Microsoft Windows: https://devblogs.microsoft.com/oldnewthing/20210510-00/?p=105200 . In der BSD/Linux-Welt schaut es so aus, dass poplige Raspis mit 16kB Pages umgehen können und der Softwarekatalog auch halbwegs steht: https://www.raspberrypi.com/news/benchmarking-raspberry-pi-5/
Bei den Raspis tut sich da bei der Performance wenig, die (L1) Caches bleiben ja von der größe Gleich und die Logik für die Verwaltung samt Latenzen ebenso.

Und die Hyperscaler haben das Problem mit gammliger Altsoftware im Zweifelsfall nicht, entsprechend sollte man denen ein Angebot machen, welches sich an deren Anforderungen richtet und nicht an die Anforderungen des rückständigsten Marktteilnehmers. Wenn das mit x86 nicht möglich ist, wird es halt ARM.

foofoobar schrieb:
Die Abkündigung der X86-Altlasten wurde von Intel abgekündigt.
OAAARRRRRRRR
 
Piktogramm schrieb:
Die ARM-Kerne die Xilinx als Hardware oder Softcores im Einsatz hat und hatte waren immer relativ klein. Das bringt AMD nahezu nichts wenn das Ziel größere Applikationsprozessoren sind.
Es geht darum, dass AMD im Produktportfolio schon jede Menge Armkerne hat. Nicht darum dass AMD einen Zynq oder Versal ins Surface einbauen wird.

AFAIU sind das alles Standardkerne von Arm.

Piktogramm schrieb:
Einen riesigen Katalog an (teils alter) Software zu haben ist im Zweifelsfall eben auch ein Nachteil, wenn diese Software gescheite Entwicklung ausbremst.
Einen großen Softwarestack zu haben, zu dem man kompatibel bleiben will hat eben zwei Seiten.

Aber Dinge die man nicht ändert, um zu alte Software kompatibel zu bleiben, sind eben keine Limitierung durch die ISA sondern Limitierungen durch den Softwarestack.

Alte Software wegzuschmeißen wird Arm im PC- und Server-Umfeld nicht mehr so leicht fallen wie im Embedded- und Mobilfon-Umfeld.

foofoobar schrieb:
Die Abkündigung der X86-Altlasten wurde von Intel abgekündigt.
Was nun folgerichtig ist, wenn man eine X86 Advisory Group einberuft.

Und das hätten Intel und AMD schon 20 Jahre früher machen müssen. Aber Intel war ja auf dem Trip über die Befehlssatzerweiterungen alle aus dem X86-Markt zu drängen. Wenn Intel bei 64 Bit nicht AMD den Vortritt gelassen hätte, wäre es Intel IMO gelungen.
 
ETI1120 schrieb:
Und das hätten Intel und AMD schon 20 Jahre früher machen müssen. Aber Intel war ja auf dem Trip über die Befehlssatzerweiterungen alle aus dem X86-Markt zu drängen. Wenn Intel bei 64 Bit nicht AMD den Vortritt gelassen hätte, wäre es Intel IMO gelungen.
Lies meinen Satz noch mal.
Und Intel hat eben nicht AMD den Vortritt bei X64 gelassen, es war MS die AMD den Vortritt gelassen haben.
 
  • Gefällt mir
Reaktionen: Piktogramm
ETI1120 schrieb:
Aber Dinge die man nicht ändert, um zu alte Software kompatibel zu bleiben, sind eben keine Limitierung durch die ISA sondern Limitierungen durch den Softwarestack.
Nicht Limitierung durch die ISA, aber die ISA ist dadurch an (Imho sinnvoller) Weiterentwicklung gehindert, was dann wirklich ein Problem der ISA ist.

ETI1120 schrieb:
Alte Software wegzuschmeißen wird Arm im PC- und Server-Umfeld nicht mehr so leicht fallen wie im Embedded- und Mobilfon-Umfeld.
Die derzeit finanzstärksten Kunden haben das Problem alter, ranziger Software tendenziell nicht. Wenn man an deren Geld will muss man deren AArch64 Eigendesigns das Wasser abgraben. Das wird aber schwierig, wenn die Entwicklung einer ISA dadurch ausgebremst wird, dass da Kunden Investitionen scheuen und so viel Rücksicht erfahren, dass die ISA nicht gescheit weiterentwickelt wird.

Und Altlasten, im Serverumfeld abseits von WinServer auf Blech[1] ist das Thema doch durch. Designs und Anwendunen mit >4kB minimal Pagesize sind etabliert, die Software drumherum auch und für Gammelsoftware wird Qemu untergeschnallt. Wobei der Linuxkernel mittlerweile wohl alles an [4; 8; 16; 32; 64]kB Pages frisst und auch das Storagesubsystem mittlerweile von der Pagesize vom Prozessor abgekoppelt ist: https://lwn.net/Articles/822868/

Selbst am PC, wie bereits geschrieben. Linux Desktop in Form von Raspberries haben da kein Problem mehr mit Altlasten, Android ist auf einem gutem Weg, unter iOS/MacOS ist es sowieso Schnee von Gestern. Windows on ARM schaut auch nicht all zu schlecht aus, abgesehen davon, dass der NT-Kernel nachwievor 4K Pages will, ohne dass mir bekannt wäre, dass Microsoft da dahinter ist :/. Lustigerweise kann allerhand Software von Microsoft 16k Pages ja schon, inkl. .net
 
foofoobar schrieb:
Lies meinen Satz noch mal.
Wenn man eine Advisory Group einberuft, ist es folgerichtig das eigene Papier öffentlich zurück zu ziehen.

Einige Befehlserweiterungen pusht Intel aber trotzdem noch.
foofoobar schrieb:
Und Intel hat eben nicht AMD den Vortritt bei X64 gelassen, es war MS die AMD den Vortritt gelassen haben.
Intel hat AMD den Vortritt gelassen. Intel hat verkündet dass es für X86 keine 64 Bit Erweiterung geben wird.

AMD hat dann AMD 64 veröffentlicht, Microsoft hatte zugesichert es zu unterstützen. Intel kam später, als offensichtlich wurde das AMD64 ausreichend Unterstützung bekommt um erfolgreich zu sein. Microsoft hat sich dann geweigert das später veröffentlichte Intel 64 zu unterstützen.

Wenn Intel die eigene 64 Bit Erweiterung, gebracht hätte, als es Zeit dafür war, wäre das ganze vollkommen anders gelaufen. Oder glaubst Du dass Microsoft AMD64 anstatt des früher veröffentlichten Intel 64 unterstützt hätte?

Die Geschichte hat sogar eine Pointe, die X86 Leute bei Intel hatten ihre Erweiterung schon fertig und auch im Chip implementiert, mussten sie aber auf höhere Weisungen deaktivieren.
 
@ETI1120
Ich kenne die Geschichte auch so, dass AMD mit AMD64 schneller an der Öffentlichkeit war, Intel intern, parallel Yamhill, EMT64T bzw. Intel64 entwickelte mit ein paar Inkompatibilitäten zu AMD. Wobei Microsoft dann klar geäußert hat, dass sie nur AMD64 unterstützen werden, woraufhin Intel einlenkte.

Und wie hängt bitte die Advisory Group mit dem Rückzieher von x86s zusammen? APX, AVX10/20 kamen alls vor diesem Zusammenschluss und blieben halbwegs unberührt. Allenfalls gab es (endlich) den Rückzieher bei AVX, dass es 128bit Implementierungen geben darf.
 
Wenn ich eine Advisory Group gründe und sie den Inhalt von X86S nicht besprechen und absegnen soll, kann ich es gleich lassen.

AFAIU geht es bei der X86S vor allem darum wie ein System mit X86 initialisiert wird und welche Systemstates es hat.

Das alles hätten AMD und Intel schon vor 20 Jahren machen müssen. AMD hat zwar einiges aufgeräumt aber sie könnten eben kein Tabula Rasa machen da sie sonst inkompatibel gewesen wären. AMD und Intel gemeinsam hätte viel weiter gehen können. Und dann kann man ja auch sagen, XYZ wird noch behalten, aber in 4 Jahren fliegt es raus.

Im übrigen hat niemand Intel vorgeworfen ein Talent für das Design einer ISA zu haben.
Ergänzung ()

Im übrigen sehe ich die Zukunft von X86 nicht so rosig. Aber das hat eben nichts damit zu tun das X86 CPUs nicht mehr weiter entwickelt werden können oder dass der Software Stack diese Weiterentwicklung verhindert.

Du musst Dir nur Mal anschauen welchen Markt X86 noch abdeckt. Es ist nur noch PC und Servermarkt.

Auf allen Wachstumsmärkte spielt X86 kaum eine Rolle.

Hinzu kommt dass die CPU ihre dominierende Rolle einbüßt.

Man muss nur Mal anschauen wie viele Kerne von AMD und Intel im Vergleich zu Arm und RISC V entwickelt werden.

Bei Arm bin ich mir nicht sicher wie es weiter geht. Keine Altlasten zu haben bedeutet eben auch dass man einfach wechseln kann.

Da es Nvidia endlich geschafft hat ihre Rücklösung auszuliefern hat der Arm Marktteil einen Sprung nach oben gemacht. Und das wird weiter gehen. Die Frage ist wen es mehr trifft AMD oder Intel.

Heute machen Gerüchte die Runde die nächste XBOX kommt mit Qualcomm SoC.

Die AI Kiste von Nvidia mit dem GB10 wird sich gut verkaufen. Und Qualcomm bereitet die Runde 2 vor.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Piktogramm
ETI1120 schrieb:
@foofoobar Danke für den Link. Jetzt weiß ich wieder warum ich mit heise keine Zeit mehr verschwende.
Und wer lesen kann ist wie immer klar im Vorteil:
Und dass er kein großer Freund des Itanium war, galt Insidern als offenes Geheimnis. Stattdessen hatte er mit dafür gesorgt, dass bei Intel unter dem Codenamen Yamhill eine durchaus ähnliche Erweiterung wie AMDs x86-64 entwickelt wurde. Die war undokumentiert schon im ersten Pentium 4 (Willamette) eingebaut, aber damals in der Intel-Chefetage nicht willkommen.
 
@foofoobar Ich hab's gelesen, auch diese Stelle gelesen, und auch festgestellt dass es um denselben Sachverhalt geht wie in dem Thread auf X. Ich dachte es könnte interessieren eine andere Sichtweise des Sachverhalts zu lesen, deshalb habe ich den Thread verlinkt.

Da wir alle 3 dieselbe Erinnerung an den Sachverhalt hatten, kam ich ich nicht auf die Idee dass man meinen Post als Widerspruch interpretieren kann.

Das "Jetzt weiß ich wieder warum ich mit heise keine Zeit mehr verschwende" bezog sich auf die Art und Weise wie der Artikel von heise geschrieben ist. Er ist handwerklich unterste Schublade, wie die meisten Artikel bei heise. Ich habe mein ct Abo gekündigt, als mir klar wurde, dass die Leute bei heise gar nicht wollen, dass die Leser die Artikel verstehen.
 
ETI1120 schrieb:
Das "Jetzt weiß ich wieder warum ich mit heise keine Zeit mehr verschwende" bezog sich auf die Art und Weise wie der Artikel von heise geschrieben ist. Er ist handwerklich unterste Schublade, wie die meisten Artikel bei heise. Ich habe mein ct Abo gekündigt, als mir klar wurde, dass die Leute bei heise gar nicht wollen, dass die Leser die Artikel verstehen.
Wenn du solche Bröckchen von Twitter besser verdauen kannst, darfst du dir gerne daraus deine Meinung ableiten.
 
@ETI1120 Na ja, letztendlich machen die Kisten zu ~95% load, store, branch, add, usw.
 
Zurück
Oben