Geekbench 5 and earlier constructed the multi-core test as essentially running N independent copies of the single-core test. This effectively pretends that every subtest is embarrassingly parallel. Geekbench 6 switched to having the multi-core test actually operate like real multi-threaded software: a fixed-size problem is broken up to be divided among available cores, with a non-zero amount of coordination between threads and potential for less than perfectly linear scaling because Amdahl's Law isn't being ignored.
But that’s a very specific thing to adjust a benchmark for, what if I want to host 50 VMs on one server for example? Then the 100 core server would be much better than the 16 core server, even though it has a lower benchmark value.
It's not a "very specific" thing to adjust a benchmark for. It's the default case for practically all consumer workloads, and Geekbench is a consumer-focused benchmark.
Comments
Geekbench 5 and earlier constructed the multi-core test as essentially running N independent copies of the single-core test. This effectively pretends that every subtest is embarrassingly parallel. Geekbench 6 switched to having the multi-core test actually operate like real multi-threaded software: a fixed-size problem is broken up to be divided among available cores, with a non-zero amount of coordination between threads and potential for less than perfectly linear scaling because Amdahl's Law isn't being ignored.
But that’s a very specific thing to adjust a benchmark for, what if I want to host 50 VMs on one server for example? Then the 100 core server would be much better than the 16 core server, even though it has a lower benchmark value.
It's not a "very specific" thing to adjust a benchmark for. It's the default case for practically all consumer workloads, and Geekbench is a consumer-focused benchmark.