This is around the performance of a Core 2 Duo, if I understand correctly?

camel-cdr 3 hours ago | parent | next [-]

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.

▲

ahoka 42 minutes ago | parent | next [-]

That’s actually decent, thanks.

▲

oxxoxoxooo 2 hours ago | parent | prev [-]

Do you happen to know how does one access/use those A100 cores?

	▲	camel-cdr 2 hours ago \| parent [-]
		No. The problem is that you can't migrate threads between cores with different vector length. The current ubuntu 26.04 image, that is installed, lists 16 cores in htop, but you can only run applications on the first 8 (e.g. taskset -c 10 fails). If you query whats running on the A100 cores you see things like a "kworker" processes. I suspect that it should be possible to write a custom kernel module that runs on the A100s with the current kernel, but I'm not sure. I expect it will definitely be possible to boot a OS only one the 8 A100 cores. Well have to see if they manage to figure out how to add support for explicitly pinning user mode processes to the cores. The ideal configuration would be to have everything run only on the X100s, but with an opt-in mechanism to run a program only on an A100 core.

▲

6SixTy 2 hours ago | parent | prev [-]

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.

▲

adgjlsfhk1 2 hours ago | parent [-]

If it's anything like the k1, I wouldn't be surprised if Core 2 performance was on the table. The released specs are are ~Sandybridge-Haswell like, but those were architectures made by (at the time) the top CPU manufacturer and were carefully balanced architectures to maximize performance while minimizing transistors. SpaceMIT is playing on easy mode (they are making a chip on a ~2-4x smaller process node and aren't pioneering bleeding edge techniques), but balancing an out of order CPU is still tough, and it's totally possible to lose 50% of theoretical ipc if you don't have the memory bandwith, cache hierarchy, scheuling etc.

	▲	6SixTy an hour ago \| parent [-]
		Cache issues add another layer here, if it's not the whole issue. Device tree patches for the K3 have 2 clusters of 4 cores with shared 4MB L2 cache per cluster. Core 2 Duo P8400 has 3MB L2 shared between 2 cores, and Sandybridge-Haswell have per core L2 and shared L3.