[HN Gopher] Scaleway launches RISC-V servers
___________________________________________________________________
Scaleway launches RISC-V servers
Author : enz
Score : 70 points
Date : 2024-03-03 11:01 UTC (11 hours ago)
(HTM) web link (labs.scaleway.com)
(TXT) w3m dump (labs.scaleway.com)
| MaxBarraclough wrote:
| 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.
| brucehoult wrote:
| 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.
| MaxBarraclough wrote:
| 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.
| brucehoult wrote:
| 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.
| yjftsjthsd-h wrote:
| Nitpick: Alpine is a Linux distro, but not a GNU/Linux distro;
| it uses musl libc and busybox coreutils.
| williadc wrote:
| This is the first time I've seen the correction go the other
| way.
| MaxBarraclough wrote:
| Interesting, thanks.
| arcanemachiner wrote:
| Or as I've recently taken to calling it, BusyBox plus Linux.
| cpswan wrote:
| 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.
| my123 wrote:
| 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.
| nevi-me wrote:
| 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).
| b9b10eb736 wrote:
| 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.
| brucehoult wrote:
| 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.
| b9b10eb736 wrote:
| 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!
| camel-cdr wrote:
| 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)
| drmpeg wrote:
| 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.
| my123 wrote:
| It's not just about a given microbenchmark - that platform
| just sucks tbh. Hopefully something better appears.
| drmpeg wrote:
| Real world performance reported: glibc build on Unmatched
| ~7:30, on Pioneer ~16:20 hours.
| brucehoult wrote:
| > 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...
| b9b10eb736 wrote:
| 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.
| Kab1r wrote:
| 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.
| tux3 wrote:
| 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.
| crq-yml wrote:
| 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.
| brucehoult wrote:
| The performance is about the same as the first Graviton
| servers in late 2018.
| Hamuko wrote:
| Do they still offer ARM? I remember them killing the ARM bare
| metal back in the day.
| tempest_ wrote:
| Still seem to offer ampere based vcpus
|
| https://labs.scaleway.com/en/amp2-instances/
| c0balt wrote:
| 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...
| freeqaz wrote:
| 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.
| tyingq wrote:
| 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,042EUR 15,99EUR
| mikmak wrote:
| just click the link => 15.99EUR per month or 0.042EUR per hour
| theanonymousone wrote:
| Does Docker work with RISC-V?
| cpswan wrote:
| Yes. I've been running it on a VisionFive 2 and a BeagleV-
| Ahead.
| pella wrote:
| https://hub.docker.com/u/riscv64
|
| minimal pre-build images ...
| brucehoult wrote:
| 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
| b9b10eb736 wrote:
| 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.
| fodkodrasz wrote:
| 100 Mbit/s NIC? Seems a bit thin.
| mistrial9 wrote:
| great for code, terrible for lots of data. maybe not trendy but
| neither is it fatal?
| jacoblambda wrote:
| 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.
| znpy wrote:
| 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.
| Findecanor wrote:
| 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.
| brucehoult wrote:
| > 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.
| camel-cdr wrote:
| I'll reiterate what I wrote before:
|
| 042EUR/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 5EUR 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
| justahuman74 wrote:
| We probably want to encourage people to forget pre 1.0 vectors
| exists, to ease ecosystem fragmentation
___________________________________________________________________
(page generated 2024-03-03 23:01 UTC)