News Foundry IDM 2.0: Intel setzt auf RISC-V und neues Foundry-Ökosystem

[Volker]

Intel setzt in Zukunft noch stärker auf RISC-V und etabliert ein Foundry-Ökosystem, welches mit einer Milliarde US-Dollar gefördert wird. Vor allem die stärkere Zusammenarbeit mit RISC-V wird als cleverer Schachzug seitens Intel gesehen, mit dem sich der Hersteller in vielen Bereichen zukünftig auch gegen ARM aufstellen könnte.

Zur News: Foundry IDM 2.0: Intel setzt auf RISC-V und neues Foundry-Ökosystem

 

[ghecko]

War ja zu erwarten. Hoffe AMD steigt auch noch mit auf, damit RISC-V fahrt aufnimmt und vllt irgendwann gesockelte Chips der Desktop-Klasse verfügbar sind.

Aber hoffentlich bleibt es nicht bei den beiden. Ich möchte künftig keine Prozessoren mehr von AMD oder Intel. Und Apple.

 

[whynot?]

Sehr kluger move von Intel

 

[Un1kum]

War ja zu erwarten. Hoffe AMD steigt auch noch mit auf, damit RISC-V fahrt aufnimmt und vllt irgendwann gesockelte Chips der Desktop-Klasse verfügbar sind.

Aber hoffentlich bleibt es nicht bei den beiden. Ich möchte künftig keine Prozessoren mehr von AMD oder Intel. Und Apple.

Ob das dabei rausspringt? Ich tippe ja darauf das wenn das Ökosystem da ist man gerne auch Chip-Lösungen und nicht nur Foundry Service anbieten würde.

Gesockelte Chips hieße, es gäbe einen Standard. Das wäre im mobile und embedded Bereich eher ein Novuum. Nicht das es sowas gar nicht gäbe, es ist eher Wildwuchs. Sowas wie ACPI dort wär mal was.

 

[flaphoschi]

Komm schon AMD. Ihr müsst euch da jetzt aufstellen, Notfalls auf Risiko.
Hinterherhecheln ist Mist, dass musstet Ihr schon viele Jahre und auf Augenhöhe duellieren macht mehr Freude (so wie jetzt)

Vielleicht könnt da mit Xilinx Kompetzen der Einstieg leichter sein?

Nichts gegen X86_64, AMD hat damit wirklich viel bewirkt. Aber eine offene Architektor - mit guter Lenkung - wäre strategisch für viele von uns gut. Womöglich auch wirtschaftlich, für den Standort Europa. Wenn wir mit Geschick einen offenen Standard führt, kann das langfristig erfolgreich sein (Vulkan, OpenGL mit Einschränkung, WiFi, Bluetooth...).

Anmerkung:
SiFive ist nicht der größter Hersteller von RISV-V, aber der bekannteste mit Fokus darauf. Und SiFive gehört praktisch schon zu Intel.

 

[DFFVB]

Ist RISC V heute das was ARM vor 15 Jahren war?

 

[NikoNet]

Durch die Übernahme von Xilinx solte AMD auch RISC-V an Bo(a)rd haben.

 

[flaphoschi]

Ist RISC V heute das was ARM vor 15 Jahren war?

Womöglich. Und da muss man langen Atem haben.

Minus die Lizenzen und Patente. Und auf Basis einer klareren Architektur. Sollte halt nur nicht ein Haufen loser Extensions werden wie bei Intel X86. SGX, AVX, MPX, SSE {1, 2 , 3, 4, 5}, AES und so weiter. Dann wirft Intel wieder was raus wie SGX kürzlich oder gibt es heimlich auf wie MPX oder versucht immer eins mehr zu haben als AMD (irgend ein SSE+1).

Ergänzung (8. Februar 2022)

Durch die Übernahme von Xilinx solte AMD auch RISC-V an Bo(a)rd haben.

Quelle? Ich will möchte gerne mehr Wissen. Von Xilinx weiß ich nur, dass deren große stärke FPGA ist.

 

[NguyenV3]

Durch die Übernahme von Xilinx solte AMD auch RISC-V an Bo(a)rd haben.

Quelle? Ich will möchte gerne mehr Wissen. Von Xilinx weiß ich nur, dass deren große stärke FPGA ist.

Hier ist eine Liste der Boardmember. Intel ist schon da eingepflegt. Von Xilinx sehe ich nichts.

 

[NikoNet]

Suche ergibt einige Treffer zu Xilinx und RISC-V

https://riscv.org/member/xilinx/

 

[calluna]

Sollte halt nur nicht ein Haufen loser Extensions werden wie bei Intel

Der Grund für diese Extensions ist der Spagat zwischen einer (in dieser Branche nicht alltäglichen) Abwärtskompatibilität und einer notwendigen technischen Weiterentwicklung. Jede Iteration von SSE hat Sinn ergeben und war bestimmten Problemen gewidmet... dasselbe gilt für AVX.

Intel z.B. hat ja schon vor 20 Jahren versucht x86 loszuwerden - auch wenn x86 mit dem Pentium Pro bereits zu einer Art Interface degradiert wurde, denn seitdem bezeichnet es keine Architektur mehr, die von einem der Nachfolger implementiert wurde.

Und wie Apple gezeigt hat, ist so ein Wechsel heute besser möglich, wenn es clevere Lösungen für die alten Binaries gibt.

 

[NguyenV3]

Suche ergibt einige Treffer zu Xilinx und RISC-V

https://riscv.org/member/xilinx/

Ja als "Strategic Member" wird Xilinx aufgeführt:
https://riscv.org/members/

Über diesen Strategic Members gibt es noch die Premier Member. Ich nehme an, dass sind die, die auch direkt einen Sitz an der Spitze erhalten. Hier ist eine Auflistung, was die unterschiedlichen Mitgliedschaften bringen und was die kosten:
https://riscv.org/membership/

 

[end0fseven]

Kann mir jemand in einfachen Worten erklären was RISC-V im Vergleich zu ARM bringt? Ich dachte das sich jetzt langsam ARM durchsetzen wird?

 

[eastcoast_pete]

Kann mir jemand in einfachen Worten erklären was RISC-V im Vergleich zu ARM bringt? Ich dachte das sich jetzt langsam ARM durchsetzen wird?

RISC-V ist eine quelloffene Architektur; ARM ist zwar sehr erfolgreich, aber eben auch "geschlossen", d.h. ohne Lizenzgebühren und -abkommen geht gar nichts. Wahrscheinlich ist RISC-V die zur Zeit größte Bedrohung für ARMs Dominanz im Markt v.a. für kleinere SoCs.

Ergänzung (8. Februar 2022)

Ich denke auch, daß die 1 Milliarde Dollar so etwas wie eine Versicherung sind. Intel baut im Moment ihre Foundry Kapazität massiv aus; da lohnt es sich, schon jetzt dafür zu sorgen, daß die zig Milliarden teuren fabs in 3-5 Jahren nicht "Däumchen drehen". Außerdem baut Intel so Know-how auf, das sie in Zukunft selbst sehr gut gebrauchen könnten.

 

[ModellbahnerTT]

Wahrscheinlich ist RISC-V die zur Zeit größte Bedrohung für ARMs Dominanz im Markt v.a. für kleinere SoCs.

Nicht nur für ARM wird es eng wenn RISC-V groß raus kommt auch der x86_64 bekommt Probleme. Einziges Problem welches RISC-V treffen könnte ist ein fehlendes Coreboot oder UEFI.

 

[DevPandi]

Hier ist eine Liste der Boardmember. Intel ist schon da eingepflegt. Von Xilinx sehe ich nichts.

Na ja, du hast da jetzt das "Board of Directors" verlinkt, das ist zwar schön und gut, dass da z.B. nun Intel drin ist, nur ist das Board da eher für die grobe Richtung von RISC-V wichtig und hat repräsentative Aufgaben.

Interessanter sind da eher die Entwickler-Boards sowie die strategischen Boards, die die Hauptarbeit machen, es reicht also für Firmen, wenn sie sich als Strategic Member einschreiben: https://riscv.org/members/

Kann mir jemand in einfachen Worten erklären was RISC-V im Vergleich zu ARM bringt? Ich dachte das sich jetzt langsam ARM durchsetzen wird?

Der große Vorteil von RISC-V ist, dass es eine OpenSource ISA (Instruction Set Architecture) ist. Jeder kann die RISC-V ISA nutzen um eine eigene CPU-Architektur damit zu entwickeln und anzubieten.

Bei ARM ist das ganze anders. Es gibt bei ARM zwei Modelle - stark vereinfacht - einmal kannst du bestimmte ARM-CPU-Kerne lizenzieren, dann darfst du genau nur diesen lizensierten CPU-Kern verwenden. Das zweite Modell sieht vor, dass du die ISA lizensierst, diese ermöglicht es dir dann, dass du eigene Kerne mit der ARM-ISA entwerfen darfst und verkaufen darfst.

Wichtig ist dabei aber immer: Egal ob du jetzt die Kerne oder die ISA lizensierst du darfst das, was du da machst nicht weiter lizensieren.

Sprich, lizensierst du die ISA, dann darfst du CPU-Kerne entwerfen und verkaufen, aber nicht weiter lizensiere.

Lizensierst du einen CPU-Kern, darfst du ein Produkt darauf aufbauen und verkaufen, aber nicht das Produkt weiter lizensieren.

RISC-V ist offen und ermöglicht nun jedem Anbieter, der CPU-KErne gestaltet, dass man diese CPU-Kerne auch weiter lizensieren darf.

RISC-V ist eine quelloffene Architektur

Jaein, wichtig ist hier: Die ISA ist quell offen und kann von jedem, der möchte verwendet werden. CPU-KErne und Co, die mit dieser ISA entworfen werden müssen aber nicht quelloffen sein.

Eine RISC-V Architektur ist also nicht automatisch quelloffen, nur weil die ISA quelloffen ist.

 

[flaphoschi]

Und wie Apple gezeigt hat, ist so ein Wechsel heute besser möglich, wenn es clevere Lösungen für die alten Binaries gibt.

Ja. Nein.

Apple wirft auch gnadenlos alles über Bord, was sie nicht zwingend brauchen:

• MacOS 10.0 Einführung Cocoa und Quartz
• Classic - Rauswurf mit 10.4 (Emulation)
• PowerPC - Rauswurf Kompatbilität 10.7 (Universal Binarys)
• Carbon - Rauswurf mit 10.15 (ziemlich lange, Library zur Kompatiblität)
• iOS - Rauswurf aller 32 Bit Apps

Microsoft wirft dagege nie etwas weg. Die ABI und API bleibt, bei Toolkits wird alle paar Jahre ein neues als letzte Lösung vermarktet und die alte Version einfach nicht mehr geändert

Bei Linux rastet Torvalds regelmässig - zu recht - aus, wenn jemand die Rückwärtkompatiblität bricht. Die GLIBC ist soweit stabil bei der API und ABI. Und mit Systemd bringt langsame eine Vereinheitlichung und Stabilitisierung des System-Verwaltung und Dienste (das ist richtig gut für Entwickler, Grund zu Meckern gibt es immer, aber nicht übertrieben). Und so kommt es, dass wir seit bald 10 Jahren X11 ablösen und auf Wayland wechseln (ich bin da schon seit vier Jahren). Und ich bin mir sicher, in zehn Jahren ist X11 immer noch da für die Kompatibilität.

Um zum Thema zurück zu kommen. In zehn Jahren ist Apple wahrscheinlich nicht mehr zu Intel kompatibel, obwohl dafür heute noch entwickelt wird? OpenGL werden sie wahrscheinlich noch lange behalten, dass erfährt ja auch noch Weiterentwicklung. Vielleicht gibt es dann neue Universal-Binaries für ARM/RISC-V

Ergänzung (8. Februar 2022)

Der Grund für diese Extensions ist der Spagat zwischen einer (in dieser Branche nicht alltäglichen) Abwärtskompatibilität und einer notwendigen technischen Weiterentwicklung. Jede Iteration von SSE hat Sinn ergeben und war bestimmten Problemen gewidmet... dasselbe gilt für AVX.

Hintergrund und Kritik an Extensions. Etwas vereinfacht:

https://www.pcgamer.com/linux-found...-instructions-and-start-fixing-real-problems/
https://www.zdnet.com/article/linus...hanging-how-processor-interrupts-are-handled/

Was Torvalds hier wohl ärgert ist, dass die Programmierer unzählige Sonderfälle bekommen. Und nur damit Intel in irgend einem Benchmark schneller ist. Im schlimmsten Fall kommt dann sowas wie SMT (!= SMP) heraus und verursacht Ärger. Das Prozessorinterface sollte gleich bleiben und effizienter werden. Wie? Da ist die Aufgabe des Herstellers, nicht der Programmierer.

Intel so

Wir haben die Leistungsaufnahme nicht unter Kontrolle. Wir haben ineffiziente P-Cores und effiziente E-Cores. Die P-Cores sind zum Benchmark gewinnen. Die E-Cores haben nicht alle Extensions, kein SMT und skalieren viel besser. Schreibt mal spezielle Scheduler, sonst läuft das nicht gescheit! Wenn euch was nicht passt, geht doch!

Torvalds etwa so:

Bei AMD sieht das Gras deutlich grüner aus.

Wenn man weiter zurück geht in der Geschichte kommt man bei CISC und RISC vorbei.

 

[DevPandi]

Microsoft wirft dagege nie etwas weg. Die ABI und API bleibt, bei Toolkits wird alle paar Jahre ein neues als letzte Lösung vermarktet und die alte Version einfach nicht mehr geändert

Na ja, nie etwas wegwerfen stimmt da nicht so ganz. Mit "NT" allgemein hat man ja mit der Kompatiblität zu den "DOS"-Versionen gebrochen.

Und was gewisse Treiber angeht usw ist Microsoft auch schnell dabei mal Änderungen zu machen, die da durchaus auch kritischer Natur sind, dass dann nichts mehr geht.

Die Probleme bei Microsoft sind da zum Teil eher etwas anders gelagert und auch weitgreifender. Microsoft versucht ja erst jetzt wirklich eine saubere und umfassende API für die Softwareentwicklung bereit zustellen mit der Verschmelzung aus Win32-API und WinRT-API.

Apples "gnadenloser" Umgang mit Balast ist auch primär dem Lehrgeld geschuldet, dass Apple in Ende der 80er und auch Anfang der 90er zahlen musste und das auch fast zur Insolvenz geführt hätte. Man hatte in den 80er und 90er auch bei Apple stark auf Kompatiblität geachtet und hat sich damit in eine Entwicklungssackgasse geführt - die Geschichte um Mac OS 8 und 9 - und hatte gleichzeitig auch das Problem damals mit dem ersten großen Architekturwechsel von 68k auf PowerPC. Apple hat damals gemerkt, wie wichtig eine saubere und auch umfassende API für ein Betriebsystem ist, damit man Plattformabhängigen-Code aus Programmen weitgehend verbannt und diesen nur noch an ein paar Stellen des Betriebssystems anpasst.

Genauso verhält es sich mit alten Bestandteilen, die man nicht mehr "benötigt" und da kommt halt auch die doch sehr gute Cocoa-API und die anderen APIs von Darwin und MacOS zu tragen: Wenn man Cocoa, Metal und Co verwendet, dann reicht in der Regel bei einem Programm das erneute kompilieren und man kann locker zwischen x86 und AArch wechseln, genauso wenn sich was im Betriebssystem ändert was die Arch angeht, in der Regel reicht einfach ein neues kompilieren, weil die Anpassungen durch Apple in Darwin, iOS, iPad OS oder MacOS vorgenommen werden.

Bei Linux rastet Torvalds regelmässig - zu recht - aus, wenn jemand die Rückwärtkompatiblität bricht.

Nicht ganz richtig, nicht ganz falsch.

Es kommt darauf, über was wir sprechen. Geht es um den Linux-Kernel, hast du recht, da wird auf eine gewisse Rückwärtskompatiblität geachtet, aber im Kernel eine gewisse Kompatiblität zu bewahren ist ein Stück einfacher, als dann im ganzen OS.

Das merkt man schnell, wenn man Programme zwischen verschiedenen Distrubitionen hin und her schieben will und wenn dann etwas nicht funktioniert. Für Proramme und Co muss mann dann oft sehr wohl noch mal einen Kompiler anwerfen und erneut kompilieren, damit es funktioniert.

Man kann ein "OS" auf Linux-Basis so zusammen bauen, das "x11" nioch funktioniert, genauso kann ich es aber auch bauen, dass es nicht mehr geht. Kommt halt darauf an, was man dann wegwerfen will und nicht.

 

[flaphoschi]

Das merkt man schnell, wenn man Programme zwischen verschiedenen Distrubitionen hin und her schieben will und wenn dann etwas nicht funktioniert. Für Proramme und Co muss mann dann oft sehr wohl noch mal einen Kompiler anwerfen und erneut kompilieren, damit es funktioniert.

Nicht ganz richtig und nicht ganz falsch

Unter Linux ist Source-Kompatibilität wichtig (API), nicht Binärkompatibilität (ABI). Erbe von UNIX und der Vorteil quelloffener Software, hat schnellen Wechsel auf X86_64 erlaubt. Dazu ARM, PPC, RISC-V.

Debian etwa hat halt oft eine altes SO oder ein Feature auskomponiert. Wer das umgehen will, Windowstaktik (alle Libraries dazu packen). Da verrennen sich Windowsleute oft und machen den Fehler ihre Software für spezielle Distributionen zu paketieren - nicht Ihre Aufgabe. Objekte oder Source bereitstellen, Distributionen paketieren lassen oder direkt Flatpak.

 

[eastcoast_pete]

@DevPandi: Stimme Dir zu; die Architektur (ISA) ist quelloffen, aber ein darauf basierendes Chip Design kann bzw darf man nicht einfach nachbauen. Wird hier aber auf jeden Fall interessant, da Intel sich hier auch viele Optionen offen lassen will.
Und (Achtung, reine Spekulation!) wäre es doch interessant, wenn Google sich auch bei RISC-V umsieht. Vielleicht gibt's ja auch Mal einen Pixel 7 oder 8 mit RISC-V ISA; sowas wäre das viel gesuchte "Halo" Produkt der RISC-V mit Android im Smartphone anschieben könnte.