Note the benchmark is not very rigorous, but it reflects what we want to do with these boards which is to build Fedora packages.
This P550 seems like the first "fast" RISC-V CPU actually available.
But most packages don't have as solid (or any) cross-build infrastructure as those projects.
I did some benchmarks on RISC-V Linux kernel builds (commit 7503345ac5f5, defconfig) this week. Native on SBCs, cross-build on a couple of x86, docker (qemu-user) on x86.
- 1m45s i9-13900HX cross-compile
- 4m29s Milk-V Pioneer (youtube video from 9 months ago .. close enough)
- 10m10s Ryzen 5 4500U (6 cores, Zen2) laptop cross-compile
- 22m48s RISC-V docker on 24 core i9-13900HX laptop
- 67m35s VisionFive 2 (4x U74)
- 88m4s Lichee Pi 4A (4x C910)
I need a figure for SpacemiT in BPI-F3 / Jupiter / LPi3A / DC-Roma II / MuseBook. I think it'll be more or less the same as the VF2.
My guess is the Milk-V Megrez (EIC7700X @1.8 GHz) might come in around 25 minutes, and this HiFive Premier (same Soc @1.4 GHz) 30 minutes.
So the P550 machines will probably be a little slower than qemu on the i9. Not a lot. But even the VF2 and LPi4A are going to be much faster than qemu on that 6 core Zen2 -- I haven't measured it, but I'm guessing around 130m.
So if you already have that high core count x86, maybe you don't need a P550 machine.
On the other hand it's good to verify on real hardware.
On the gripping hand, with a 16 GB Megrez costing $199 and my i9 costing $1600, if you want a build farm with 5 or 10 or 100 machines then the P550 is looking pretty good.
VF2 (or Mars) is still looking pretty good for price/performance. The problem there is that being limited to 8 GB RAM isn't good. That's not enough for example to do riscv-gnu-toolchain without swapping. That build is fine on my 16 GB LPi4A, but not my VF2.
16 GB or 32 GB on the P550 boards is much more robust.
- 70m57s Lichee Pi 3A (8x SpacemiT x60 @1.6 GHz)
5% slower than the VisionFive 2, despite the extra cores.
Apparently the small level 2 caches on the X60 are crippling.
The P550 actually feels "snappy".
That's a lot for the same SoC.
And, yes, ridiculously small caches on the BPI-F3 at 0.5 MB for each 4 core cluster, vs 2 MB on the VisionFive 2 and 4 MB on the P550.
The Pioneer still wins for cache and I think real-world speed though, with 4 MB L3 cache per 4 core cluster, but also access to the other 60 MB of L3 cache from the other clusters on the (near) single-threaded parts of your builds (autoconf, linking, that last stubborn .cpp, ...)
I just checked the Linux kernel tree I was testing with. It's 7.2 GB, but 5.6 GB of that is `.git`, which isn't used by the build. So only 1.6 GB of actual source. And much of that isn't used by any given build. Not least the 150 MB of `arch` that isn't in `arch/riscv` (which is 27 MB). Over 1 GB is in `drivers`.
riscv-gnu-toolchain has 2.1 GB that isn't in `.git`. Binutils is 488 MB, gcc 1096 MB.
This is all small enough that on an 8 GB or 16 GB board there is going to be essentially zero disk traffic. Even if the disk cache doesn't start off hot, reading less than 2 GB of stuff into disk cache over the course of a 1 hour build? It's like 0.5 MB/s, about 1% of what even an SD card will do.
It just simply doesn't matter.
Edit: checking SD card speed on Linux kernel build directory on VisionFive 2 with totally cold disk cache just after a reboot.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Dec 10 07:39:01 2024 from 192.168.1.85
user@starfive:~$ time tar cf - linux/* | cat >/dev/null
real 2m37.013s
user 0m2.812s
sys 0m27.398s
user@starfive:~$ du -hs linux
7.3G linux
user@starfive:~$ du -hs linux/.git
5.6G linux/.git
user@starfive:~$ time tar cf - linux/* | cat >/dev/null
real 0m7.104s
user 0m1.120s
sys 0m8.939s
I'm having trouble seeing how NVMe vs SATA can make any difference, when SD card is already 25x faster than needed.
I'm not familiar with the grub build at all. Is it really big?
omg. I didn't notice that before.
The two tests were run on DIFFERENT MACHINES by different people.
NVMe result is 28.9% faster than SATA result.
1.8 GHz EIC7700X (e.g. Milk-V Megrez) is 28.6% faster than 1.4 GHz EIC7700X (HiFive Premier)
Mystery explained?
Try on an SD card ... I bet you don't see a significant difference.
In any case, I actually want to use RISC-V machines for my development environment.
For quite some time to come, the main user of the Fedora riscv64 port will be the Fedora riscv64 builders. With cross-compilation, we wouldn't even have that limited use of the binaries produced.
Doing "native" build in an emulator works for just about everything, but with a 10x - 15x slowdown compared to native or cross-build.
While price/performance of RISC-V is currently significantly worse than x86, it's not 10x worse.
A $2500 Milk-V Pioneer (64 cores, 128 GB RAM) builds a RISC-V Linux kernel five times faster than a $1500 x86 laptop (24 cores) using RISC-V docker/qemu.
A $75 VisionFive 2 or BPI-F3 takes 3 times longer than the x86 with qemu but costs 20 times less.
If you're only building one thing at a time and already have the fast x86 ... then, sure, use that. But if you want a build farm then RISC-V native on either the Pioneer or the VF2 is already much better.
These P550 machines are an incremental improvement again, in price/performance.
For more numbers see: