Scaleway launches RISC-V servers
labs.scaleway.com
labs.scaleway.com
042€/hour per hour of compute is a great deal for developers. If you tests with cross compilation and qemu anyways and sometimes needs test/benchmark on the native hardware, then this means you can spend about 5€ and you are probably set for months if not a year.
Also, with the latest gcc you can finally target rvv 0.7.1, which is supported by these CPUs. You just write your standardized rvv 1.0 intrinsics and if you add `-march=64gcxtheadvector` gcc 14 will just generate the equivalent rvv 0.7.1: https://godbolt.org/z/va9sfEnMW
It's pure FUD.
The x86 world somehow survives with MMX, SSE, SSE2, SSE3, SSE4, AVX, AVX2, AVX512. The Arm word has a few incompatible variants too, with VFP, a couple of variations of NEON, SVE, SVE2, MVE.
In comparison, RVV draft 0.7.1 and ratified 1.0 are practically the same thing.
With GCC 14 transparently compiling unmodified code using RVV C intrinsics to either 0.7.1 or 1.0 there is very little cost or reason not to support both.
RVV 0.7.1 is available in the vast majority of RISC-V SBCs in the world today, from the $5 Milk-V Duo (1.0 GHz C906, 64 MB RAM, 256M & 512M available for a few bucks more), to the ~$30 Lichee RV [dock] and MangoPi MQ Pro, to the $120-$180 Lichee Pi 4A, to the $2500 64 core Milk-V Pioneer.
With the sole exception of the CanMV-K230 (single core, 0.5 GB RAM), if a RISC-V board on sale today doesn't have RVV 0.7.1 then it doesn't have vectors at all.
it's wonderful news that gcc is able to paper over the compatibility problems now
btw possibly you should add a decimal point to your price
For 18 bucks USD I can get the same 100mb, 16mb and 4c/8t of core i5 hosted by OVH cloud (where I have so many upgrade paths it's laughable. I can, if I wish emulate my builds on x86 right here, at home, on my prox mox box or anywhere else I wish and not pay per hour of dev time.
As a small dev, the cost savings isnt there yet. I don't have good RISC-V options at home/office to do testing on.
That having been said, I want the few dev boards that are out there to come down from the 70dollar price point. I love what ESP32 ecosystem has coming out (P4? I think, it has zigbee). So if you have the spare 16 bucks a month, and the TIME to play this might be a good time to stick your toe in!
It's not about the highest performance or cheapest hosting if you don't care what you're using. It's for those who specifically want RISC-V hosting.
> ESP32-P4
Dual 400 MHz CPUs, less than 1 MB RAM.
If you are happy with things in that class, you don't need to pay any $70.
For $5 you can get Milk-V Duo dual 1000 MHz + 700 MHz with 64 MB RAM and run Linux on it.
You can compile C/asm code for the 700 MHz "microcontroller" core right there on the 1 GHz Linux core, if you want. Just put the bare metal binary in the right directory and reboot the 700 MHz core. Use the Arduino library to write your code, if you want, if twiddle the registers yourself.
I would still love a mini pc/ raspberry pi style form factor for testing things that are more "application" and less embedded. The "real network" and 4-8 cores where I can vet out high thread low volume tasks would be ideal. I can run this at home and "play" avoiding the rent seeking techno feudalism for an experiment!
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).
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.
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.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.
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!https://libera.irclog.whitequark.org/riscv/2024-02-02
The stress-ng benchmark was suggested the previous day.
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.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...
> 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.
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.
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.
On the site: no information.
FAQ: "You can order your Elastic Metal RV1 server directly on the order page"
click order page:
-> "create an account to view the page"
"I have a question, a problem, what can I do?
Like all Scaleway services, you can contact us officially via our support center, or informally via the Scaleway Community Slack."
click support center:
-> "create an account to view the page"
Scaleway Community Slack:
-> "your browser is not sanctioned by our strikt kompliance kommitat"
You know what, never mind.
No. No, actually there are plenty of people willing to take my money. Christ, it's far less of a hassle to get a crypto account opened on a decent exchange. I can't be the only one who just nopes out at stuff like this.
This is on top of the unactionable banner I have that tells me I have a pending contract (I have no pending contract, and no reason I would have one). Okay Scaleway, I get it, I'll move on.
It's maybe almost too early, given the performance profile of these and the current state of software compat, but the trajectory is definitely there for RISC-V. Wouldn't be surprised to see these compete strongly against ARM servers a few years from now.
Of course, that excuse could be true for customers too.
If you're going to run your stuff on them on aarch64 Linux in docker anyway you wont notice any difference (except speed and price) between Mac and Ampere running Linux.
I see they list 3 officially supported GNU/Linux distros: Debian, Ubuntu, Alpine. I wonder how mature these are on RISC-V at this point and whether they're ready for production server usage.
Linux is Linux. It's hard to go wrong when you're not mucking about with graphics cards and first-person games and things like that.
Python 'pip' packages, which often have native code dependencies, may also lack official RISC-V builds.
It's a lot lower barrier to entry than buying the equivalent board outright for $180.
You can also just do `docker run -it riscv64/ubuntu` on your x86 or Mac, at zero incremental cost.
When I ask people what it will take to get RISC-V into stable releases the answer is always ‘better access to test hardware’. Hopefully this is a step along the way.
I haven't tried it -- I installed the VF2 Debian fork in April 2023 or so, then switched to SID, and I'm still on that. I think Ubuntu 24.10 will have a lot better support; mainline support for the VF2/JH7110 is almost complete for 6.6: https://rvspace.org/en/project/JH7110_Upstream_Plan
I have an old atom-based kimsufi by ovh, cryptography will eat almost a full core when doing file transfer over ssh or any kind of https…
No cryptographic hardware acceleration could really be the Achilles’ tendon for this platform.
The RISC-V standard has extensions for both scalar and vector cryptography instructions but yet only a few cores out there support one or the other. Look out for CPUs based on the SiFive P670 which should have the latter. When Android smartphones with RISC-V show up, they will also have vector cryptography.
Announced in July 2019, it is one of the most recent RISC-V cores you can buy. Hardware takes time, usually 3-4 years to go from announcement of a core to an SBC you can buy.
The C910 is the only RISC-V core you can buy in an SoC with 64 of them (Milk-V Pioneer)
The only newer core you can buy is the C908, available only in the K230 SoC on the CanMV-K230 board. It had some advantages (it's the only board rn with Vector 1.0), but it also has the HUGE disadvantages of being single core and only 0.5 GB RAM, vs quad core and 16 GB RAM on this cloud offering.
> Look out for CPUs based on the SiFive P670
This is not available. The first boards are expected late this year.
It will be a huge advance, certainly, with twice the speed per core, and the first SoC SG2380 with it having 16 cores.
But not today.
for the genral assembly there isn't mutch to learn tbh, look at the isa reference card and maybe also look at the B (bit manipulation) extension: https://www.cl.cam.ac.uk/teaching/1617/ECAD+Arch/files/docs/...
---
Here are some resources on RVV I can recommend:
RVV spec (also look at the examples in the repo): https://github.com/riscv/riscv-v-spec/blob/master/v-spec.ado...
RVV intrinsics viewer: https://dzaima.github.io/intrinsics-viewer
Tutorial: RISC-V Vector Extension Demystified (3 hour video going over every instruction): https://youtu.be/oTaOd8qr53U
RISC-V Vector extension in a nutshell: https://fprox.substack.com/p/risc-v-vector-extension-in-a-nu...
If you want to see a more complex example/real world application, then you might also be interested in my article about vectorizing unicode conversions: https://camel-cdr.github.io/rvv-bench-results/articles/vecto...
In terms of development I'd recommend using qemu and a cross compiler, or if you want hardware try to get the kendryte k230 (currently the only sbc with rvv 1.0 support) or wait a bit for better hardware (BPI-F3 and sg2380 should release this year).
specifically i installed gcc-riscv64-linux-gnu and qemu-user-binfmt
also i read the risc-v spec and assembly programming manual
i also got some risc-v single-board computers but haven't done anything with them yet
i haven't been doing anything with the v extension, which i think is the most widely supported simd-like extension; though it's not exactly simd, it offers the same kinds of benefits for the same kinds of applications
The assembler accepts either syntax:
user@starfive:~$ echo add a0,a0,13 \; addi a1,a1,420 | as
user@starfive:~$ objdump -d a.out
a.out: file format elf64-littleriscv
Disassembly of section .text:
0000000000000000 <.text>:
0: 00d50513 add a0,a0,13
4: 1a458593 add a1,a1,420
Also, objdump will print them as `addi` if you give the `-Mno-aliases` option.thanks for the tip about no-aliases! i had no idea. i don't suppose there's an option to allow me to write arm-ual-style `add a1, a0` instead of `c.add a1, a0` or `add a1, a1, a0`, is there? because in the first case i can't assemble it without rvc, and the second case is annoying
i guess i should write my own assembler instead of whining
https://riscv.org/technical/specifications/
riscv64 Linux syscall numbers are the same as arm64 ones. Just put the syscall number into `a7` instead of `x8`. And args in `a0`..`a3`, obv. Use `ecall` instead of `svc 0`. Boom!
- SoC T-Head 1520 CPU (C910) RV64IMAFDCV0P7_Zicsr_Zifencei_Zfh_XTheadc 4 cores 1.85 GHz (though i think the v extension on the c910 is the pre-ratification 0.7.1 v extension; see https://news.ycombinator.com/item?id=39585519 for more detail)
- 128 GB eMMC
- Debian, Ubuntu, Alpine
- between 0.96W and 1.9W per 1.8GHz core
- €15.99/month or €0.042/hour
The real sell of this hardware is that it's doing this with about 5W of power draw at peak utilisation.
minimal pre-build images ...
You can run your RISC-V images transparently on your x86 or Arm (e.g. Apple) machines, as docker desktop automatically uses QEMU. Or run them natively in docker on your RISC-V board.
Minimal starter image: riscv64/ubuntu
Name CPU RAM Storage Ethernet Network Price excl. VAT/hour Price excl. VAT/month
EM-RV1-C4M16S128-A 4xC910 RISC-V 64GCV 1.85GHZ 16 GB 128 GB 100 Mb/s 0,042€ 15,99€But if we packing low power servers this densely we might not need to.