News RISC-V: Debian Trixie auf dem VisionFive 2 SBC

[SSD960]

Danke für den Test. Interessiert mich sehr was abseits der X86 Technologie passiert. Bin aber seit Jahren bei den Raspi hängengeblieben.

 

[Xeroxxx]

Ich habe in Vergangenheit mit neuen Kernel Releases immer mal Test aus dem VisionFive 2 gefahren. Hier kann man schön sehen woran gearbeitet und zugelegt wurde.

https://wiki.isunreal.de/books/technology/page/visionfive-2-risc-v-jh7110

 

[TomH22]

Wieso wurde nicht das Testboard von Framework genutzt?
https://frame.work/de/de/products/deep-computing-risc-v-mainboard
Das nutzt den gleichen Prozessor und kostet erstmal (ohne alles außer den 8GiB LPDDR) nur 199€ statt 399€, die ursprünglich abgeschreckt hatten...
(und ist kompatibel zum gesamten Framework-Kosmos)

Du bringst da ein paar Dinge durcheinander. Das Framework Mainboard beruht in der Tat auf den gleichen SoC (StarFive JH-7110) wie das VisionFive2, welches um 100 EUR kostet (je nach Lieferant/Ausstattung). 399 USD kostet das HiFive Premier P550 (https://www.sifive.com/boards/hifive-premier-p550). Der dort eingesetzte SoC ist allerdings deutlich leistungsfähiger als der JH-7110. „Abgeschreckt“ haben mich auch nicht so sehr die 399 USD (hatte das Produkt schon im Warenkorb, wobei Versand + Einfuhr UST auch noch mal ordentlich was draufschlagen), sondern die vielen technischen Einschränkungen und Fallstricke (z.B. eingeschränkte Kompatibilität mit ATX Netzteilen).

Zu dem Framework Board schreibt Framework selber:

Obwohl die Leistung und die Peripheriefunktionen derzeit noch begrenzt sind, bietet sie eine einzigartige Gelegenheit, sich mit dieser aufstrebenden Technologie in einem raffinierten Laptop-Formfaktor zu beschäftigen.

und

Dieses Board ist sehr stark auf Entwickler fokussiert, um die Reifung des Software-Ökosystems rund um RISC-V zu beschleunigen. Wir empfehlen daher, auf zukünftige RISC-V-Produkte zu warten, wenn Sie auf der Suche nach einer verbraucherfreundlichen Erfahrung sind.

Ich würde wirklich jedem abraten das Framework Board zu kaufen, als Laptop SoC ist der JH-7110 nicht zu gebrauchen. Als „Headless“ Linux Computer für einfache Serveraufgaben, als Router, Firewall, usw. ist er hingegen problemlos einsetzbar, allerdings mit der Einschränkung, dass es vieles nicht als RISC-V Binary gibt (z.B. InfluxDB oder die meisten fertigen Docker Images).

Ergänzung (1. September 2025)

Komischer "Benchmark", nutzt im Durchschnitt nur 10% Leistung der CPU.

Jestream ist als JavaScript Benchmark prinzipbedingt single threaded. Er soll auch nicht die Leistung der CPU messen, sondern die JavaScript Performance des Systems. In meinem Leserartikel ist das besser erklärt, als in der Zusammenfassung.

Laut Tabelle kann der VisionFive2 H264 und H265 hardware decoding.

Soweit ich aus der Dokumentation rausgelesen habe, werden die Hardware Decoder nur in einer speziell gepatchten Version des VLC Players genutzt, nicht im Browser. Es ist aber auch egal, da schon das laden der YouTube Startseite ewige dauert. Dieser Screenshot im dem Artikel war eine halbe Stunde Arbeit…

 

[Piktogramm]

@mae
Ok, ZSTD gebaut (-O2 -march=X86_64_v3) mit Debugsymbolen (-g) und dann mit perf geschaut, welche Funktionen länger laufen. Ganz grundlegend wird in compressStream2 bzw. decompressStream. Es überwiegen skalare Befehle, Vektorbefehle sind allenfalls immer mal wieder "unaligned mov" (vmovdqa), das machts Kraut wirklich nicht fett.


Edit: Hat wer ne zugängliche Quelle um perf Events bzw. Register für PerfCounter für Intel, AMD, ARM Prozessoren zu finden?

 

[mae]

"unaligned mov" (vmovdqa)

Aendert zwar nichts an der Sache, aber entweder "aligned mov" (vmovdqa) oder "unaligned mov" (vmovdqu).

Edit: Hat wer ne zugängliche Quelle um perf Events bzw. Register für PerfCounter für Intel, AMD, ARM Prozessoren zu finden?

Ich verwende "perf list". Ist aber abhaengig von der Unterstuetzung durch die Prozessorhersteller. Fuer Intel gibt's noch ocperf.py von Andi Kleen, das die raw-Events fuer die benannten Events ausgibt (oder im Normalfall gleich perf mit diesen Events aufruft). Nach Doku dazu habe ich laenger nicht gesucht, aber ich habe den Eindruck, dass die Hersteller dazu uebergegangen sind, das lieber in Tools einzubauen als fuer die Allgemeinheit zu dokumentieren.

 

[Chaosbreed]

RISC-V ist mir leider noch zu teuer, zu langsam und Software gibt es auch nicht genug. Dann lieber ein Raspberry oder der Intel n100.

Als ESP32-P4 (2x 400 Mhz RISC-V) sicher ein guter Leistungsfähiger Chip für 12€ +6 Versand kommt man aber auch Richtung Raspberry Pi Zero 2 W (4 X 1 GHz).
Ja der braucht mehr Strom ist aber von der Rechenpower schon ordentlich mehr. (Software ist auch breiter unterstützt)

 

[mae]

399 USD kostet das HiFive Premier P550 (https://www.sifive.com/boards/hifive-premier-p550). [...] „Abgeschreckt“ haben mich [...] die vielen technischen Einschränkungen und Fallstricke (z.B. eingeschränkte Kompatibilität mit ATX Netzteilen).

Auf der Website steht "Board requires standard ATX power supply". Dass sie noch welche listen, mit denen sie getestet haben, muss jetzt nicht heissen, dass andere nicht gehen; oder steht woanders etwas ueber Einschraenkungen? Mich schreckt im ersten Moment der mini-DTX-Formfaktor ab. Wir haben da noch ein mini-ITX-Gehaeuse mit einem kleinen ATX-Netzteil, was ideal fuer sowas waere (wir haben in solche Gehaeuse auch schon Boards mit Intel E-Kernen eingebaut), aber dieses Board passt da nicht hinein. Der Preis ist auch ein Thema.

 

[TomH22]

Dass sie noch welche listen, mit denen sie getestet haben, muss jetzt nicht heissen, dass andere nicht gehen

In irgendeinem Readme oder im SiFive Forum stand seinerzeit (Dezember 2024) das bei vielen ATX Netzteilen sich das Board nicht einschalten lässt. Bin gerade unterwegs und kann die Quelle nicht raussuchen. Außerdem war im Dezember der Unbuntu Port noch „geplant“. Und ich habe schon die Mikrocontroller Boards (HiFive1 rev 1 und 2) und die wurden von SiFive nur sehr lieblos supported.

 

[mae]

In irgendeinem Readme oder im SiFive Forum stand seinerzeit (Dezember 2024) das bei vielen ATX Netzteilen sich das Board nicht einschalten lässt. Bin gerade unterwegs und kann die Quelle nicht raussuchen.

Danke, nicht noetig, wenn ich doch ueberlegen sollte, das anzuschaffen, suche ich danach.

 

[aid0nex]

Also halten wir fest: Teuer, wenig und wenn dann oft veraltete Software verfügbar, langsam. Also der Anfang des Henne-Ei-Problems, so wird sich RISC-V nicht durchsetzen.

 

[TomH22]

@andi_sco: Erst mal vielen Dank für die Erwähnung meines Leserartikels. Ich war gestern und heute auf dem Weg in den Urlaub, und hatte unterwegs nicht viel Zeit auf die zahlreichen Reaktionen zu antworten.
Nun bin ich am Urlaubsort angekommen und es regnet sowieso, also Zeit ausführlicher zu antworten.

Zunächst nur ein paar zur Tabelle im Artikel:
Bei "Speicher" sollte beim VisionFive2 auch noch eMMC und M2 M-Key 2280 (allerdings auf 1xPCIe 2.0 beschränkt) stehen. Für dem eMMC Speicher gibt es einen Steckplatz, mitgeliefert wird keiner.
Bei Stromversorgung würde ich USB-PD max. 25W ergänzen, das ist einer der positiven Aspekte am VisionFive2.
Laut der offiziellen Ankündigung ist der JH-7110 ausßerdem in TSMC 28nm gerfertigt:
https://www.starfivetech.com/en/site/new_details/970

Die U74 Kerne von SiFive sind nicht sonderlich stark von der Rechenleistung her, soweit mir bekannt arbeiten diese die Befehle In-Order ab.

Ja genau, SiFive vergleicht sie auch mit einen Cortex-A53

Finde mal welche, die auf solchen skurrilen CPUs laufen

Wenn man sich die Mühe macht, sie selber zu übersetzen kann man auch SpecInt, etc. laufen lassen. Mir ging es bei dem Artikel darum, Benchmarks zu nutzen, die im Consumer Hardware Bereich verbreitet sind, sodass die Leser die Leistung einordnen können. JetStream hat außerdem wegen der Bedeutung von JavaScript für die alle web basierten Anwendungen auch eine praktische Relevanz.

So oder so, das Framework wäre wegen des Ökosystems und möglicherweise besseren Software-Unterstützung sicher die interessantere Option, auch wenn es teurer ist.

Auch das beste Ökosystem macht den Chip leider nicht schneller.

@Piktogramm, @mae:
Interessante Diskussion die ihr da führt. Ob mit aber dem zählen von Vektor/SIMD Befehlen im Code die Relevanz für die Performance beurteilen kann, weiß ich nicht. Oft sind nur relativ wenige Codestrecken in häufig ausgeführten Leaf-funktionen (also der unteren Ebene im Call Stack) für die Performance verantwortlich.

Ich kann selber nicht beurteilen wie relevant Vektor/SIMD, etc. für heutige Anwendungen sind, nur braucht z.B. AVX bei Intel/AMD CPUs ziemlich viel Fläche und Energie, und ich denke nicht, dass Hersteller diesen Aufwand zum Spaß treiben. Auf jeden Fall funktionieren z.B. in Microsoft Teams die Video Effekte (wie Background Blur) nur bei CPUs mit AVX. Die Frage ist ob Microsoft nur keine Lust hatte, eine Version ohne AVX zu entwickeln oder es wirklich nicht geht.

Grundsätzlich besteht ein zentraler Unterscheid zwischen Vektor Support in der CPU und GPU, dass die Auslagerung von Berechnungen an die GPU einen recht hohen Overhead hat. Es gibt daher sicher Anwendungsfälle wo die Nutzung der GPU sehr ineffektiv ist.

RVA23 macht Vektor und Hypervisor zur Pflicht weil beides als Voraussetzung für die Eignung von RISC-V für Datacenter und Desktop gilt.

 

[Piktogramm]

@TomH22
Ich habe deswegen ja zstd mit Debuginformationen gebaut und mit perf geschaut, welche Funktionen da CPU-Zeit brauchen. Bei Zstd ist es echt nicht wesentlich.

Was Audio und visuellen Multimediakram angeht, da ist Vektorisierung eigentlich immer nützlich. Aber es kann auch schlicht daran hängen, dass es kaum sinnvoll ist für Systeme zu entwickeln, die kein AVX2 beherrschen.

Edit:
Naja und es gibt durchaus Komprimierung, die von Vektorerweiterungen profitiert:
https://blog.centos.org/2023/05/high-performance-zlib-compression/

 

[Deinorius]

Auch das beste Ökosystem macht den Chip leider nicht schneller.

Es ging nicht um die Leistung. Das SBC ist ja auch in Ordnung, gerade, da es günstiger ist.
Mir, und @CDLABSRadonP... sicher auch, ging es um die zusätzlichen Anschlussmöglichkeiten bei Framework und auch Software-technisch würde ich mir mehr erwarten. Ich kann mich irren, aber die Hoffnung stirbt zuletzt.

 

[andi_sco]

Zunächst nur ein paar zur Tabelle im Artikel:

Habe zumindest den Wert auf 28 nm und 4,1 W geändert.
Der Rest ist der entsprechenden Herstellerwebseite entnommen.

 

[mae]

Ich kann selber nicht beurteilen wie relevant Vektor/SIMD, etc. für heutige Anwendungen sind, nur braucht z.B. AVX bei Intel/AMD CPUs ziemlich viel Fläche und Energie, und ich denke nicht, dass Hersteller diesen Aufwand zum Spaß treiben. Auf jeden Fall funktionieren z.B. in Microsoft Teams die Video Effekte (wie Background Blur) nur bei CPUs mit AVX. Die Frage ist ob Microsoft nur keine Lust hatte, eine Version ohne AVX zu entwickeln oder es wirklich nicht geht.

Das sind Operationen, wo mit vielen Daten, die in einem einfachen Array vorliegen, das gleiche gemacht wird. Das ist ideal fuer SIMD (single instruction, multiple data). Und fuer Anwendungen, die sowas machen, ist SIMD gut. Bei Compilern, die meistens mit Baeumen, Graphen, und anderen kompliziert strukturierten Daten arbeiten, ist mit SIMD wenig zu holen. Bei Kompression, wo man sich immer eine Reihe Bytes anschaut, und dann danach sucht, wie man das Codieren kann, ist da auch wenig zu holen; bei Dekompression umgekehrt. Bei AES-Encryption/Decryption braucht man einen Befehl, der AES-Sbox implementiert; der Befehl kann ein SIMD-Befehl sein, aber wenn der Befehl nicht vorhanden ist, nutzt der Rest von SIMD gar nichts (und wenn er vorhanden ist, werden auch nur wenige andere SIMD-Befehle gebraucht).

Ergänzung (1. September 2025)

Naja und es gibt durchaus Komprimierung, die von Vektorerweiterungen profitiert:
https://blog.centos.org/2023/05/high-performance-zlib-compression/

Interessant. Bei einem Benchmark 4.3-5.2% Speedup durch SSE2 und 16.1-16.2% durch AVX2, beim anderen 11.5-13.2% und 16-18.1%. Und da haben Experten von Intel mit der Hand Assemblercode geschrieben, um das herauszuholen. Wenn Zlib auf RVA23 laeuft, wird es wahrscheinlich nicht in diesen Genuss kommen. Daher bezweifle ich weiterhin, dass Dekompression auf RISC-V von SIMD profitiert.

 

[Schillicon]

Ganz schön risc-ant (badumm tss tss)
Danke für den tollen Beitrag! Sehr interessant

 

[TomH22]

Das sind Operationen, wo mit vielen Daten, die in einem einfachen Array vorliegen, das gleiche gemacht wird. Das ist ideal fuer SIMD (single instruction, multiple data). Und fuer Anwendungen, die sowas machen, ist SIMD gut.

Was SIMD und Vektor theoretisch machen ist mir schon klar, ich kann nur nicht einschätzen wie groß die praktische Relevanz in Real-World Anwendungen ist, also z.B. bei Video- und Audio Bearbeitung.

Also halten wir fest: Teuer, wenig und wenn dann oft veraltete Software verfügbar, langsam. Also der Anfang des Henne-Ei-Problems, so wird sich RISC-V nicht durchsetzen.

Nein, das stimmt so nicht.
Alle großen Linux Distributionen (z.B. Debian, Ubuntu, Fedora) haben kompletten RISC-V Support, d.h. mehr oder wenige alle im Repository der Distribution enthaltenen Programme sind für RISC-V compiliert verfügbar. Auch alle relevanten Compiler (wie z.B. auch Go oder Rust) können RISC-V Code erzeugen, auch die V8 Javascript Engine unterstützt RISC-V. Es werden z.B. auch alle USB und PCIe Geräte unterstützt, für die es open-source Treiber im Linux Mainline gibt.

Die Software ist auch up-to-date. Das Problem ist eher der Ansatz, den z.b. die Firma StarFive verfolgt. Man kann durchaus auch einen Kernel mit speziellen Anpassungen verwenden, und trotzdem ein aktuelles Userland bereitstellen - macht Raspberry mit seinem Raspberry OS auch.

Vielleicht ist durch meine Kritik an der Desktop Performance des VisionFive2 ein falscher Eindruck entstanden. Der JH-7110 ist kein schlechter SoC, die Performance liegt in der Größenordnung von In-Order ARMv8 Kerne und für viele Anwendungen abseits des Desktops ist die Leistung völlig ausreichend. Als Router/Firewall mit z.b. OpenWRT ist das VisionFive2 mit seinen zwei GBit Ethernet Schnittstellen eine durchaus geeignete Wahl.

Eigentlich ist das RISC-V Ecosystem erstaunlich weit, es gibt auch schon IP Cores wie diesen https://www.sifive.com/cores/performance-p800 , die wesentlich mehr leisten als der U74 von 2018.
Es muss jetzt nur noch jemand einen SoC mit diesen Cores bauen, und dafür sorgen, dass die notwendige Unterstützung in den Mainline Kernel einfliesst, dann wäre RISC-V "Ready for Desktop". Es ist jetzt nicht die Frage ob das passiert sondern nur wann.

Anderseits ist der Erfolg von RISC-V am Desktop nicht entscheidend für den Erfolg von RISC-V als Konzept. RISC-V ist ja kein CPU Design sondern eine offene Spezifikation. Schon jetzt gibt es mehr RISC-V Designs als für alle anderen ISAs. Laut RISC-V International gibt es weltweit über 13 Milliarden produltiv eingesetzte RISC-V Cores. Die sind heutzutage 99% Mikrocontroller Cores die ein allen möglichen Chips stecken.

Das ist so ähnlich wie beim Linux Kernel: Der Linux Kernel ist mit Abstand der meist eingesetzte Betriebsystemkern, er steckt in Milliarden von Geräten, den meisten sieht man es garnicht an, dass ein Linux drinsteckt. Der Desktop ist der einzige Anwendungsfall wo sich Linux bisher nicht durchsetzen konnte.

 

[mae]

Was SIMD und Vektor theoretisch machen ist mir schon klar, ich kann nur nicht einschätzen wie groß die praktische Relevanz in Real-World Anwendungen ist, also z.B. bei Video- und Audio Bearbeitung.

Das sind viele Daten, die gleichfoermig behandelt werden, da hilft SIMD oft viel. Aber der Teufel steckt im Detail. Einerseits sind das dann wieder Sachen, wo sich der Aufwand lohnt, es von der GPU machen zu lassen; wenn die CPU dann nur zuschaut, braucht sie dafuer keine SIMD-Befehle. Andererseits habe ich ueber eine Codierung (WIMRE H.264 gelesen), wo beim Dekodieren nach staendig irgendwelche Verzweigungen gemacht werden muessen. Da hilft SIMD dann beim Dekodieren wenig, und auch sonst laeuft das nicht gut auf einer CPU (branch mispredictions); da ist dann ein spezieller Hardware-Beschleuniger (nicht die GPU-Shaderkerne) zum Dekodieren angesagt (und auch nicht so leicht zu bauen).

 

[aid0nex]

Alle großen Linux Distributionen (z.B. Debian, Ubuntu, Fedora) haben kompletten RISC-V Support, d.h. mehr oder wenige alle im Repository der Distribution enthaltenen Programme sind für RISC-V compiliert verfügbar.

Die meisten Programme sind aber nicht für RISC-V verfügbar. Selbst bei ARM bekommst du schon Probleme. Die meiste Software wird nur für x86 kompiliert.

Der Desktop ist der einzige Anwendungsfall wo sich Linux bisher nicht durchsetzen konnte.

Das hat aber keine technischen sondern eher vertriebstechnische Hintergründe.