Benchmarking the First RISC-V Cloud Server: Scaleway EM-RV1 Performance | Hacker News Reader

Benchmarking the First RISC-V Cloud Server: Scaleway EM-RV1 Performance

phoronix.com

13 pointsmy1237 comments

Here is the conclusion from the article: "Across 71 benchmarks ran across all three Scaleway Elastic Metal instance types, the EM-RV1 was much slower than even the aging Intel and AMD x86_64 instances. The EM-A315X that is using a 10 year old Ivy Bridge Xeon with 4 cores was around 7.4x the performance of this RISC-V cloud server. Or the half-decade old Ryzen 5 PRO 3600 within the EM-A210R instance was 18.3x the performance of the EM-RV1. Comparing to the very latest Intel and AMD CPUs would be even more mind-boggling advantages for latest x86_64 performance over RISC-V. See all the benchmarks in full here.

The Scaleway Labs EM-RV1 is interesting for a number of reasons as noted and a great way to dabble with RISC-V cheaply in the cloud, but do so with realistic performance expectations."

Basically, the reviewed RISC-V chip is not competitive because it is a about seven times slower than a 10 year old Intel chips. My guess is its performance per WATT is lower than current chips from AMD, Intel, and ARM.

I don't know why they pay so much attention to when things were made, and no attention to the microarchitecture, which they so often like to analyse.

The EM-RV1 (which is made up of Sipeed LicheePi 4A Clusters) uses 1.85 GHz THead C910 cores, with similar uarch to the Arm A72 (used in the first Amazon Graviton servers) or to something maybe early low end Core 2 e.g. in the first MacBook Air.

OF COURSE if all you want is the maximum performance and the ISA doesn't matter then you're much better off using something else for now.

But if you specifically want run RISC-V code, for example to get your software ready for the coming much faster RISC-V machines, then this is a good way to do it, without having to spend $180 up front for the equivalent SBC.

RISC-V machines with cores 1.3x faster will be out in a few months, and 2x faster around the end of the year. By around 2026 there will be RISC-V around Zen2 or Apple M1 performance. This is all in the pipeline.

> But if you specifically want run RISC-V code, for example to get your software ready for the coming much faster RISC-V machines, then this is a good way to do it, without having to spend $180 up front for the equivalent SBC.

If that's all you're using it for, isn't qemu good enough?

> RISC-V machines with cores 1.3x faster will be out in a few months, and 2x faster around the end of the year. By around 2016 there will be RISC-V around Zen2 or Apple M1 performance. This is all in the pipeline.

That's a great argument for prepping your software now, but also for not buying anything now. Like, textbook https://en.wikipedia.org/wiki/Osborne_effect

> If that's all you're using it for, isn't qemu good enough?

You can never quite be sure qemu correctly represents real hardware. There have been a number of cases where qemu was more permissive and programs developed on it didn't work on real hardware. The emphasis is on running valid code, not catching invalid code.

Qemu-user on recent PCs is a bit faster than this board for long-running scalar programs with a small amount of code e.g. my primes benchmark:

     5.052 sec i9-13900HX, qemu-riscv64 @ 5.1 GHz
    10.430 sec Sipeed LM4A TH1520 4x C910 @1.848 GHz

https://hoult.org/primes.txt

However, this changes if you run a lot of short programs in quick succession (as e.g. autoconf does) as you get dominated by JIT time. Or if you run full-system emulation using qemu-system, which gets hit by MMU emulation on every load/store.

Also, this CPU core implements draft 0.7.1 of the RISC-V Vector spec with 256 bit ALU. Qemu emulates such SIMD code element by element, which is far slower than real hardware. NB there are significant differences between draft 0.7.1 and the final Vector 1.0, but the style is the same, most code doesn't hit the differences, and some code (e.g. memcpy/move/cmp, strcpy/cmp/len) is even binary compatible. Moreover, if you write code using the C intrinsics for the vector instructions then the newly-released GCC 14 can generate code for either 0.7.1 (as "XTHeadVector") or 1.0 from exactly the same source code with just a compiler flags change.

> Osborne effect

I was at university at the time. Osborne computers cost as much as a new car. RISC-V SBCs in this class cost as much as a dinner date.

That makes a HUGE difference to people's willingness to buy something to throw away after a year.

All the more so as the engineer using it is probably on a salary sufficient to earn enough to pay for one before morning tea.

This is relatively boring, as machines with this CPU core have been available for years.

Looking forward to something new. BPI-F3 ships this month with a 8 core CPU that implements RVA22 and RVV 1.0.

Milk-V Oasis ships later this year with 16x SiFive P670, which are comparable to Cortex-A77, and thus faster than any ARM SBC that can be bought right now.

They'll be exciting to look at.

> machines with this CPU core have been available for years

Not true. The first volume-produced (reasonably priced) board with the C910 core was the LicheePi 4A. My pre-ordered $119 quad core board arrived on June 6, which is still less than one year ago. The Lichee Cluster 4A used here shipped in September.

Until the BPI-F3 shipped this month it was the newest core available in a multi-core SBC. Sadly so far the BPI-F3 ships only with a paltry 4 GB RAM, not the 16 GB people hoped for (and that the LicheePi has), making it useless for many development jobs, especially if you want to use all 8 cores.

Got them confused. C906 shipped ages ago. C910 was first available for general public in LM4A which is indeed recent relatively speaking.

I agree 4GB makes that Banana Pi board useless. I am hopeful for other boards with the same SoC or a future variant with at least 16GB.

We won't be getting very far with make -j8 with just 4GB.

Reply on news.ycombinator.com