blackiwid schrieb:
Hab gehört das die amerikanischen Behörden nicht kapieren das man ne Architektur nicht am Einführen nach China verhindern kann.
Ich denke schon, dass die wissen, was sie koennen. Und die RISC-V Foundation ist sofort in die Schweiz umgezogen, als die USA ARM auferlegt haben, nicht nach China zu lizensieren.
Ist Risc als Architektur neben dem offenen besser als X86?
Besser nach welchem Kriterium?
RISCs im allgemeinen und RISC-V im speziellen verursachen weniger Aufwand bei der Implementierung und vor allem bei der Validierung der Implementierung; ein Beispiel fuer die Probleme, die sich daraus ergeben, ist Downfall (wobei Downfall nicht aus den Features herkommt, die von 8086..386 geerbt wurden, sondern von den relativ neuen (2011) AVX-Befehlen, aber wenn sie sich dabei an das RISC-Prinzip "Maximal ein Speicherzugriff pro Befehl" gehalten haetten, haetten sie sich Downfall erspart).
Nichtsdestoweniger hat das weder Intel noch AMD davon abgehalten, sehr schnelle CPU-Kerne zu entwickeln, an die fuer meine Benchmarks niemand anderer herankommt (und bei anderen Benchmarks nur Apple).
Was den Energieverbrauch betrifft, ist die Frage, ob die Unterschiede sich daraus ergeben, dass Intel und AMD seit Jahrzehnten im Wettbewerb um die Geschwindigkeit stehen, der laengste Balken im Benchmark zaehlt, und der laengste Balken im Energieverbrauch wird von den Kunden akzeptiert; nicht einmal bei den Laptops ist es viel anders, wenn auch die Kuehlsysteme dort noch nicht soviel wegkuehlen koennen. Im Gegensatz dazu wurde ARM bei den Mobiltelefonen gross, wo die Power Limits viel niedriger sind, und wo die Prozessoren dauernd laufen, und dementsprechend wurden sie seit Jahrzehnten in diese Richtung entwickelt, und die Entwickler wissen, wie das geht.
Ich mein wenn es halbwegs schnelle Prozessoren ohne Blobs drin gäbe wäre schon viel gewonnen vor allem mit GPUs ohne Blobs. (Firmware)
Da nuetzt RISC-V nichts, weil das ist eine Architektur fuer CPUs, nicht GPUs. Wenn Intel mit Larrabee Erfolg gehabt haette, haetten wir vielleicht weniger Blobs in der Grafik gehabt. Neben der Grafik gibt's auf typischen ARM-SoCs jede Menge Zeug ohne oeffentliche Hardware-Doku, wo Treiber fuer Android-Linux geliefert werden, die nicht gewartet werden, sobald der SoC nicht mehr verkauft wird.
Ich wuerde mir von RISC-V-SoCs nichts besseres erwarten, auch wenn das die RISC-V-Gruender sicher auch lieber anders haetten; aber die Kraefte, die diesen Mist bei den ARM-SoCs verursachen, wirken genauso in den Maerkten, in denen RISC-V unterwegs ist.
Dass es bei den PCs ein bisschen besser ist, liegt eben daran, dass PCs offene Systeme sind, die aus den verschiedensten Komponenten zusammengebaut werden. Zumindest war es frueher so. Mit dem Einzug von Prozessoren auf die Erweiterungskarten selbst konnten die Hersteller dann Teile der Treiber auf die Karten verlegen und die Software dafuer dann in Form von Blobs zur Verfuegung stellen. Und so wachsen die Blobs auch unter Linux seit vielen Jahren.
In der Hinsicht sind die Smartphones wohl noch weniger weit, weil's dort keine separaten Karten gibt, und man wohl auf einem SoC seltener noch einen Extrakern fuer eine Spezialfunktion spendiert, wenn es auf dem SoC ohnehin einen Haufen CPU-Kerne gibt. Aber wenn der Treiber dann nicht gewartet wird, hat man auch wenig davon, selbst wenn der Treiber als freie Software vorliegt.