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
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.
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.
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.
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!
> 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`).
> 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.
> 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.
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:
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.
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!
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)
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.
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.
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.
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.
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.
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.)
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.
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
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.
> 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.
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).
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
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
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)
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.
> 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.
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.
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.
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