RISC-V bare metal servers now available at Scaleway
labs.scaleway.comWhile investigating the RISC-V ecosystem, we noticed that there isn't an easy way for developers to build and test their software on native hardware without buying it.
So we integrated custom RISC-V servers in our bare metal servers infrastructure and made them available to the public to enable the building, porting and testing of more native RISC-V software.
A 4 Cores TH1520 with 16 GiB of RAM and 128GB of eMMC is 15,99€/month.
Basically a $180 LicheePi 4A 16/128 (I have one), though apparently a custom board design.
The 4 eurocents per hour is attractive. What is the minimum number of hours? I see there is a 24 hour minimum on an Arm offering.
According to my tests, it's billed by the hour with no minimum commitment. It's attractive indeed for transient workloads. €15.99 for one month commitment sounds okay-ish when comparing with competitor's offering at this price (but you don't get RISC-V servers there (yet)).
This is an great deal for developers, if 0,042€/hour means per hour of compute. 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
Thank you, this gcc14 option looks really interesting. With the lack of hardware of this class supporting RVV 1.0, this will be useful.
btw, if my above reply felt a bit out of place, I though I was replying to the top level post.
From what I can gather, the 24h minimum is only in the Apple Silicon offering due to Apple policies that require it.
It is very nice to have cloud options. Just keep in mind this is an early preview.
It is not RVA22+V. It supports V but it's an incompatible older version, pre-ratification, 0.7.1.
With GCC trunk now (and soon 14.1) supporting 0.7.1 and furthermore supporting compiling the exact same RVV C intrinsics source code to either 0.7.1 or 1.0, this is not the obstacle it once was.
>With GCC trunk now (and soon 14.1) supporting 0.7.1
I missed this whole event. When/how did this happen?
See example here https://godbolt.org/z/va9sfEnMW