Comment by brucehoult | Hacker News Reader

Comment by brucehoult | Hacker News Reader

Parent Full thread

Out of interest I tried running my Primes benchmark [1] on both the x86_64 and x86 Alpine and the riscv64 Buildroot, both in Chrome on M1 Mac Mini. Both are 2nd run so that all needed code is already cached locally.

x86_64:

    localhost:~# time gcc -O primes.c -o primes
    real    0m 3.18s
    user    0m 1.30s
    sys     0m 1.47s
    localhost:~# time ./primes
    Starting run
    3713160 primes found in 456995 ms
    245 bytes of code in countPrimes()
    real    7m 37.97s
    user    7m 36.98s
    sys     0m 0.00s
    localhost:~# uname -a
    Linux localhost 6.19.3 #17 PREEMPT_DYNAMIC Mon Mar  9 17:12:35 CET 2026 x86_64 Linux

x86 (i.e. 32 bit):

    localhost:~# time gcc -O primes.c -o primes
    real    0m 2.08s
    user    0m 1.43s
    sys     0m 0.64s
    localhost:~# time ./primes
    Starting run
    3713160 primes found in 348424 ms
    301 bytes of code in countPrimes()
    real    5m 48.46s
    user    5m 37.55s
    sys     0m 10.86s
    localhost:~# uname -a
    Linux localhost 4.12.0-rc6-g48ec1f0-dirty #21 Fri Aug 4 21:02:28 CEST 2017 i586 Linux

riscv64:

    [root@localhost ~]# time gcc -O primes.c -o primes
    real    0m 2.08s
    user    0m 1.13s
    sys     0m 0.93s
    [root@localhost ~]# time ./primes
    Starting run
    3713160 primes found in 180893 ms
    216 bytes of code in countPrimes()
    real    3m 0.90s
    user    3m 0.89s
    sys     0m 0.00s
    [root@localhost ~]# uname -a
    Linux localhost 4.15.0-00049-ga3b1e7a-dirty #11 Thu Nov 8 20:30:26 CET 2018 riscv64 GNU/Linux

Conclusion: as seen also in QEMU (also started by Bellard!), RISC-V is a *lot* easier to emulate than x86. If you're building code specifically to run in emulation, use RISC-V: builds faster, smaller code, runs faster.

Note: quite different gcc versions, with x86_64 being 15.2.0, x86 9.3.0, and riscv64 7.3.0.

[1] http://hoult..rg/primes.txt

MIPS (the arch of which RISCV is mostly a copy) is even easier to emulate, unlike RV it does not scatter immediate bits al over the instruction word, making it easier for an emulator to get immediates. If you need emulated perf, MIPS is the easiest of all

That's a very small effect in the overall decoding of an instruction even in a pure interpretive emulator, and undetectable in a JIT.

Also MIPS code is much larger.

MIPS code is not much larger.

There are two interesting differences of ISA between MIPS and RISC-V: that MIPS does not have branch on condition, only on zero/non-zero and that MIPS has 16 bit immediates with appropriate sign extension (all zeroes for ORI, all ones for ANDI). The first difference makes MIPS programs about 10% larger and second difference makes MIPS programs smaller (RISC-V immediates are 11.5 bits due to mandatory sign extension, 13 bits are required to cover 95% of immediates in MIPS-like scheme), a percent or so, I think.

ANDI is not 1-extended (though that would be nice) it is 0-extended. MIPS only has 2 extension modes for immediates - sign extended and zero-extended. all logical ops are 0-extended, all arith ops are sign extended.

Thanks. My memory failed me, I've implemented MIPS 18 years ago.

Entirely disagreed. In a simple step by step emulator it can be as much as 30% of the time spent. In a jit indeed it is less of an effect.

MIPS Linux ELF interpreter in Perl:

http://blog.schmorp.de/2015-06-08-emulating-linux-mips-in-pe...

> If you're building code specifically to run in emulation, use RISC-V: builds faster, smaller code, runs faster.

I don't really think this bears out in practice. RISC-V is easy to emulate but this does not make it fast to emulate. Emulation performance is largely dominated by other factors where RISC-V does not uniquely dominate.

Do you have an explanation for GP's benchmark results then?

If they had a working link I might

Oh darn, I mistyped that, though it's not that hard to guess how to fix the typo (or Google):

http://hoult.org/primes.txt

x86 is a lot easier to JIT to Arm or RISC-V though, because it has fewer registers.

Interesting to see the gcc version gap between the targets. The x86_64 image shipping gcc 15.2.0 vs 7.3.0 on riscv64 makes the performance comparison less apples-to-apples than it looks - newer gcc versions have significantly better optimization passes, especially for register allocation.

The RISC-V one has just never been touched since it was created in 2018.

> newer gcc versions have significantly better optimization passes

So what you're saying is that with a modern compiler RISC-V would win by even more?

TBH I doubt much has changed with register allocation on register-rich RISC ISAs since 2018. On i386, yeah, quite possible.

Reply on news.ycombinator.com