alt Hacker NewsPlease stop framing the multi core scaling issue as a matter of the benchmark being good or bad. Geekbench 5 scores scale better than Geekbench 6 scores because Geekbench 5's multicore test runs N independent copies of the same workload while Geekbench 6 runs one workload that has to be split across the available cores, with non-zero coordination between threads.
The Geekbench 5 approach of pretending Amdahl's Law doesn't exist is sometimes a valid benchmarking strategy, but generally is the wrong choice for benchmarking consumer workloads and devices, and that's what Geekbench is ostensibly targeting.
The fact that Geekbench 6 scores don't increase linearly with the addition of more CPU cores is not a weakness of the benchmark, it's the benchmark demonstrating an important real-world effect.
The change that Geekbench 7 makes to exclude some subtests from the multicore suite entirely will definitely have the effect of making the overall multicore score scale better with the addition of more cores, but most of the audience for those scores is going to miss out on the fact that the multicore test now measures a narrower range of tasks than the single-core test suite.
Replies
Hmm, I don't fully agree. There are a whole lot of embarassingly parallel processes that people interested in many core workstations are interested in; compiling large C++ codebases for example tends to scale very well since each translation unit is independent. This is still going to not quite give you linear scaling so it's definitely still valuable to know what that looks like.
They do mention that the change is meant to reflect how real world programs handle various types of workloads.
> In Geekbench 7, a workload only runs in multi-threaded mode if the task it models actually runs multi-threaded in real applications. For example, the HTML5 Browser test isn’t included in the multi-threaded suite because web browsers are single-threaded (or lightly threaded).
While it would be nice to have a multi-threaded benchmark that demonstrates a realistic scaling towards many threads, I have no reason whatsoever to trust that the Geekbench implementers are capable to optimize the inter-thread communication well enough for reaching the limits imposed by the hardware.
If they use inefficient thread synchronization methods, like those offered by the C++ compiler, or by the pthreads library on Linux, or by some of the older Win32 functions, their results will be much too pessimistic for the CPUs with many cores, creating the wrong impression that they are not much better, or not better at all, than CPUs with less cores.
For Geekbench 6, I have seen enough results where CPUs that are much better for real multi-threaded workloads appeared to be almost the same as clearly inferior CPUs.
For multi-threaded benchmarks, if they are embarassingly parallel the quality of the implementation does not influence the results, but otherwise it is not possible to trust the results without having access not only to the source program of the benchmark, but also to the compilers used by it.
I have seen a lot of benchmarks of locking methods used for thread synchronization, where the results could not be interpreted correctly without seeing the assembly language instructions generated by the compiler for the locking sequences, because a bad assembly generation could matter more than the high-level algorithms whom the benchmark was supposed to compare.
It bothers me because there is no reason it can't just give 3 results: single, mixed/low thread, all core and yet there is often debate on which 2 numbers in such benchmarks instead.
But, of all of the 2-pick-only options, choosing a custom mix and calling it multi-core requires guessing your actual workload on both the content of the mixed test suite as well as the scaling profile of the CPU to reason with. On the other hand, just testing "single core" and "all core" at least only requires you to guess based on what you think the scaling profile of the CPU is.
Nothing beats just testing your actual workload, but that doesn't mean all other ways of testing have to be equally good.
Honestly I think the world would be better off if Geekbench just refused to run on any machine over 28C. Then people could benchmark their workstations using... workstation benchmarks.
I agree. For me personally I mostly only care about single thread geekbench variant, I believe it's an excellent proxy for general performance of a CPU. Multi thread geekbench (or other benchmarks) for most purposes and for most people, it's kinda useless. You just need to know that you have a quite a few cores on your computer and that it will have enough concurrency for what you do. But single thread will make whatever you do actually faster.