News Open-Source-Architektur: Western Digital will auf RISC-V umsteigen

[cirrussc]

Es gab früher aber eine ganze Reihe verschiedener RISC-Architekturen. Z.B. MIPS und ALPHA.

MIPS gibt es nachwievor.

 

[Kulasko]

Och Leute...
RISC ist keine Architektur, es ist eine Kategorie. RISC-V dagegen ist der Name einer Architektur.

Was den Cell-Prozessor der PS3 angeht, ich bin relativ froh, dass sich das Ding nicht durchgesetzt hat. Das PPE war im Prinzip ein "normaler" und sogar relativ schmaler Prozessorkern, die SPE hingegen konnten nur rechnen und war für Kontrollstrukturen im Code auf das PPE angewiesen. Im Prinzip kann man darin eine Art Äquivalent zu heutigen Grafikkarten ziehen.

Zum Thema, ich finde die Umstellung auf Open Source Architekturen in jedem Fall begrüßenswert, wobei RISC-V auch ein relativ zweischneidiges Schwert ist. Zwar erweiterbar wie sonst was, diese Erweiterungen werden aber natürlich nur von Programmen genutzt, die dafür kompiliert wurden, womit man im Prinzip eine Open Souce Version des x86 Problems hat.
Für spezialisierte Controller wird das aber wohl okay sein.

 

[textract]

Die PS3 hatte - der "CELL-Prozessor" - 1,5 PowerPC-Kerne. Nochmal andere Bausteille.

Nein, kein bisschen andere Baustelle.
Ja: CELL ist ein POWER Chip
Ja: POWER nutzt RISC Befehlssatz

POWER ist lediglich eine Abkürzung for Performance Optimization With Enhanced RISC.
RISC ist eine Abkürzung für Reduced Instruction Set Computer.

RISC ist keine Architektur, RISC ist der Befehlssatz der CPU.

 

[Bigfoot29]

Aber die Cell-CPUs basieren dochauf der RISC Arch soweit ich das dem Post von Teralios entnehmen kann.

Ja, tut sie. Wobei RISC keine CPU-Architektur wie "ARM" oder "x86" ist, sondern eine (grundlegendere) CPU-Infrastruktur. In den letzten 20 Jahren hat sich der CISC/RISC-War dadurch aufgelöst, dass heute mehr oder weniger alle CPUs "enhanced RISC" sind. Die heutigen großen General Purpose CPUs haben so viel Vorab-Befehls-Decoder-Power, dass sie zwar nach außen hin als CISC gelten, intern aber (fast) alle(s als) RISC bearbeiten. Ich könnte Dir derzeit nicht genau sagen, WO GENAU die Grenze heute zwischen RISC und CISC verläuft. Letztlich haben reine RISC-Prozessoren aber nach außen hin deutlich höhere Compiler-Anforderungen, weil man die Befehle in weniger mögliche CPU-Ops zerlegen muss als bei CISC, wo dies die CPU selbst erledigt. Intel z.B. bezeichnet die internen RISC-Befehle als µOps, die der Decoder selber erzeugt. Dem Prozessor sagt man nur "Mach man Hausflur!" und er zerlegt den Befehl dank seiner Übersetzungstabellen in die Arbeitsanweisungen "Fegen und durchwischen", welches dann zwei Einheiten nacheinander ausführen. (Wobei mir klar ist, dass man sowohl fegen als auch wischen noch deutlich weiter in Minimal-Operationen zerlegen kann. - Ging ums Prinzip.)

Nachtrag: Den damaligen CELL mit damals verfügbaren ARM-Prozessoren zu vergleichen ist genauso wenig zielführend wie der Vergleich von einem LKW mit einem 3l-Auto. Der CELL (LKW) war als Hochleistungsprozessor ausgelegt, der große Mengen an Berechnungen mit guter Siliziums-Auslastung und akzeptablem Verbrauch bearbeiten konnte. Die ARMs ihrer Zeit waren kaum über 1GHz zu kriegen, weil die Architektur auf maximale Energieeffizienz bei nicht zwingend maximaler Leistung ausgelegt war. Letztlich ja einer der Gründe, warum wir ARM-Cores in Smartphones haben und keine CELLs (oder x86-CPUs, wobei Intel, nachdem es erstmal sämtliches mobile CPU knowhow verkauft hat, ja alle Register gezogen hat, um die Atoms halbwegs ähnlich fit bzgl. Energieverbrauch vs. "mobile"-gerechte Leistung zu werden).

Erst seit sehr wenig Jahren kommen die ARM CPUs so langsam durch "massive Multicoring" (wieder) an die Leistung der Groß-GP-CPUs wie Power oder x86 heran. Aber gut, das war ja auch das Gründungs-Jahrzehnt (von ARM) lang nicht das Primär-Ziel der CPU-Core-IP-Schmiede.

Regards, Bigfoot29

Nachtrag:
@textract: Wie Kulasko schon schreibt, ist RISC kein "Befehlssatz". Ein Befehlssatz wäre die Struktur x86. Eine Befehlssatz-Erweiterung beispielsweise SSE. Beim CELL war der Befehlssatz PowerPC mit frei definierbarem Endian-Handling. (Meist Big Endian)
RISC hingegen ist eine Art, einen Prozessor zu designen. Plain RISC bedeutet: ich habe X "fest verdrahtete" (auch wieder relativ) Befehle, die sich nicht überlappen und die in so wenig wie möglichen Taktzyklen abgearbeitet werden können. CISC ist eine Design-Philosophie, in der man - übertrieben gesagt - auch ein "boote mir Windows" als CPU-Befehl durch den Befehlssatz-Owner (Intel/AMD/Who ever) hätte implementieren können. Als Voraussetzung hätte man lediglich den Kernel-Blob mitgegeben und die CPU hätte alles weitere "befehlsintern" abgearbeitet und erst am Ende gesagt "K. Windows gebootet. Nächster Befehl?". Für Linux hätte man einen eigenen Befehl implementieren müssen/können, der aber 40% mit dem Windows-Befehl deckungsgleich wäre. Zugegeben SEHR grafisch geschrieben, aber ich hoffe, es wird klar, was gemeint ist. bei RISC gibt der Software Code Interpreter Minimal-Befehle an die CPU, die diese Dank Minimalismus schnell abarbeitet, von denen aber vergleichsweise viele ausgeführt werden müssen, um eine komplexe Aufgabe zu erledigen. CISC erlaubt komplexere Befehle in einem Rutsch entgegenzunehmen, braucht mit deren Abarbeitung aber länger. - Möglicherweise sogar länger als optimierter RISC-Code. Und falls es schneller ist, ist es teurer, diese CPU herzustellen, weil man besonderes Augenmerk darauf legen musste, diese Funktion explizit zu implementieren.

Regards, Bigfoot29

 

[Miuwa]

Weil die Begriffe hier ständig durcheinander geworfen werden:

- CISC/RISC sind Designphilosophien für Prozessoren
- ARM ist eine Firma
- RISC-V, ARMv7, ARMv8, x86, x64 sind verschiedene instruction set architectures (ISA, bzw. Überbegriffe, da es von den meisten noch verschiedene Unterversionen oder Erweiterungen gibt) also im wesentlichen die Spezifikationen der Binärsprachen die von bestimmten Prozessorfamilien verstanden wird.
- Sandy Bridge, Cannon Lake, ARM Cortex-A7/8/9..., Apple A6/7/8 ... sind CPU/SOC Architekturen die jeweils eine bestimmte ISA verstehen/implementieren.

Wahrscheinlich kommen jetzt gleich noch ein paar echte Experten, die diese Gliederung nochmal auseinander nehmen, aber ich hoffe dass räumt die gröbsten Verwirrungen aus dem Weg. Das wichtigste: Genauso, wie die x86 ISA von den verschiedensten Chips verstanden wird (von den Intel Quarks bis zu Serverprozessoren) lassen sich auch die verschiedensten Chips für die RISC-V ISA entwerfen.

 

[textract]

@Bigfoot29
Ja, hast völlig Recht, Weihnachtsmarkthopping, als Analogie zum Barhopping, war heute wohl doch keine so gute Idee.

RISC oder CISC definiert ob man lieber eine CPU baut, die viele, schnelle und einfache Befehle von der CPU berechnen lassen will, oder es sinnvoller ist, je nach Anwendung, komplexe Befehle an die CPU zu geben, die auch mehrere Taktzyklen zur Berechnung braucht.

 

[Holt]

bin mal gespannt was genau WD da vor hat. Die Storage-Systeme mit spezialisierten CPUs "intelligenter" zu machen könnte jedenfalls neue Möglichkeiten eröffnen.

Nur muss der Rest dies unterstützen und da dürften noch einige Hürden zu überwinden sein. Bisher bieten alle Massenspeicher einen linearen Adressraum und die Betriebssyteme verwalten diesen, einmal in Form der Aufteilung über die Partitionierung und dann über die Filesysteme. Es gibt Ansätze bei SSDs die in die Richtung gehen diese als Key Value Storage arbeiten zu lassen, was ein ganz anderes Protokoll erfordern und wohl den Wegfall der Filesysteme bedeuten würde.

Aber SSDs haben sowieso aufwendige Controller und die große Mengen an Metadaten verwalten müssen, HDDs aber kommen bisher mit weitaus einfacheren Controllern daher. Hier würden dann wohl die Kosten und die Leistungsaufnahme steigen, wenn man deren Controller neue Aufgaben übertragen würde.

 

[Jesterfox]

Ja, der Rest muss solche Ansätze dann auch erst mal mit unterstützen und man wird neue Schnittstellen und Protokolle benötigen. Aber ich denke das man damit die Last besser verteilen könnte, an Stellen wo man sie auch besser abfangen kann. Ist wie mit Datenbanken: man kann sie einfach nur als dumme Tabellenlager sehen oder aber ihre volle Programmierfähigkeit nutzen und so die Last vom Application Server teilweise auf den DB Server verlagern.

 

[TZUI1111]

@ Bigfoot
Danke

 

[BlackWidowmaker]

Wenn du die deiner Meinung nach 95% geplante Obseleszenz entfernst bist du vermutlich wieder auf dem Stand der 90er und dann?

Lächerliche Behauptung. Ein PC ohne geplante Obsoleszenz wäre aber sicherlich ähnlich Modular wie ein 90er Jahre PC, da gebe ich Dir Recht. Sprich ein MB mit zwei große Sockel, einen für CPU, einen für den 3D-Beschleuniger. Dann Steckplätze nicht nur für RAM, sondern auch VRAM, aber ganz besonders wichtig auch für L3-Cache. Denn massiv aufzubohren brachte beim 486er auch mehr als z.B. der Wechsel von einer DX2-66 zu einer DX-2 100 CPU. Das vermisse ich am meisten vom 486er - gesteckter Cache, den man selbst erweitern kann. Vor allem in diesem Super-Kastrat namens Skylake-X der Gipfel an geplante Obsoleszenz. Zuerst Zahnpasta-Kühlung dann noch den L3-Cache kastrieren. Denen ist wirklich nichts heilig um Profit zu machen.

Meine früher gestellte Forderung, Steckplätze für Flash-Speicher ist durch M.2, aber auch durch moderne Serverboards mit extra Steckplätze für 3D Xpoint, ja auch indirekt wahr geworden.

Und letztendlich nicht alle naslang neue Hardware auf den Markt bringen, bei der man alle Komponenten raus schmeißen muß, sondern man auch sinnvoll für spätere Ergänzung/Erweiterung planen könnte.

 

[Wadenbeisser]

Die geplante Obsoleszenz ist das frühzeitige Ableben des Produkts und dafür sehe ich bei dir keinerlei Anhaltspunkte.
Sie mögen zu für neuere Programme langsam werden aber das hat damit nichts zu tuen. Dir passt der Aufbau der aktuellen Hardware nicht, das ist alles.

 

[Holt]

Geplante Obsoleszenz bedeutet, dass ein Produkt gewollt nicht so lange hält wie es technisch könnte, weil man bewusst eine Schwachstelle einbaut. Davon wäre mir bei CPUs aber kein Beispiel bekannt, diese werden durch den technischen Fortschritt immer schneller und effizienter, was den Produktiveinsatz alter HW dann oft schon vor den Erreichen des Endes der geplanten Nutzungsdauer von meist 5 Jahren oft unwirtschaftlich macht. Es gibt auch HW die für eine längere Einsatzdauer ausgelegt wird, im Embedded, Industrial und vor allem Automotiv Bereich, aber diese lohnt sich nur, weil die Geräte denen diese HW dann dort dient eben für eine längere Nutzungsdauer ausgelegt sind und die Computer dort nur eine untergeordnete Rolle im Endprodukt spielen.

Geplante Obsoleszenz gibt es, aber nicht so oft und überall dort wo dieses gerne unterstellt wird! Gerade CPUs halten seht lange und meist sind es die Mainboards die vorher aufgeben, selbst wenn die CPU deutlich übertaktet war.

Aber ich denke das man damit die Last besser verteilen könnte, an Stellen wo man sie auch besser abfangen kann.

In einem professionellen Storage steckt eine Menge CPU Power, da ist oft eher die Anbindung der Flaschenhals und dann macht es Sinn diesem mehr Berechnungsaufwand zu übertragen. Aber bei eiinem Desktop ist die CPU Last bei Zugriffen auf die Speichermedien dort eher gering und die aktuellen Schnittstellen bieten meist genug Bandbreite, der mögliche Zugewinn ist hier also gering.

Ist wie mit Datenbanken: man kann sie einfach nur als dumme Tabellenlager sehen oder aber ihre volle Programmierfähigkeit nutzen und so die Last vom Application Server teilweise auf den DB Server verlagern.

Allerdings ist bei kommerziellen Datenbanken wie Oracle die CPU des DB-Server die mit Abstand teuerste im System., weil die Kosten der DB Lizenz sich nach der richten und daher will man diese eigentlich immer möglichst entlasten statt sie zu belasten.

 

[Diablokiller999]

Auch Nvidia gibt der Open-Source-Architektur eine Chance

Sowas könnt ihr mir doch nicht morgens vor den Latz knallen, vor lauter Schreck hab ich meinen Kaffee über den Arbeitsplatz verspritzt!

 

[Bigfoot29]

@Diablokiller999: Schade, dass man hier keine Kommentare bewerten kann...

Regards, Bigfoot29

 

[konkretor]

@
Diablokiller999

@Rest sind ein ein paar gute Kommentare dabei *thumps up*

 

[textract]

Sowas könnt ihr mir doch nicht morgens vor den Latz knallen, vor lauter Schreck hab ich meinen Kaffee über den Arbeitsplatz verspritzt!

Naja, falsch ist das nicht, wenn es um Hardware geht. Nvidia ist immerhin auch Mitbegründer der OpenPOWER Foundation.
Außerdem kommen ihre neuen Deep Learning Teslas aktuell lediglich mit eigenen Treiber für POWER9 CPUs.

Bei Software gebe ich dir natürlich Recht.

 

[Raucherdackel!]

Es gab früher aber eine ganze Reihe verschiedener RISC-Architekturen. Z.B. MIPS und ALPHA.

MIPS gibt es immer noch, und sind sehr erfolgreich in High End Sat Receivern, wie zum Beispiel Dreambox, Vu+ und deren ganzen Nachbauten und Klone davon.

 

[Bigfoot29]

...wobei der einzige Grund dafür ist, dass sie billiger als vergleichbare ARM-Prozessoren sind und auch die Energie-Effizienz nicht unbedingt den ARM-Modellen entsprechen muss.

Hinweis: ich habe gar nichts gegen MIPS-Prozessoren. Ich und meine DBox2 waren beste Freunde. Nur: In vielen Bereichen, wo es um maximale Effizienz geht, ist MIPS leider nicht (mehr?) konkurrenzfähig.

Regards, Bigfoot29

 

[BlackWidowmaker]

Geplante Obsoleszenz bedeutet, dass ein Produkt gewollt nicht so lange hält wie es technisch könnte, weil man bewusst eine Schwachstelle einbaut.

Stimmt, ABER die Schwachstelle muß nicht zwingend ein geplanter Defekt sein. Eine Nicht-Aufrüstbarkeit ist meines Erachtens ebenso geplante Obsoleszenz. Ebenso eine völlig unnötige Kastrierung eines Systems, bei der man z.B. 1% Kosten spart, aber der User 30% weniger Leistung hat. So z.B. der L3-Cache bei CPUs. Bringt im wirklichen Alltag, abseits vom Benchmark-Universum-Schwachsinn wesentlich mehr Performance eines Systems als schnellere CPU-Taktung, oder schnellerer RAM, oder sonstiger Schwachsinn. Aber wird einfach ignoriert, totgeschwiegen und heruntergespielt. Ich kenne keinen einzigen Test, bei dem der Umfang des L3-Caches wirklich in relevanter Art getestet wurde, lasse mich aber gerne eines besseren belehren.

 

[joshy337]

Geplante Obsoleszenz bedeutet, dass ein Produkt gewollt nicht so lange hält wie es technisch könnte, weil man bewusst eine Schwachstelle einbaut. Davon wäre mir bei CPUs aber kein Beispiel bekannt, diese werden durch den technischen Fortschritt immer schneller und effizienter, was den Produktiveinsatz alter HW dann oft schon vor den Erreichen des Endes der geplanten Nutzungsdauer von meist 5 Jahren oft unwirtschaftlich macht. Es gibt auch HW die für eine längere Einsatzdauer ausgelegt wird, im Embedded, Industrial und vor allem Automotiv Bereich, aber diese lohnt sich nur, weil die Geräte denen diese HW dann dort dient eben für eine längere Nutzungsdauer ausgelegt sind und die Computer dort nur eine untergeordnete Rolle im Endprodukt spielen.

Bei den aktuellen CPUs stimme ich zu, wobei es bei der x86 Firmware nicht so rosig aussieht.
Ob man das mehr oder wenig grundlose Entfernen von grundlegenden Funktionen als geplante Obsoleszenz bezeichnen darf,
weiß ich allerdings nicht.
Schade finde ich es persönlich allemal, da die kommenden Probleme in keinem Verhältnis zum Nutzen liegen.
Das ist vergleichbar mit der anstehenden Abschaltung von 3G und des GSM-Netzes in den nächsten Jahren:
In der Öffentlicheit zwar praktisch in Vergessenheit geraten und für tot erklärt, trägt GSM im Hintergrund immernoch ein
Großteil unserer Infrastruktur (M2M-Anwendungen).

Was ich an der x86 PC-Architektur immer bewundert habe, war die konsequente und durchgehende Kompatibeliät
und damit verbundene Zukunftssicherheit. Auch die Genialität der Entwickler, alt und neu irgendwie zu vereinen..
Versteht mich bitte nicht falsch, ich mag UEFI und finde es toll. Aber wenn die IT-Branche erstmal anfängt,
alte Zöpfe dieser Größenordnung abzuschneiden, wird es möglicherweise zur Gewohnheit.
Dann können wir uns alle 10 Jahre auf eine neue, inkompatible Firmware/Architektur freuen.

Der nächste logische Schritt wäre dann z.B. das Entfernen von CPU-Funktionen, die im 64-Bit-Computing
nicht mehr gebraucht werden (x87, MMX, 16/32-Bit Register). Was am Ende von der PC-Architektur bleibt,
hat dann womöglich nur noch wenig mit dem gemeinsam, was wir als PC kennen.
Schlußendlich fragt sich dann, welchen Nutzen x86 dann noch hat. Es gibt bessere Architekturen.
Auf diese könnten Win10 und Linux ebenfalls portiert werden. .Net- und Metro-Anwendungen liefen im Prinzip auch dort.
Nur Win32/64-Anwendungen "hängen" noch an der x86 Architektur (auf dem Desktop).