News Für Server und Surface: Auch Microsoft entwickelt eigene CPUs auf ARM-Basis

@ghecko
Dafür frisst Design-Entwicklung viel Geld. Solange man also nicht gerade Abermillionen an Chips rauspumpt, hohlt man die Investition mit den Einsparungen an Lizenzgebühr / Chip nicht rein.

Dagegen kann man massiv viel Geld verdienen, wenn man als quasi-marktdominanter Player schöne lock-ins erzeugt und am Ende nur bei einem selbst, und dem einen Konkurrenten, den man gegne Monopol-Verfahren hat, gekauft werden kann.

Ich sehe RISC-V viel im Bereich kleiner Chips, USB-Controller oder sonstwas, wo es auch heute schon viele gibt, die ihre eigenen Designs machen. Da ist das auch nicht so teuer.

Aber mal eben eine High-Performance CPU designen? Und dann noch das Geld auftreiben, um ausreichend Software zur Portierung zu bewegen / Beiträge zu OpenSource Projekten zu finanzieren? Mit der Aussicht, dass ein Konkurrent einem den Erfolg direkt unter der Nase wegschnappen kann, weil alles kompatbiel ist?
Ich sehe das nicht. Das sind viel zu große Investments, bei einem zu großen Risiko, dass man selbst im Erfolgsfall das Geld nicht wieder reinholt.

Ich irre mich aber gerne. Wäre eine bessere Welt.
 
  • Gefällt mir
Reaktionen: chartmix und Cruentatus
Salutos schrieb:
Übrigens Apple sehe ich viel näher an einem vollständigen Wechsel zu ARM Prozessoren. Das liegt daran, dass Apple sich im Vergleich zu Microsoft schon viel länger mit ARM-CPUs (iPhones/iPads) und deren Optimierung beschäftigt. Zur Erinnerung, woran ist Microsofts mobile Sparte gescheitert? Richtig, an der zu starken Abhängigkeit von x86 und dem Unwillen sich mit ARM zu beschäftigen.
So wie ich das sehe, hast du gleich zwei falsche Fakten genannt;

1. Microsoft hatte bereits vor dem ersten iPhone Geräte und Software unter ARM laufen. Dementsprechend wüsste ich nicht das Apple sich "schon viel länger mit ARM-CPUs" beschäftigt.

2. Microsoft mobile Sparte lief auch unter ARM, darunter z.B. Windows CE, Windows Phone 7, 8, was dann widerlegen müsste das Microsoft unwillig war sich mit ARM zu beschäftigen.
 
  • Gefällt mir
Reaktionen: Col. Jessep und 7H0M45
Autokiller677 schrieb:
Aber mal eben eine High-Performance CPU designen?
Sehe ich als sinnvoller an, als diese von Nvidia zu kaufen. Aber vllt sehe ich das auch eher aus dem Entwicklerstandpunkt, Manager aus den Wirtschaftsakademien sind ja auf schnelle Cashgrab-Entscheidungen dressiert statt auf langfristige Rentabilität.

Um Opensource muss man sich weniger Gedanken machen. Linux läuft bereits auf RISC-V (wer hätts gedacht?), die Compiler sind fit für RISC-V und ARM ist auf dem Desktop und dessen Softwarelandschaft aktuell alles andere als etabliert.
Wenn sich AMD und Intel auf eine Architektur einigen, ist die Richtung klar und alle können sich darauf einrichten, ob das nun ARM ist, RISC-V oder es x86 bis zum bitteren Ende bleibt.
 
konkretor schrieb:
Wer mehr über Risc V lesen möchte sollte hier mal vorbei schauen

Wir leben halt aktuell in einer 20 Jahre alten x86 Blase.
Früher war x86 eine Architektur von vielen, seit Anfang 2000 ist x86 ganz klar der Marktführer

Was für Vorteile hat Risc V oder Arm gegenüber x86?
x86 ist halt sehr gut kompatibel zu alten Programmen. Hat dadurch aber Performance Probleme?
 
  • Gefällt mir
Reaktionen: Gerry18
brabe schrieb:
Was für Vorteile hat Risc V oder Arm gegenüber x86?
ARM und RISC-V sind frei von dem Problem, das Intel, AMD und andere x86 Lizenzinhaber schon in den 90ern erkannt haben und bis heute an der Korrektur arbeiten. Nämlich das CISC eine Sackgasse ist.
Wir schleifen einen antiken Befehlssatz herum, der aufwändig in micro-ops decodiert werden muss damit er auf modernen Prozessoren effizient ausgeführt werden kann. Wir sprechen quasi mit einer Hochsprache zu unseren Prozessoren und die müssen erst mal übersetzen und interpretieren, was wir denn überhaupt von ihnen wollen.

x86 ist ein Befehlssatz für CISC-Prozessoren. CISC bedeutet an sich, jedes abstrakte Problem bekommt seinen eigenen Befehl. Und je mehr Befehle ein Prozessor versteht, desto komplexere Aufgaben kann er lösen.
Zur Ausführung eines einzelnen Befehls werden dann je nach Komplexität eben mehrere Zyklen benötigt, die Durchlaufzeit durch den Prozessor bis zum Ergebnis kann also recht lange dauern und es ist schwer, die Ausführung von Befehlen zu parallelisieren.

RISC-Prozessoren verstehen hingegen nur einfache Befehle. Die können jedoch schnell, vorhersehbar und gut parallelisierbar ausgeführt werden. Dafür sind diese Speicherintensiver. Alle komplexen Operationen lassen sich grundsätzlich in einfacher Einzeloperationen zerlegen, das erfordert aber mehr Aufwand bei der Organisation und Speicherung der Zwischenergebnisse. Und dieser Aufwand muss hauptsächlich vom Compiler bewältigt werden. Einen guten Compiler für RISC zu schreiben (oder gar Assemblercode) ist also nicht ohne.

Anfangs waren CISC-Designs sehr beliebt, weil sie zu Zeiten der hardwarenahen Programmierung einfacher zu programmieren waren. Nachdem sich aber die Hochsprachen etabliert haben, Cache und RAM immer günstiger und die Compiler immer besser wurden, war dieser Vorteil weg und die RISC-Maschinen skalierten gegenüber CISC-Designs in der Leistung schlicht besser. Das Ergebnis war schließlich, das so ab 1990 alle mit einer x86 Lizenz CISC aufgegeben haben und stattdessen RISC-inspirierte Prozessoren mit einem Decoder für x86-Instructionen entwickelt haben. Alle heute gebräuchlichen Desktoparchitekturen stammen von diesen Prozessoren ab, sind also im Kern RISC-Prozessoren ähnlicher als der originalen CISC-Idee.
Intel: https://de.wikipedia.org/wiki/Intel_Pentium_Pro
NexGen (AMD): https://de.wikipedia.org/wiki/NexGen
AMD: https://de.wikipedia.org/wiki/AMD_K5


  • RISC-V ist nur ein (sehr moderner) RISC-Befehlssatz, den jeder frei für eigene RISC-Designs nutzen und ausbauen kann.
  • ARM ist ein RISC-Befehlssatz inklusive Designvorlagen, die in Lizenz genutzt und erweitert werden können.

An sich sind beide vielversprechende Vorlagen, RISC-V ist der modernere Befehlssatz und ARM hat den Mobile und Embedded-Markt bereits durchdrungen.
ARM hat halt die unschöne Eigenschaft jetzt zu Nvidia zu gehören. Und Nvidia ist ein komplizierter Geschäftspartner.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: cele, cM0, petepow und 16 andere
cbtestarossa schrieb:
Im HighEnd Bereich, wo es auf Leistung ankommt wird uns x86 sicher noch ne Weile begleiten.
Die sind schon auf der Höhe der Zeit. Nicht mit den ARM Designs von Telefonen verwechseln.
 
Fritzibox schrieb:
X86 muss absterben. Niemand braucht mehr sowas
Wieso beschäftigst du dich denn dann damit? Und danke das für mich falsche Aussagen triffst. Nicht immer von sich auf andere schließen. ;)
x86 wird dann abgelöst wenn etwas besseres da ist und das Alte obsolet wird. Das scheint bisher nicht gewesen zu sein.
In der Vergangenheit von einem C64 zu einem Amiga 1200c gewechselt, und danach zum PC. Wenn etwas neues sich durchsetzt und ein Wechsel Sinn macht, werde auch ich wechseln. Bis dahin kann die x86 Plattform gerne noch ein paar Iterationschleifen drehen.
 
Dass X86 sein Ende finden wird, war seit RISC-V klar, aber wann die Schwergewichte wie AMD, Intel, MS und Co. die Reißleine ziehen, steht noch in den Sternen. Apple hat aufgrund ihrer besonderen Rolle als Software- und Hardwareentwickler(Designer), die Sie kontinuerlich ausgebaut haben (Arm-CPU, GPU usw.) diesen Schritt früher gewagt als andere.
Wann Intel und AMD auf dem privaten Feld da mitziehen, wäre aus unserer Sicht viel interessanter.

Hier zum Nachlesen, der ARM-Serverchip-Test von Anandtech:

https://www.anandtech.com/show/16315/the-ampere-altra-review
 
Zuletzt bearbeitet:
Bei Servern kann ich mir eine Umstellung recht gut in recht kurzer Zeit vorstellen, bei Clients im privatem Umfeld wird es aber eher keiner von uns erleben da Henne<>Ei Problem und eine Emu nie die native Leistung erreichen wird... Alles online auf einem Server zu erledigen ist für Privat auch nur eine teure Krücke.

Wenn aber alle grossen Anbieter eigene CPUs entwickeln, dann wird auch Intel und AMD erstmal Probleme bekommen.
 
ghecko schrieb:
RISC-Prozessoren verstehen hingegen nur einfache Befehle. Die können jedoch schnell, vorhersehbar und gut parallelisierbar ausgeführt werden. Dafür sind diese Speicherintensiver. Alle komplexen Operationen lassen sich grundsätzlich in einfacher Einzeloperationen zerlegen, das erfordert aber mehr Aufwand bei der Organisation und Speicherung der Zwischenergebnisse. Und dieser Aufwand muss hauptsächlich vom Compiler bewältigt werden. Einen guten Compiler für RISC zu schreiben (oder gar Assemblercode) ist also nicht ohne.

Sehr schön erklärt.
Ein Beispiel:
CISC`s können x² rechnen und RISC müssen x*x rechnen? Wenn ich also x² haben will, dann muss der Compiler wissen, dass x² = x*x ist. Also kann ein CISC Rechner komplexe Rechnungen schneller ausführen. Wenn er aber nur 16 Threads hat, dann kann er es nur 16 mal gleichzeitig machen. Wenn dagegen ein RISC Prozessor auf derselben DIE Größe 512 Threads hat, dann könnte er 32 mal das Problem lösen ( ich nehme mal an, dass man mehrere Threads, hier zum Beispiel 16, braucht um x² zu lösen). Sehe ich das richtig? Der RISC kann also seine Aufgaben besser aufteilen, da er mehrere kleinere Rechnungen durchführen kann.

Im CISC ist die Berechnung im Design und im RISC im Code.
 
ghecko schrieb:
ARM und RISC-V sind frei von dem Problem, das Intel und AMD schon in den 90ern erkannt haben und bis heute an der Korrektur arbeiten. Nämlich das CISC eine Sackgasse ist.
Wir schleifen also aktuell einen antiken Befehlssatz herum, der in aktuellen Prozessoren aufwändig in micro-ops decodiert werden muss damit er auf Prozessoren effizient ausgeführt werden kann.
Wie hartnäckig sich diese Aussagen halten. X86 ist zwar CISC und ARM RISC aber reale Implementierungen kompensieren die jeweiligen Nachteile jeweils indem sie von der "reinen Lehre" abweichen. Was dazu führt, dass ARM CPUs die ARM ISA genauso in µOps umsetzen. Genauso wie ARM µOp fusion betreibt und sich damit eher etwas an CISC annähernd. Während x86 Rechenwerke sich eher an RISC annähern.


RISC-V ist nur ein (sehr moderner) RISC-Befehlssatz, den jeder frei für eigene RISC-Designs nutzen und ausbauen kann.

Naja "modern", die in der Spezifikation festgesetzten (ratifizierten) Featurelevel sind die Grundlagen und konzeptionell über Jahrzehnte bekannt. So einige Dinge, die man heute in modernen ISAs und Implementierungen will sind noch in der Diskussion (Hypervisor, SIMD, Bit Manipulation, Crypto). Zudem RISC-V an einigen Stellen anzumerken ist, dass es als simples Lehrbeispiel ausgelegt ist. Es gibt da durchaus Kritik/Diskussionen darum, dass RISC-V da etwas zu sehr an der Lehrbuchdefinition klebt und damit Implementierungen in Details langsamer und/oder komplizierter werden.
Und das "jeder kann Ausbauen" ist eigentlich die Hölle. Proprietäre Erweiterungen können zu einer immensen Fragmentation führen. Die Stärke von X86 und ARM ist ja gerade, dass es solche Insellösungen fast nicht gibt.

#########################################################
Ob sich auf breiter Ebene x86 abgelößt wird kommt vor allem darauf an, ob entsprechende Geräte auf breiter Front verfügbar werden und es Software dafür gibt. Ich befürchte dabei, dass sich viele Anbieter Apple als Beispiel nehmen werden. Verlötete und verdongelte Plattformen sowie Dokumentation, Compiler und Standardbibliotheken nur vom Anbieter unter restriktiven Lizenzen...
 
  • Gefällt mir
Reaktionen: cele, JohnVescoya, ComputerJunge und 4 andere
Das macht einigen Sinn ((für MS), v.a. wenn's hier zunächst Mal um Servers geht. Azure läuft doch zumindest hier und da auf existierenden ARM Server Chips (Marvell Thunder), d.h. Erfahrung damit haben sie, und da Azure auf Linux läuft, muss MS sich nicht zuviel Kopfschmerzen mit OS und Software machen wenn sie im Großmasstab auf ARM Marke Eigenbau umrüsten würden.
Für PC/Ultraportables ist es problematischer, hier muß MS mit den Milliarden von x86 Legacy Usern wie mir umgehen, und der Spagat ist schon schwer genug für Apple, die das aber einfach durchdrücken können (willst Du Mac, kaufst Du Apple, sonst gibt's nichts). Langfristig aber ist dies jetzt vielleicht doch die Zeit, in der das Ende von x86/x64 eingeläutet wurde, zumindest auf Servern und Hochleistungscomputern.
 
Edit: NEU Richtigstellung
Shifts funktionieren für Multiplikation oder Division mit 2 (z*2). Für beliebige x^2 würden Compiler versuchen x als Vielfaches von 2 darzustellen um dann fröhlich shifts anzuwenden. Für x=6 (binär: 110) sähe das so aus
Code:
x=6
x^2=(1*x*2^2) + (1*x*2^1) + (0*x*2^0)
=36
Was bedeutet, dass die CPU einmal um 2 Stellen links schiebt (left shift), einmal um 1 Stelle. Die Ergebnisse dieser beiden "Schiebungen" müssen dann noch addiert werden.

Ich hatte mich da ursprünglich etwas vertan. Es folgt der alte, ungeänderte Beitrag, der taugt noch immer um RISC/CISC Unterschiede aufzuzeigen. Ist Aber Falsch was die genaue Representation vom Einsatz von Shifts angeht.

ALT:

brabe schrieb:
Sehr schön erklärt.
Ein Beispiel:
CISC`s können x² rechnen und RISC müssen x*x rechnen? [...] Der RISC kann also seine Aufgaben besser aufteilen, da er mehrere kleinere Rechnungen durchführen kann.

Im CISC ist die Berechnung im Design und im RISC im Code.
x*x oder x² bei zum Zeit des Kompilierens ein unbekannten Integer x würde jeder brauchbarer Compiler als Shiftoperation übersetzen (solang die CPU das bietet). Egal ob CISC oder RISC.

Was unterschiedlich ist, ist dass RISC zum Laden des Wertes X erst den Speicher aus einer Addresse in ein Register lesen muss, während CISC direkt angibt shift left auf Adresse:

Code:
Pseudo Assembler (zu faul um nach exakten Befehlen zu schauen)
RISC
load $src_addr, &reg //Hole Wert aus Speicher Adresse, Schreibe in Register
shl $reg                      //left Shift auf Register
store $reg, $dest_addr //Schreibe Wert aus Register in Speicheradresse
//RISC könnte auch ein shl als shl $src_reg, $dest_reg implementieren, wie gesagt zu faul zum nachschlagen


CISC
shl &dest_addr, &src_addr  //Left Shift auf Wert in source Adresse, Schreibe Ergebnis in destination Adr.
// Wäre auch denkbar, dass es nur "shl &addr" lautet.

Und mit der Anzahl an Threads hat das auch nichts zu tun.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: JohnVescoya, foo_1337, kaji-kun und eine weitere Person
brabe schrieb:
Also kann ein CISC Rechner komplexe Rechnungen schneller ausführen
Nicht zwangsläufig. Wie gesagt, je komplexer der Befehl, desto mehr Zyklen benötigt dessen Abarbeitung.
Der Vorteil von CISC ist, dass der Prozessoren diese überhaupt erst versteht.
brabe schrieb:
CISC`s können x² rechnen und RISC müssen x*x
eher 4+4+4+4 wenn x=4 ist, um es "banal" auszudrücken. Das soll auch nur veranschaulichen, wie man eine "höhere" Mathematik in einfachere Operationen runter brechen kann.
brabe schrieb:
Wenn er aber nur 16 Threads hat, dann kann er es nur 16 mal gleichzeitig machen.
Kein Grund das gleich auf mehrere Kerne zu verteilen, schon die Ausführung solcher Befehle innerhalb eines Kerns ist parallelisiert. Pipelining, Out of Order und Speculative Execution sind ja prinzipiell nichts anderes als Ansätze die die Auslastung der Einzelkomponenten eines Prozessorkerns verbessern, indem die auszuführende Reihenfolge der Befehle für parallelisierung optimiert, die Ausführung in verschiedene Ebenen zerlegt die gleichzeitig abgearbeitet werden und diese teilweise noch auf "Verdacht" ausgeführt werden.
Piktogramm schrieb:
Wie hartnäckig sich diese Aussagen halten.
Nun, irgendwas scheint dran zu sein, sonst würde die Industrie nicht diesen Diskurs um eine Zukunft nach x86 führen.
 
Zuletzt bearbeitet:
the_pi_man schrieb:
Die sind schon auf der Höhe der Zeit. Nicht mit den ARM Designs von Telefonen verwechseln.
(Leider?) Auch nicht mehr: der Fujitsu Fugaku (Mt. Fuji) ist 100% ARM, und der zur Zeit leistungsstärkste Supercomputer (Stand 12/2020). Der A64FX Chip der hierfür entwickelt wurde hat auch 512 Bit weite Extensions (SVE), also zumindest in der Weite ähnlich wie AVX512.
 
ghecko schrieb:
eher 4+4+4+4 wenn x=4 ist, um es banal auszudrücken.
Nur wenn die ISA keine Multiplikation und keine Shifts zulässt.

Edit: RISC-V Dokumentation überflogen. Shifts sind in RISC-V I (also der grundlegenden, minimalen Implementierung von RISC-V) bereits enhalten. Selbst die 8bit billig AVR µController (bekannt aus Arduino Uno u. Ähnliche) können das. Also kommt dein Beispiel (hoffentlich) niemals vor.
Nun, irgendwas scheint dran zu sein, sonst würde die Industrie nicht diesen Diskurs um eine Zukunft nach x86 führen.
Wenn das Viele ohne all zu tiefes Verständnis immer wieder wiederholen, dann wird es zur Wahrheit innerhalb der Echokammer. Prinzipiell hat x86 keine Essentiellen Nachteile/Vorteile genauso wenig wie ARM, RISC-V, MIPS etc. pp. Wie gesagt, reale RISC und CISC Implementierungen borgen sich Ideen der anderen Konzepte um die Vorteile/Nachteile des grundlegenden eigenen Konzepts verschwimmen.

Wenn die großen Firmen auf ARM schielen, dann hat das in erster Linie mit Geld zu tun. Die Gewinne von AMD und Intel finanzieren die Kunden. Die großen Betreiber von Rechenzentren kommen da langsam in Bereiche, wo selber bauen günstiger wird als Einkaufen. Naja und Intel hat es sich über Jahre ohne ernsthate Konkurrenz zu bequem gemacht. Da ist mittlerweile viel Luft.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: JohnVescoya, foo_1337, emulbetsup und 3 andere
Eorzorian schrieb:
Dass X86 sein Ende finden wird, war seit RISC-V klar, aber wann die Schwergewichte wie AMD, Intel, MS und Co. die Reißleine ziehen, steht noch in den Sternen. Apple hat aufgrund ihrer besonderen Rolle mit Software- und Hardwareentwickler(Designer), die Sie kontinuerlich ausgebaut haben (Arm-CPU, GPU usw.) diesen Schritt früher gewagt als andere.
Wann Intel und AMD auf dem privaten Feld da mitziehen, wäre aus unserer Sicht viel interessanter.

Hier zum Nachlesen, der ARM-Serverchip-Test von Anandtech:

https://www.anandtech.com/show/16315/the-ampere-altra-review
Das Ding ist schon Hammer, aber die TDP ist nicht viel anders als bei X86. Fuer alles ist der auch nicht geeignet.
Wenn X86 alte Funktionen ueber Board werfen wuerde, saehe es besser aus. Software die 20 Jahre und aelter ist soll ja auch noch auf dem PC laufen. Interessant finde ich die Angaben zum Preis fuer dieses 80 Core Monster.
 
Blöde Frage an die Profis, könnte man nicht bei den x86 Prozessoren prinzipiell alten Ballast wegwerfen und darauf scheißen ob eine 30 Jahre alte Software drauf läuft oder nicht, um das ganze effizienter zu gestalten?

Andersherum, ist ARM noch wesentlich effizienter wenn es den komplett gleichen Funktionsumfang wie x86 bietet, vor allem auch im Hinblick auf Abwärtskompatibilität?
 
Zurück
Oben