The single core performance is roughly in the middle between Pi4 Cortex-A72 and Pi5 Cortex-A76.

It's slightly faster than a 3GHz Core 2 Dua in scalar single threaded performance, but it has 8 cores instead of two and more SIMD performance. There are also 8 additional SpacemiT-A100 cores with 1024-bit wide vectors, which are more like an additional accelerator.

The geekbench score is a bit lower than it should be, because at least three benchmarks are still missing SIMD acceleration on RISC-V (File Compression, Asset Compression, Ray Tracer), and the HTML5 browser test is also missing optimizations.

I'd estimate it should be able to get to the 500 range with comparable optimization to other architectures.

The Milk-V Titan mention in the original post is actually slightly faster in scalar performance, but has no RISC-V Vector support at all, which causes it's geekbench score to be way lower.

Something is odd here, the Core 2 Duo only has up to SSE 4.1, while the RVA23 instruction set is analogous to x64-v3. I find it hard to believe that the SpacemiT K3 matched a Core 2 duo single core score while leveraging those new instructions.

To wit the Geekbench 6.5.0 RISC-V preview has 3 files, 'geekbench6', 'geekbench_riscv64', and 'geekbench_rv64gcv', which are presumably the executables for the benchmark in addition to their supported instruction sets. This makes the score an unreliable narrator of performance, as someone could have run the other benchmarks and the posted score would not be genuine. And that's on top of a perennial remark that even the benchmark(s) could just not be optimized for RISC-V.

As someone from the Fedora/RISC-V project, it'll depend on what our users want. We cannot support both RV64GC and RVA23 (because we don't have the build or software infra to do it) so we have to be careful when we move. Doing something like building with RV64GC generally but having targeted optimizations - perhaps two kernel variants and some libraries - might be possible, but also isn't easy.

Things are different for CentOS / RHEL where we'll be able to move to RVA23 (and beyond) much more aggressively.

> On the other hand, even RVA23 is quite poor at signed overflow checking

When I tried to measure the impact of -ftrapv in RVA23 and armv9, it was roughly the same: https://news.ycombinator.com/item?id=46228597#46250569

reminder:

    unsigned 64-bit:
    add: RV: add+bltu       Arm: adds+bcc
    sub: RV: sub+bltu       Arm: subs+bcs
    mul: RV: mulhu+mul+beqz Arm: umulh+mul+cbz
    
    unsigned 32-bit:
    add: RV: addw+bgeu     Arm: adds+bcc
    sub: RV: subw+bgeu     Arm: subs+bcs
    mul: RV: mul+slli+beqz Arm: umul+cmp lsr 32

    signed 64-bit:
    add: RV: add+slt+slti+beq  Arm: adds+bcc
    sub: RV: sub+slt+slti+beq  Arm: subs+bcs
    mul: RV: mulh+mul+srai+beq Arm: smulh+mul+cmp asr 63
    
    signed 32-bit:
    add: RV: addw+add+beq   Arm: adds+bvc
    sub: RV: subw+sub+beq   Arm: subs+bvs
    mul: RV: mul+sext.w+bew Arm: smul+asr+cmp asr 31

> On the other hand, even RVA23 is quite poor at signed overflow checking.

On the other hand it avoids integer flags which is nice. I doubt it makes a measurable performance impact either way on modern OoO CPUs. There's going to be no data dependence on the extra instructions needed to calculate overflow except for the branch, which will be predicted not-taken, so the other instructions after it will basically always run speculatively in parallel with the overflow-checking instructions.