On the RISC-V IRC channel, it was shown that there was some bug with the Milk-V Pioneer processor, which is a C920 core. I'm not sure if the C910 has the same issue. The super slow benchmark was:

stress-ng --verbose --metrics --aggressive --atomic 64 --timeout 600

If you try this, adjust the number (64) to match the number of cores on your system.

It's not just about a given microbenchmark - that platform just sucks tbh. Hopefully something better appears.

Can you expand on why it sucks?

Real world performance reported: glibc build on Unmatched ~7:30, on Pioneer ~16:20 hours.

I don't have a Pioneer (I wish!) but I just yesterday compiled GCC head (14.0.1) on my 16GB LicheePi 4A (same cores as the Pioneer, but only 4 instead of 64) and it took just under 7:03 in your notation:

    real    422m41.367s
    user    1430m56.638s
    sys     70m17.994s

It's hard to believe the Pioneer with 16x as many cores and a slightly higher clock speed and 128GB RAM and NVMe SSD vs eMMC would be slower.

My expectation is that it would beat my i9-13900HX laptop (24 cores) running riscv64/ubuntu in docker (QEMU) which took 1:42.

    real    101m44.472s
    user    1695m26.395s
    sys     24m36.671s

Note: newlib build, not glibc. But still!

The glibc times were reported on the RISC-V IRC channel by davidlt. Here's the backlog for that day.

https://libera.irclog.whitequark.org/riscv/2024-02-02

The stress-ng benchmark was suggested the previous day.

https://libera.irclog.whitequark.org/riscv/2024-02-01

Who knows what he did? There are opposite experiences cited in that same log:

    19:03 <xypron> Concerning Pioneerbox vs Unmatched: My experience with building Ubuntu'g glibc was 7 h on Pioneer box vs 3.5 days on Unmatched.

I was going to try the server out until I saw this comment. Which alternative board/computer would you recommend one buy?

I'm learning RISC-V assembly with a friend, it'd be great for us to have a machine to tinker with (we'll use ESP-32-Cx for 32-bit).

Still way better than a VisionFive 2, and more than enough to get your hands in the thing (especially with the hourly pricing). You have to acknowledge that the RISC-V ecosystem isn't as mature as that of ARM64 and AMD64. You don't get the best performance/price ratio with RISC-V (yet). Many extensions were ratified so recently that hardware doesn't even exist (yet).

As far as I'm concerned, the LicheePi 4A from Sipeed which is also equipped with a TH1520 offers a decent value for a RISC-V SBC. If you want more performance than that, it's going to cost you a lot more.

Right now, you can't get more performance than the TH1520 (C910 cores) and JH7110 (U74 cores) at ANY price. The only thing you can do is get more of the same cores i.e. SG2042 with 64x C910 cores.

The same goes for emulation. QEMU on my i9-13900HX laptop is about the same speed on each core, but there I have 24 cores (32 threads).

I just compiled gcc 14 natively on both LicheePi 4A (the same as this hosting) and docker/QEMU:

i9-13900HX (8 P + 16 E cores) docker running riscv64/ubuntu image

    real    101m44.472s
    user    1695m26.395s
    sys     24m36.671s

LicheePi 4A (TH1520 SoC, 4x C910 cores)

    real    422m41.367s
    user    1430m56.638s
    sys     70m17.994s

The LicheePi actually used less CPU time, but the i9 won with more cores.

Thanks for the clarification, you're completely right. I didn't realize the SG2042 used the same core. So, Scaleway's offer really does seem to make sense!

Thank you all, yes it makes sense to use this as the cost is great for say 3 months worth of tinkering.

Arguably OpenXiangShan should be more powerful, but verilog simulation isn't really that usable in practice, and it has no working vector support yet. (the dev branch currently hangs after a few minutes of simulating)

> Avoid. That particular platform is really incredibly slow, Cortex-A5x level.

If you avoid it then you won't be using RISC-V at all, right now.

Along with the JH7110, it is the fastest RISC-V CPU you can buy off the shelf today. That will probably change late in this year, but for now you can't do significantly better.

Overall the two (and the SG2042, same cores as the TH1520 but 64 of them, plus L3 cache) are very similar in speed. The C910 can be 30% to 50% faster on some microbenchmarks. The JH7110 is usually about 10% faster on system level real world tasks e.g. building software. Not enough to notice unless you sit both side by side.

> And with RVV 0.7.1 instead of 1.0 too

Which matters much less than it used to, as gcc 14 can compile C code with RVV intrinsics to either.

Just today I took someone's RVV 1.0 test code, which they'd only been able to run on simulators, and compiled it and ran it on my TH1520 LicheePi 4A, with only Makefile changes (`-march=rv64gc_xtheadvector` instead of `-march=rv64gcv`).

https://www.reddit.com/r/RISCV/comments/1b57gib/comment/kt4t...

Fully agreed.

> The JH7110 is usually about 10% faster on system level real world tasks e.g. building software.

Pretty sure the U74 CPU from the JH7110 is way worse than the C910 from the TH1520 on pretty much all aspects. So my guess is that your metric is mostly explained by the fact that the JH7110 has a PCIe bus which allows plugging in an SSD rather than an eMMC or SD Card. But such SSD also has a cost. I think this gives some perspectives.

It's not a "metric" it's real-world use. Whatever the causes, the CPU core is not the only component in an overall system.

I use both of these boards every day. Constantly, as it's my work.

Building my RVV 0.7.1 gcc 9.2 snapshot takes 111 min on the U74 VisionFive 2, 122 minutes on the C910 LicheePi 4A.

Running DotNET "LINQ" test suite takes 4m30s on VisionFive 2, 5m30s on LicheePi 4A.

Doing `emacs --eval '(kill-emacs)' hello.c` takes 0.72s on VisionFive 2, 0.75s on LicheePi 4A. Close, but the C910 does not win.

Yes, the C910 significantly beats the U74 on every micro-benchmark. Dhrystone, coremark, my "primes" test https://hoult.org/primes.txt, memcpy...

https://hoult.org/TH1520_memcpy.txt

https://hoult.org/JH7110_memcpy.txt

It doesn't translate to the real world, at least in the TH1520 SoC, on the LicheePi 4A sbc.

> If you avoid it then you won't be using RISC-V at all, right now.

I'm sorry this just isn't true. The K230 has RVV 1.0 hardware and has been available for 5 months.

> Which matters much less than it used to, as gcc 14 can compile C code with RVV intrinsics to either.

This is still a huge problem for fragmentation. Multimedia libraries in FFmpeg and VideoLAN use hand written assembly and only support standards compliant RVV 1.0.

There is no reason to ever produce a binary for RVV 0.7.1, it will simply fail if run on standards compliant hardware.