4 ms·
I don't know why they pay so much attention to when things were made, and no attention to the microarchitecture, which they so often like to analyse. The EM-RV
by brucehoult 2y ago
I don't know why they pay so much attention to when things were made, and no attention to the microarchitecture, which they so often like to analyse.
The EM-RV1 (which is made up of Sipeed LicheePi 4A Clusters) uses 1.85 GHz THead C910 cores, with similar uarch to the Arm A72 (used in the first Amazon Graviton servers) or to something maybe early low end Core 2 e.g. in the first MacBook Air.
OF COURSE if all you want is the maximum performance and the ISA doesn't matter then you're much better off using something else for now.
But if you specifically want run RISC-V code, for example to get your software ready for the coming much faster RISC-V machines, then this is a good way to do it, without having to spend $180 up front for the equivalent SBC.
RISC-V machines with cores 1.3x faster will be out in a few months, and 2x faster around the end of the year. By around 2026 there will be RISC-V around Zen2 or Apple M1 performance. This is all in the pipeline.
- yjftsjthsd-h 2y ago> But if you specifically want run RISC-V code, for example to get your software ready for the coming much faster RISC-V machines, then this is a good way to do it, without having to spend $180 up front for the equivalent SBC. If that's all you're using it for, isn't qemu good enough? > RISC-V machines with cores 1.3x faster will be out in a few months, and 2x faster around the end of the year. By around 2016 there will be RISC-V around Zen2 or Apple M1 performance. This is all in the pipeline. That's a great argument for prepping your software now, but also for not buying anything now. Like, textbook https://en.wikipedia.org/wiki/Osborne_effect https://en.wikipedia.org/wiki/Osborne_effect
- brucehoult 2y ago> If that's all you're using it for, isn't qemu good enough? You can never quite be sure qemu correctly represents real hardware. There have been a number of cases where qemu was more permissive and programs developed on it didn't work on real hardware. The emphasis is on running valid code, not catching invalid code. Qemu-user on recent PCs is a bit faster than this board for long-running scalar programs with a small amount of code e.g. my primes benchmark: 5.052 sec i9-13900HX, qemu-riscv64 @ 5.1 GHz 10.430 sec Sipeed LM4A TH1520 4x C910 @1.848 GHz https://hoult.org/primes.txt https://hoult.org/primes.txt However, this changes if you run a lot of short programs in quick succession (as e.g. autoconf does) as you get dominated by JIT time. Or if you run full-system emulation using qemu-system, which gets hit by MMU emulation on every load/store. Also, this CPU core implements draft 0.7.1 of the RISC-V Vector spec with 256 bit ALU. Qemu emulates such SIMD code element by element, which is far slower than real hardware. NB there are significant differences between draft 0.7.1 and the final Vector 1.0, but the style is the same, most code doesn't hit the differences, and some code (e.g. memcpy/move/cmp, strcpy/cmp/len) is even binary compatible. Moreover, if you write code using the C intrinsics for the vector instructions then the newly-released GCC 14 can generate code for either 0.7.1 (as "XTHeadVector") or 1.0 from exactly the same source code with just a compiler flags change. > Osborne effect I was at university at the time. Osborne computers cost as much as a new car. RISC-V SBCs in this class cost as much as a dinner date. That makes a HUGE difference to people's willingness to buy something to throw away after a year. All the more so as the engineer using it is probably on a salary sufficient to earn enough to pay for one before morning tea.