News Übernahmegerüchte: Intel will SiFive und RISC-V für über 2 Milliarden US-Dollar

[lanse]

Das wäre sehr schade und würde RSICV hart treffen, da hier gerade von dieser Firma hier gerade viel kommt für Entwickler etc.

Und gerade weil von SiFive so viel kommt (die sind in der Tat "das Herz der RISC-V-Entwicklung"), ist es gut, dass Intel hier zugreift. Die brauchen nämlich dringend finanzstarke Investoren bei all dem, was sie tun … nicht nur Arbeit an der RISC-V-Spezifikation und an CPU-Designs, auch am DSA Compiler (MLIR), am Silicon Compiler (CIRCT), …
Hard- und Software zusammendenken: dafür steht SiFive.

"Überflieger" wie Chris Lattner würden eh weiterziehen, wenn Intel die austrocknen wollte.
Das glaube ich aber nicht. Ich glaube eher, dass ein Typ wie Pat Gelsinger, der technisches Verständnis und den entsprechenden Weitblick mitbringt, selbstverständlich erkannt hat, dass Intel den toten Gaul nicht noch ewig reiten können wird.

Aus denselben Gründen denke ich inzwischen auch, dass ARM von der Übernahme durch Nvidia profitieren könnte.

 

[Teralios]

Letztlich ist heute alles Microcode. Ob da x86, arm, power oder r5 nach Microcode übersetzt wird ist herzlich egal. Vermutlich könnte Intel aus dem Stegreif einen Alder Lake aus dem Ärmel schütteln der r5-Code in Microcode ausführt.

Nein, könnten sie nicht. Und ja, auch wenn x86, ARM, Power, RISC-V heute über einen Decoder noch mal zu µOPs zerlegt werden, ist diese Zerlegung im Fall von x86 um ein vielfaches komplexer, während viele Befehle in RISC-Architekturen bereits Atomar sind und damit einem µOP entsprechen und quasi durchlaufen.

Aber es wäre hier nicht nur der Decoder zu beachten, sondern auch das Register-Set in den jeweiligen ISA und darauf aufbauend auch die Anzahl der Register die man in einem Registerfile heute mindestens bereit halten sollte, vor allem wenn man noch Späße wie SMT nutzt. Von den ganzen anderen Sachen wie Re-Orderbuffer usw. wollen wir erst garnicht anfangen, die passend ausgelegt werden sollten.

 

[chartmix]

RISC-V gehört weder SiFive noch künftig Intel. Bei dem Titel bekommt man gleich den Eindruck, Intel will sich damit RISC-V unter den Nagel reißen.

Das ist mir auch sauer aufgestoßen. RISC-V wird von einer Schweizer non-profit Stiftung verwaltet.

 

[Crass Spektakel]

Nein, könnten sie nicht. Und ja, auch wenn x86, ARM, Power, RISC-V heute über einen Decoder noch mal zu µOPs zerlegt werden, ist diese Zerlegung im Fall von x86 um ein vielfaches komplexer, während viele Befehle in RISC-Architekturen bereits Atomar sind und damit einem µOP entsprechen und quasi durchlaufen.

Aber es wäre hier nicht nur der Decoder zu beachten, sondern auch das Register-Set in den jeweiligen ISA und darauf aufbauend auch die Anzahl der Register die man in einem Registerfile heute mindestens bereit halten sollte, vor allem wenn man noch Späße wie SMT nutzt. Von den ganzen anderen Sachen wie Re-Orderbuffer usw. wollen wir erst garnicht anfangen, die passend ausgelegt werden sollten.

Ich erinnere an den IDT C6. Der konnte anwendererstellten Microcode/Translations ausführen. Es gab dafür neben einer x86 auch einen MIPS-Microcode. Davon abgesehen lernt man spätestens im dritten Semester Informatik daß das Übersetzen einer prozeduralen Syntax in eine andere prozeduralen Syntax immer in der Grössenordnung n:n/1:1 liegt.

Auch das "Reorderung" bzw. OoO ist mit Microcode nicht etwa "kompliziert" sondern sehr einfach weil man schlicht mit VLIW arbeitet. Einen Translator für Stage2-C zu AMD29000 - eine recht frühe VLIW Implementierung - mußten wird damals im zweiten Semester erstellen, das war praktisch das gleiche. Zudem, ein "mov ax,bx" ist auf x86 auch nicht komplexer in Microcode umzusetzen als "lb t0,t1" auf r5 und selbst mit komplexen Addressierungsmethoden ändert sich nichts weil sich da beide Architekturen kaum was nehmen. Zumal alle aktuellen CPUs intern bestenfalls einfachste Peephole-Optimierung verwenden. Bleiben noch solche Monsteropcodes wie PCMPxSTRx aber gerade die sind in Microcode lächerlich simpel umsetzbar. Und zeig mir mal eine RISC-Architektur die das gleiche mit einer derart abartigen Performance macht. Und wenn sie es macht dann vermutlich unter Nutzung von einer AVX-Variante mit ähnlich aufgeblähten Opcodes.

Nicht zu vergessen daß x86-Code vergleichsweise kompakt gegenüber RISC-Code ist und damit weniger schnelle Bus-Systeme, weniger Cache benötigt.

Apropo Register: Ryzen 5000 hat ungelogen 160 Register pro Core. Die meisten davon Schattenregister aber interessanterweise macht das aus einer Hochsprache genutzt nichts aus und intern im Microcode lassen sich die Register offenbar sogar direkt nutzen.

 

[mykoma]

Sehr naiv

Sehe ich bei RISC V anders, die Basics sind fix und darauf sollte alles aufbauen.

Weniger schwarzmalen und die Chancen sehen, statt nur Probleme.

 

[Teralios]

Apropo Register: Ryzen 5000 hat ungelogen 160 Register pro Core.

160 Register … niedlich! Du weißt schon, das diese 160 Registereinträge quasi alle für die ALUs + SMT daraufgehen und deine besagten Schattenregister genau diese SMT Register sind, damit man deren Daten nicht ständig aus dem Cache holen kann und man so aus auf den Kontext Switch verzichten kann?

Ehrlich gesagt habe ich jetzt keine Zeit und auch keinen Nerv deinen Beitrag auseinander zunehmen und dir dann teile um die Ohren zu Hauen. Es steht Wochenende an und da will ich mal was besseres mache als wieder Stunden damit zu verbringen alles zu erläutern und warum die 160 Register verpuffen gegenüber den Registerfiles moderner RISC - CPUs und warum Apple zum Beispiel für FireStorme für 6 ALUs auf über 300 kommt und wieso die Anszhal der Register in der ISA für Compiler relevant sind und warum Schattenregister heute notwendig sind - nicht nur SMT sondern vom Pipeline Aufbau wegen OoO sowie spekulative Ausführung.

Egal, wie geschrieben, heute mach ich lieber was einfaches und nur so: Wenn du denkst dein Informatikstudium beeindruckt mich und was du im zweiten Semester gemacht hast: Nö ,hab Hebung technische Informatik, praktische und theoretische Informatikkurse besucht und ebenso Compilerbau sowie Architektur für Informationssysteme auf CPU Basis. Ich muss es aber nicht jedes Mal erwähnen um hier zu zeigen wie toll ich doch bin.

 

[latiose88]

@Teralios

Danke für die Info,darum ist der 5950x so gut bei Ganzzahlen.Aber ich habe gelesen das diese vielen ALUS nur bei sehr komplexen Aufgaben benutzt werden. Ich bin einer der nur die reine Integer Leistung braucht.Habe aber gesehen das diese CPU in wahrheit mehr für Floingpoint also AVX Einheiten verwendet.
Ich benutze keinerlei AVX. Habe aber dennoch ne mehrleistung gegenüber dem 3950x. Das liegt halt daran das die Einheiten sich erhöht hatten. Sonst hätte ich wohl keine mehrleistung gehabt. Bin gespannt ob AMD und auch Intel diese Einheiten noch weiter erhöhen kann um noch mehr Leistung zu haben..Aber das es nicht nur auf diese ganzen Einheiten ankommt sehe ich auch weil ich beim Threadripper 3970x trotz weniger Register noch immer mehr Leistung habe. ALso der hat mehr L1 Cache,mehr Kerne,mehr Transistoren pro Kern und darum auch mehr Leistung. Kommt es also echt nur bei reiner CPU Leistung wirklich nur auf die Anzahl der Kerne und deren Transistoren an. Weil genau diese 3 Punkte unterscheidet sich ein Threadripper 3970x zum Ryzen 9 5950x noch. Es trennt die beiden bei mir rund 11-15 %.


Ich dachte immer Integer Leistung alleine würde bei meiner Anwendung für mehr Leistung sorgen. Scheint wohl doch nicht zu sein. Zählt der L1 Cache,Transistoren Anzwahl samt mehr Kerne also auch zu IPC dazu also sprich ist ein Teil dessen weil es ja per Core heißt. Ein Kern hat ja viele Transistoren,nen Cache,Einheiten zum berechnen. Das ist halt das große ganze. Darum ist halt die Frage ob das alles dazu kommt. Ich habe alles genau mit einander verglichen und darum auch einen 1zu 1 vergleich angestellt weil ich wissen wollte was sich da unterscheidet. Habe alle Caches und alles EInheiten direkt miteinander Verglichen.
Ich habe nur diese 3 Unterschiede entdeckt. Weil ich dachte der Threadripper hat so viel mehr EInheiten ,also müsste er auch automatisch mehr Leistung liefern. Aber das sich die Unterschied nicht so groß sind,das wusste ich ja nicht.

Denke mal nach dem die Unterschiede doch nicht so gravierend sind,müsste man sowas auch mit anderen Achetekturen hinbekommen.Denn nen Threadripper kann man nicht als andere Welt betrachten und ist auch nicht so unterschiedlich wie Tag und Nacht.Ich habe irgendwie mehr Technik dahinter erwartet,bin irgendwie Entäuscht.Habe wohl wunder was erwartet.Weil es sind ja 32 Kerne,also richtig Fette CPU und so. Aber halt nur Optisch.

 

[mae]

[Alder Lake "aus dem Stehgreif" auf RISC-V-Ausfuehrung umbauen]

Nein, könnten sie nicht. Und ja, auch wenn x86, ARM, Power, RISC-V heute über einen Decoder noch mal zu µOPs zerlegt werden, ist diese Zerlegung im Fall von x86 um ein vielfaches komplexer, während viele Befehle in RISC-Architekturen bereits Atomar sind und damit einem µOP entsprechen und quasi durchlaufen.

Das macht es einfacher. Insbesondere ist die RISC-V-Architektur ja besonders feature-arm, da sollte es besonders einfach sein.

Aber es wäre hier nicht nur der Decoder zu beachten, sondern auch das Register-Set in den jeweiligen ISA und darauf aufbauend auch die Anzahl der Register die man in einem Registerfile heute mindestens bereit halten sollte, vor allem wenn man noch Späße wie SMT nutzt. Von den ganzen anderen Sachen wie Re-Orderbuffer usw. wollen wir erst garnicht anfangen, die passend ausgelegt werden sollten.

Ja, dass AMD64 auf der GPR-Seite nur 16 Register hat und RISC-V 32, wird an der einen oder anderen Stelle (wohl vor allem im Renamer, eventuell auch im reorder buffer) Umbauten erfordern, also mit einem neuen Decoder allein ist es wohl nicht getan. Dazu kommt vermutlich noch Hardware, um die Page-Table Entries vom RISC-V-Format auf das prozessorinterne Format umzuaendern. Aber so aus der Ferne schaut das alles nicht so aufwendig aus; nur steckt der Teufel halt bekanntlich im Detail.

 

[Teralios]

Danke für die Info,darum ist der 5950x so gut bei Ganzzahlen.Aber ich habe gelesen das diese vielen ALUS nur bei sehr komplexen Aufgaben benutzt werden. Ich bin einer der nur die reine Integer Leistung braucht.Habe aber gesehen das diese CPU in wahrheit mehr für Floingpoint also AVX Einheiten verwendet.

Du musst da unterscheiden. ALUs sind erst mal nur "Rechenwerke".

Im Integer-Teil hat Zen und auch Intel 4 ALUs, man spricht in dem Fall von 4-facher Skalarität. Es können also 4 Befehle unabhängig voneinander ausgeführt werden. Wenn keine Abhängigkeit der Befehle voneinander gegeben ist, können diese 4 zur gleichen Zeit abgearbeitet werden.

Vereinfacht: add r1, r2; add r3, r4, add r5, r6 und add r7, r8. Diese 4 Befehle haben keine Abhängigkeit voneinander und können bei 4 ALUs zur gleichen Zeit ausgeführt werden, statt in 4 Takten bei nur einer ALU oder in 2 Takten bei nur 2 ALUs.

Anders würde es aussehen, wenn wir jetzt sowas hätten: add r1, r2, add r1, r3, add r2, r4 und add r6, r7. Hier besteht mindestens eine Abhängigkeit: r1 + r2 und r1 + r3, r2 + r4 und r6 + r7 sind - bis auf das r2-Register voneinander unabhängig. Hier braucht man mit 4 ALUs 2 Takte, weil man erst add r1, r2 sowie add r6, r7 ausführt und erst im nächsten Schritt add r1, r3 und add r2, r4. *hier setzte ich gleich an, geh aber ertst mal zur FPU

Bei einer FPU reden wir in der Regel - bei Zen und SandyBridge+ von 2 ALUs, das sind aber Vektor-ALUs die 64 Bit (MMX) bis hin heute zu 512 Bit fassen und verarbeiten. Viele rechnen diese Breite in ALUs um, bei 512 Bit kann man zum Beispiel 16 Werten mit 32 Bit verarbeiten. Nur Vektor-ALUs/SIMD-ALUs haben ein paar andere Probleme bei der Auslastung, nur sind hioer die 16 "ALU"s pro FPU-ALU nicht unabhängig, sondern es wird der gleiche Befehl ausgeführt.

So zurück zum Text und hier auch danke an dich @mae danke dass du ein Teil der Sachen zusammen fasst, richtig aus der Ferne sieht das alles so einfach aus und das Halbwissen, was so mancher mit einem Informatikstudium, wo man diese Themen ja im zweiten Semester angeblich behandelt hat, ist leider auch weit verbreitet und ich bin diesem Halbwissen selbst vor Jahren auch auferlegen, bis ich mich mal intensiver - also über das Studium hinaus mit ISAs beschäftigt habe, die Geschichte hinter der Halbleiterfertigung der 60er, 70er und 80er, welchen Einfluss Compiler haben, wie wichtig alleine die ISA für den Compiler ist, damit er entsprechenden Code erzeugt, was Kontextswitches bedeuten, warum Lade- und Speicher-Operationen eigentlich Gift für die Rechenleistung ist, was OoO bedeutet usw.

Natürlich stell ich das hier oben zum Beispiel stark vereinfacht dar, denn wenn ich da mit einer genauen Erklärung anfange, sitze ich mehrere Tage, muss Diagramme anfertigen und auch Beispielcode, den man dann durch eine fiktive "CPU" in den Diagrammen durchlaufen lässt.

Eine ISA die nur 16 Register hat für den Compiler, führt unweigerlich dazu, dass früher oder später der Compiler unweigerlich Load- und Store-Anweisungen einfügen muss um Ergebnisse Zwischenzuspeichern, denn der Compiler erzeugt den Programmcode und dieser muss sich an der ISA orientieren, NICHT an dem, was die CPU am Ende hat. Und genau hier kommen zwei Knackpunkte zu tragen und auch die besagten Schattenregister - und es hat schon ein andere hier versucht der Person zu erklären - die Schattenregister dienen heute - bei x86-CPUs dazu, dass man (1.) einen zweiten Thread überhaupt verarbeiten kann - ohne diese Schattenregister würden sich die Threads immer in den Weg kommen - und ebenso sind diese Schattenregister vorhanden, damit die Load- und Store-Einheiten Daten jederzeit in diese "Schattenregister" schieben können oder von dort heraus speichern können, ohne dass die ALUs blockiert werden und weitgehend frei sind für den weiteren Programmablauf. Das Register-Renaming wiederum ist mit an Board, damit man sich unnötige Kopieraktionen im "Registerfile" spart.

Damit sich ALUs sowie Load- und Store sowie eben die 2 Threads nicht ins Gehege kommen, kann man vereinfacht sagen, dass man pro ALU einen vollen Satz der ISA-Register ins Registerfile aufnimmt und das eben auch auf die Anzahl der Threads auslegt + ein kleiner Überhang für die Load- und Store-Einheiten: 4 * 2 * 16 = 128, mit den 160 hat Zen3 - oh, seh gerade, dass ich oben nen Fehler habe war es dann SunnyCove, der auf 192 Einträge kommt - hat dieser noch mal 32 Register-Einträge, die diese nutzen können.

Auch die spekulative Ausführung benötigt ein paar Register zusätzlich im Registerfile, damit man die Daten in der CPU hält, solange es möglich ist.

Nur - und deswegen breche ich das an der Stelle auch ab, weil es viel Zeit frisst: Hier werden immer wieder die eigentliche "Kerne" als Architektur mit der ISA verwechselt, dann wird die ISA plötzlich ausgeblendet und deren Auswirkung auf gewisse Eigenheit der Architektur der Hardware.

Und es frist auch Zeit alles immer zu erklären oder dann auch zu widerlegen, wenn mal wieder die üblichen pauschalen Aussagen kommen.

 

[latiose88]

@Teralios Ja danke dir,dennoch frage ich mich wieso das dann sich dann nicht verhält bei meiner Software wie bei manchen ja und auch bei deiner Ausführung.Ich habe nix mit Studium bin also ein totaler Leie was das angeht.Ich kann nur sagen wie sich das Programm bei mir Verhält durch ausprobieren.
Ich betreibe ja ein Primitives Programm wie Videoumwandeln.Das ist gewiss nicht komplex für die CPU.

Das Programm kann ich zwar nennen aber ob das was nützt ist das andere. Es heißt Xmedia Recode. Es verhält sich unter x264 sehr speziell. Ich habe ja geschrieben ich verwende kein einziges AVX Befehlt weil abgeschaltet weil es mir kaum was bringt. Soweit ich weis sind die ganzen SSE Befehle ja ebenso ALUS also Gleitkommaeinheiten. Diese habe ich dort als test ebenso abgeschaltet und es brachte nix.Ich frage mich wofür man sie dann drinnen sind wenn es nix nützt.Dann noch die ganzen MMX1-4 und so die ebenso bei mir keinerlei Wirkung gezeigt haben.Diese MMX sind ja Allzweck Einheiten soweit ich richtig gelesen habe.
BMI1 basiert ja auf Integer wegen zusammenzählen und so.Ich weis also was dieses Tool so macht.Aber ich verstehe nicht es sind doch zwischen Ryzen 9 5950x und Threadripper 3970x doch keine Einheiten mehr,also wie kann es da denn dennoch ne Leistungsunterschied geben echt nicht mehr durch die ganzen EInheiten.
Haben da echt mehr Kerne und Transistoren sowie auch der L1 Cache echt so viel auswirkung?
Ich dachte Transistoren hätte bei solchen Berechnungen keine bzw kaum ein wirkung auf die Leistung oder etwa doch?

 

[Kontrapaganda]

Da aber Apple nun voll auf ARM setzt frage ich mich, ob RISC-V nicht schon verloren hat?

Klar, Apple ist auch der Nabel der Welt. Wenn Apple nicht mitmacht, ist das leider gestorben. Schade aber auch.

 

[LamaMitHut]

Die Entwicklung bleibt spannend, Chiplets, big.LITTLE. CPUs, RISC evtl bei Intel, was kommt wohl als nächstes?

Durch Machine learning entwickelte / optimierte CPUs schätze ich.

 

[latiose88]

Mit Maschine learning wenn z.b mehr Integer Aufgaben benutzt wird,wird dann da drauf mehr fokosierst.Das wäre doch was,das auch andere Einheiten dann mehr das verwenden um die Aufgabe besser zu Optimieren also zu boosten. Dann bräuchte man sich keine Gedanken mehr zu machen was welche Einheit am wichtigsten ist.Jedoch wenn man kaum sondern nur bestimmte Einheiten benutzt wie will dann Maschine learning das dann lernen.Bin gespannt ob es dann noch was nützen würde.

 

[Crass Spektakel]

Du musst da unterscheiden. ALUs sind erst mal nur "Rechenwerke".

Danke daß Du meine Aussagen "prozedurale Übersetzung 1:1/n:n" wiederholst und zustimmst, lediglich um Faktor 20 aufgebläht. Siehe Brevity. Wie hies es in der Schule so schön: Der Rest ist trivial, d.h. der Leser kann ihn selber herleiten.

Dependency-Auflösung für VLIW sind trivial, das sind pro Register bestenfalls eine handvoll boolsche Operationen, so in der Art "wenn r1 in opcode1 und opcode2 gleichzeitig verwendet wird dann wird die Ausführung von opcode2 auf die nächste microop verschoben". Kann man in Verilog vermutlich als Einzeiler hinschreiben.

Schattenregister sind seit Core1 keine reinen ALU-Schattenregister (welche Verschwendung...) mehr wobei mich die genaue Weiterentwicklung erst bei Zen wieder interessiert hat.
Heute fangen sie Stack- und Speicherzugriffe ab und benennen interne Register on-the-fly um so daß ein erneuter Zugriff keine Transferzeit benötigt. Das ist kein Cache, das ist schlicht ein Wert der nie im Register überschrieben wurde da das Register temporär intern unbenannt wurde und das scheint sogar bei komplexen Adressmodi wie Base+Index*Scale verzögerungsfrei zu klappen. Sieht man schön wenn man opcode; push; pull; opcode; macht, die Stack-Ops brauchen bei x86 bis zu einer gewissen Tiefe und ohne Abhängigkeit exakt NULL Taktzyklen oder anders gesagt, ein fliegender Wechsel mit je NULL Taktzyklen ist praktisch das gleiche wie ein echtes Register. In der Praxis macht es einfach keinen Unterschied ob rax oder Shadow-rax#4 in die ALU für eine Operation übernommen wird. Oh Wunder der tiefen Pipeline...

Im übrigen ist amd64 ist eine sehr saubere Architektur die sicher nicht "schlechter" als ARM oder r5 ist. Da ist nach oben nicht viel Platz zur Verbesserung. Häßlich sind nur Sachen wie SSE/AVX aber eben nicht nur auf amd64 sondern auch arm, mips, r5 uswusf...

Altlasten? No Problem, da wird Segmentaddressierung z.B. in einer nach aussen gekapselten Microcode-Übersetzung mit einer Variante von Deplacement+Base+Index*Scale umgeschrieben. Andere Kuriositäten sind ähnlich einfach zu umschreiben. Da wächst der Microcode eben von 1000 auf 1100 kByte. Wen juckt das bei CPUs mit ein paar Milliarden Transistoren?

Der Rest ist trivial, d.h. der Leser kann ihn selber herleiten.

(PS, ich würde sofort einen Mord an einem Kätzchen begehen wenn ich dafür selber den internen Microcode von Ryzen direkt programmieren dürfte. Beim IDT C6 konnte man da schönen Blödsinn anstellen)

 

[latiose88]

Also ich kann mir vorstellen das so viele Transistoren auch irgendwie gefürttert werden wollen.
ALso beispiel ein Threadripper 3970x hat 19,2 Millarden Transistoren und ein Ryzen 9 5950x hat nur 4,19 Millarden Transistoren. Wenn man also nur nach der schiere Zahl gehen würde,würde die CPU mehr als das doppelte davon ziehen. Dem ist aber nicht so. Alleine das es bei mir auch wenn es nicht fair ist,smt beim 3970x abgeschaltet wurde als vergleich nur 14 % sind.Es zeigt also nach dem alleine braucht man nicht zu gehen.Auch wenn es mit dem selben Takt eigentlich fair sein sollte. Und durch das abschalten von SMT haben wohl die übrigen Kerne mehr Transistoren zum Berechnen zur Verfügung oder halbiert sich durch das die Nutzbaren Transistoren auch weil der rest dann brach liegen würde. Das kann man wohl auch bei anderen Archetekturen so machen. Bin gespannt ob da mehr heraus kommen wird. VIelleicht kommt ja noch was bahnbrechendes am ende dabei raus das so einen Ryzen 9 5950x übertrumpft .Denn ich brauche Leistung. Will ja das endlich ein Threadripper 3970x schlagen können ohne diesen Threadripper zu benutzen. Alleine weil diese CPU einfach zu viel aus der Steckdose zieht. Erwarte also durch shinks und so auch mehr Leistung.
Dann wird es Zeit das Intel das übernimmt und auch hier mal richtig auf die Pauke schlägt. Damit hier richtig Power kommen wird,ich bin jedenfall bereit für mehr Power.

 

[lynx007]

Schade um SiFive.

Und mit denen bekommt Intel lediglich eine Firma, die Prozessoren mit RISC-V ISA baut. RISC-V gehört weder SiFive noch künftig Intel. Bei dem Titel bekommt man gleich den Eindruck, Intel will sich damit RISC-V unter den Nagel reißen. Wollen sie vllt, aber auf diesem Weg kriegen sie die Hoheit darüber nicht.

Tja Intel, war damals echt blöd XScale zu verkaufen...

Was hat XScale mit RISC-V ISA zu tun? Bzw. warum würden die jetzt davon Profitieren XScale noch zu besitzen? Sind die Chips so vergleichbar? War XScale in der Branche vergleichbar gut aufgestellt? Warum haben Sie sich davon aber dann getrennt????

Und um so mehr ich mich in die Thematik einlese, umso weniger sehe ich leider einen Zusammenhang.
Laut Wiki war Xscale ja das Armportfolio von Intel. Laut erstenblick hat das wiederum wenig mit dem zu tun mit dem aber SiFive erfolg hat.
Quelle Wiki:

• RISC-V Cores: SiFive Core Series – The SiFive Core Series are customizable using the SiFive Core Designer. SiFive Standard Cores are pre-configured design points in the Core Series.
• SoC IP – The SoC IP solutions[buzzword] are customizable, or customers choose from Memory Interface IP, Connectivity IP, or System and Peripheral IP solutions.[buzzword]
• Custom SoC – Starting with an SoC template, users can design custom SoC solutions[buzzword] to be optimized for power, performance, and area.
• Boards and Software – SiFive also produces the FE310 microcontroller, HiFive1, HiFive Unleashed, and other development boards and software."

https://en.wikipedia.org/wiki/SiFive
https://de.wikipedia.org/wiki/XScale

Aber wen Sie über Insiderwissen verfügen, teilen Sie das gerne mit uns. :-)

 

[ghecko]

Aber wen Sie über Insiderwissen verfügen, teilen Sie das gerne mit uns. :-)

Gerne.

Vorerst muss man sich fragen, was hat Intel mit SiFive vor?
Da gibt es 3 mögliche Szenarien:

1. Fuß fassen im wachsenden IoT-Segment, wo Intel derzeit nichts zu bieten hat. Und von da aus dann mit einer schon etablierten Architektur evtl endlich ins Mobile-Segment vordringen.

2. Eine langfristige Alternative für den x86 Desktop und Servermarkt entwickeln

3. Beides.

Und jetzt zu Xscale.
Xscale war Intels ARM-SOC Sparte, und sie war moderat erfolgreich im damals noch "recht kleinen" Markt (im Vergleich zu heute). Warum Intel die abgestoßen hat ist mir bis heute ein Rätsel, denn kurz danach ist der Smartphonemarkt explodiert und Intel hätte diesen mit der Xscale Produktpalette wunderbar bedienen können, wenn sie aus Xscale das gemacht hätten was potentielle Kunden von ihnen wollten. Einen Smartphone-SOC.
Stattdessen hat Intel später versucht mit x86 wieder in diesen Markt zu kommen dabei Milliarden verplempert., und letztlich sind sie gescheitert.

Hätten sie Xscale behalten, hätten sie (ähnlich wie Apple) jetzt wohl einen großen Anteil des Mobilen SOC-Markts und ihr Produkt hätte von IoT bis HPC skaliert (Wortwitz). Das ARM dazu in der Lage ist, haben wir wohl mittlerweile alle verstanden.
Der Verkauf von Xscale ist wohl eine der desaströseste Managemententscheidungen die Intel je getroffen hat.

Aus jetziger Sicht gibt es für Intel keinen Ausweg mehr, um künftig mitspielen zu können brauchen sie eine Alternative zu x86. Und sie haben sich scheinbar für RISC-V entschieden, dank Nvidia.

 

[lynx007]

Xscale war Intels ARM-SOC Sparte, und sie war moderat erfolgreich im damals noch "recht kleinen" Markt (im Vergleich zu heute). Warum Intel die abgestoßen hat ist mir bis heute ein Rätsel, denn kurz danach ist der Smartphonemarkt explodiert und Intel hätte diesen mit der Xscale Produktpalette wunderbar bedienen können, wenn sie aus Xscale das gemacht hätten was potentielle Kunden von ihnen wollten. Einen Smartphone-SOC.
Stattdessen hat Intel später versucht mit x86 wieder in diesen Markt zu kommen dabei Milliarden verplempert., und letztlich sind sie gescheitert.

Hätten sie Xscale behalten, hätten sie (ähnlich wie Apple) jetzt wohl einen großen Anteil des Mobilen SOC-Markts und ihr Produkt hätte von IoT bis HPC skaliert (Wortwitz). Das ARM dazu in der Lage ist, haben wir wohl mittlerweile alle verstanden.
Der Verkauf von Xscale ist wohl eine der desaströseste Managemententscheidungen die Intel je getroffen hat.

Aus jetziger Sicht gibt es für Intel keinen Ausweg mehr, um künftig mitspielen zu können brauchen sie eine Alternative zu x86. Und sie haben sich scheinbar für RISC-V entschieden, dank Nvidia.

Ok, das ist Pech. Ja gut, aber das sie erfolgreicher mit der Arm Technologie gewesen wären, ist auch äußert spekulativ. Sie sagen ja selbst das Sie dort auf dem ARM Markt nur Moderat erfolgreich waren.

Es hätte auf jeden Fall Marktpotenzial bestanden, da stimme ich Ihnen zu, aber das führt nicht automatisch zu Erfolg. Natürlich kann man jetzt sagen "hätten" Sie ihre ARM Technologie behalten und die 3 Milliarden dann... Die haben sicher nicht freiwillig 3 Millarden in eine bestehende und anderswo äußert erfolgreiche Technologie in den Sand gesetzt. Dass man mit den 3 Millarden dann eine ähnliche Technologie dafür nur moderat erfolgreich so starkgemacht hätte.... Was verschlingt den so eine Chip entwicklung. Was steckt Qualcom jährlich in seine Entwicklung? Muss mir mal von dem Unternehmen die Bilanzen anschauen. Leicht hätte es Intel sicher trotzdem nicht gehabt.

Dazu, xcale wurde ja schon 2006 an Marvel verkauft.... 2 Jahre vor dem Release vom Iphone.... Da muss man schon fair sein.
https://de.wikipedia.org/wiki/XScale
Das Iphone so ein Erfolg wird, sprich PDAs Massentauglich macht, das war zu diesem Punkt ja noch gar nicht vorhersehbar. Rückwirkend kann man immer sagen, "hätte, hätte Fahradkette".... Rückwirkend werden sie mir zustimmen, kennt aber jeder aber auch die richtigen Lotozahlen.
Aber Marvel ist jetzt auch nicht so der große Player geworden.... Zumindest nicht Mobilbereich, oder? Haben die überhaupt mal für Smartphone CPUs gebaut? Findet man heute denn noch die xcale technologie? War die bzw. ist die irgendwo noch führend und nicht quasi nicht ersetzbar?

 

[chartmix]

Durch Machine learning entwickelte / optimierte CPUs schätze ich.

https://www.theverge.com/2021/6/10/22527476/google-machine-learning-chip-design-tpu-floorplanning

 

[LamaMitHut]

https://www.theverge.com/2021/6/10/22527476/google-machine-learning-chip-design-tpu-floorplanning

Darum bin ich auch darauf gekommen. Ich schätze, da steckt noch einiges in den Babysöckchen.