Scaleway launches RISC-V servers(labs.scaleway.com)
labs.scaleway.com
Scaleway launches RISC-V servers
https://labs.scaleway.com/en/em-rv1/
87 comments
We probably want to encourage people to forget pre 1.0 vectors exists, to ease ecosystem fragmentation
That's what the SiFive mafia have been trying to get people to do, for the three years since Nezha arrived with RVV 0.7.1, while they (still!) have zero RVV hardware available for the end user to buy.
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 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.
Deciding what to do about the version split seems tricky, but on the plus side, it's impressive that they implemented a lot of real hardware before they even froze the extension.
not really. standards consortia are notoriously sluggish and chinese hardware companies are famously agile
i think the vast majority of risc-v sbcs in the world today don't support any v extension at all, yeah
it's wonderful news that gcc is able to paper over the compatibility problems now
it's wonderful news that gcc is able to paper over the compatibility problems now
that's fantastic news about gcc
btw possibly you should add a decimal point to your price
btw possibly you should add a decimal point to your price
For me, the price is 15.99 euros.
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!
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!
> For 18 bucks USD I can get the same 100mb, 16mb and 4c/8t of core i5
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.
https://arace.tech/products/milk-v-duo
https://github.com/milkv-duo/duo-arduino/releases
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.
https://arace.tech/products/milk-v-duo
https://github.com/milkv-duo/duo-arduino/releases
Thanks for the link to the milk-V that looks amazing.
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 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!
TH1520 with the XuanTie C910 core. Avoid. That particular platform is really incredibly slow, Cortex-A5x level. And with RVV 0.7.1 instead of 1.0 too.
> 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...
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...
> 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.
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.
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.
> 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.
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.
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.
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.
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:
My expectation is that it would beat my i9-13900HX laptop (24 cores) running riscv64/ubuntu in docker (QEMU) which took 1:42.
real 422m41.367s
user 1430m56.638s
sys 70m17.994s
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
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
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.Can you expand on why it sucks?
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).
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.
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
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
real 422m41.367s
user 1430m56.638s
sys 70m17.994s
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)
I wonder what payment methods they accept.
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.
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.
Credit cards and SEPA at a minimum.
We added an FAQ question (https://labs.scaleway.com/en/em-rv1/#i-have-a-question) with a link to the Elastic Metal documentation where you can find the payment methods.
And they use Jumio. Instantly noped out after doing a number of other steps to get my account going. I have to verify bank deposits, and upload my ID through that piece of shit Jumio? The brilliant product built by people incapable of understanding that just letting me upload my gd damn ID is easier than trying to get me to complete the flow on my phone.
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.
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.
Scaleway was also early in providing Arm servers, it's cool to see them keep bringing new stuff
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.
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.
This one is probably more for Scaleway to gain experience than for customers to use seriously.
Of course, that excuse could be true for customers too.
Of course, that excuse could be true for customers too.
The performance is about the same as the first Graviton servers in late 2018.
Do they still offer ARM? I remember them killing the ARM bare metal back in the day.
Still seem to offer ampere based vcpus
https://labs.scaleway.com/en/amp2-instances/
https://labs.scaleway.com/en/amp2-instances/
They are discontinued as of the end of January 2024. (See the FAQ section). Their only ARM appears to be Cost Optimized Arm: https://www.scaleway.com/en/cost-optimized-instances-based-o...
.. and the Mac Mini M1/M2/M2 Pro.
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.
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.
Aren't speed and price the two primary metrics of a server?
eMMC for cloud seems to me like a dangerous proposition. As far as I know, they do not hold up well to write intensive workloads. I suppose you will need to use networked logging.
Interesting step, their claim of world's first RISC-V servers available in the cloud is true as far as I know.
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.
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.
Nitpick: Alpine is a Linux distro, but not a GNU/Linux distro; it uses musl libc and busybox coreutils.
This is the first time I've seen the correction go the other way.
Android and ChromeOS are also Linux distributions without GNU.
ChromeOS is glibc based.
Stand corrected, although little else from GNU is exposed to userspace.
[deleted]
Or as I've recently taken to calling it, BusyBox plus Linux.
Interesting, thanks.
Much more ready for server usage than desktop 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.
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.
For server workloads there can still be plenty of non-trivial architecture-specific dependencies besides the core OS itself, such as the JVM and other JIT-based interpreters.
Python 'pip' packages, which often have native code dependencies, may also lack official RISC-V builds.
Python 'pip' packages, which often have native code dependencies, may also lack official RISC-V builds.
You should be able to use QEMU user-level emulation to run binaries from other architectures on a RISC-V system, while using native code for the rest. Alternately if the code is available and reasonably clean, you could try a RISC-V build yourself. (Obviously not for the JVM and other JIT-dependent stuff - though these ports are ongoing too - but for most smaller projects it should work fine.)
Access to servers such as these, for pennies per hour, will accelerate authors of those packages porting them to RISC-V.
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.
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.
Debian support for RISC-V is presently only in Sid (testing release). So not production ready.
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.
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.
Ubuntu (server) is a lot closer. For example, see the limitations at the end of https://wiki.ubuntu.com/RISC-V/StarFive%20VisionFive%202
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 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
Doe these cpus have any cryptographic hardware acceleration? They list gpus and npus only.
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.
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 T-Head C910: no. It is considered a bit of an old core by now. It is open source so it has been adopted a lot.
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.
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.
> T-Head C910: no. It is considered a bit of an old core by now
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.
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.
What's the recommended way to learn RISC-V assembly (including SIMD)? For ARM I just found a book I liked and did the exercises on my Mac M1 (replacing system call numbers etc and changing page sizes).
If you're already familiar with arm64 assembly language then just read the RISC-V ISA manual. It's short and simple.
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!
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!
i'm probably not a good person to give advice on this, but what i've been doing is installing the cross-compilation gcc environment under debian and qemu-user. this allows me to build statically linked executables and run them as if they were native executables, and also to disassemble the executables and object files with riscv64-linux-gnu-objdump (though it produces incorrect output for instructions like addi and slli, it's good enough to see what's going on)
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
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
> riscv64-linux-gnu-objdump (though it produces incorrect output for instructions like addi and slli
The assembler accepts either syntax:
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
yeah, i know it accepts it, but that doesn't make it right ;)
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
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
Edit: sorry I missread, I though you were just interested in the vector extension (SIMD)
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).
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).
probably the things that will be most interesting to people:
- 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
- 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
[deleted]
Great option to use as a CI server / job runner if one has a project targeting RISC-V. Of course one could use emulation or put a CI runner on some board in a closet somewhere. But cloud image is convenient, so it is nice to be able to do this now, just as on x86 and ARM.
100 Mbit/s NIC? Seems a bit thin.
For 4 cores and 16GB of RAM? not really. That's probably close to saturation for the hardware for most workloads other than raw data streaming.
The real sell of this hardware is that it's doing this with about 5W of power draw at peak utilisation.
The real sell of this hardware is that it's doing this with about 5W of power draw at peak utilisation.
great for code, terrible for lots of data. maybe not trendy but neither is it fatal?
> We are committed to providing you with the best possible experience, but please note that the artisanal design and the youth of RISC-V processor architectures do not allow us to guarantee a specific level of service, resulting in an SLA of 0%.
This looks interesting, I have been meaning to try RISC-V outside of an emulated environment. I have a visionfive board on my desk but gave up trying to figure out how to flash a production OS. There was some shady version of Fedora they offer but I prefer to flash my own via buildroot or yocto.
These guys are unbelievable. They were the first to provide ARM servers (non-virtual, if I remember correctly), and now this. I hope they are benefitting from those innovations.
Does Docker work with RISC-V?
I works great (with the usual requirement of having the expected kernel options/modules enabled). The main issue right now is the lack of image support for RISC-V. I hope this is going to change if hardware starts becoming accessible.
It absolutely does. I use it every day.
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
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
Yes. I’ve been running it on a VisionFive 2 and a BeagleV-Ahead.
https://hub.docker.com/u/riscv64
minimal pre-build images ...
minimal pre-build images ...
I couldn't find the value, but how much are they charging per month for these boxes? I see they have 4 CPU cores and 16gb of RAM.
Can we ditch virtual machines if we are packing 672 servers per rack?
These aren't VMs?
One of the main points of VMs is to subdivide servers.
But if we packing low power servers this densely we might not need to.
But if we packing low power servers this densely we might not need to.
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