Benchmarks like 7Zip compression/decompression, LAME encoding, Blackmagic RAW video encoding, Cinebench, x265 encoding, Blender encoding, Y Cruncher, and any of the built-in video game benchmarks make much more sense than Geekbench.
Some good benchmark options here https://hwbot.org/benchmarks
https://www.pcgamingwiki.com/wiki/List_of_games_with_built-i...
Why are they incomparable? If I want to run a highly parallel task surely this tells me which one to use?
> Benchmarks like 7Zip compression/decompression, LAME encoding, Blackmagic RAW video encoding, Cinebench, x265 encoding, Blender encoding, Y Cruncher, and any of the built-in video game benchmarks make much more sense than Geekbench.
Pretty sure the internal tests it uses are similar to these
For instance, the file compression workload on version 6:
This workload compresses and decompresses the Ruby 3.1.2 source archive (a 75 MB archive with 9,841 files) using different compression codecs (such as LZ4 and ZSTD). It also verifies the files using the SHA1 (Secure Hash Algorithm 1) function.
Benchmarks like 7Zip compression/decompression, LAME encoding, Blackmagic RAW video encoding, Cinebench, x265 encoding, Blender encoding, Y Cruncher, and any of the built-in video game benchmarks make much more sense than Geekbench.
Geekbench is extremely good at showing general CPU performance, especially ST. It's also highly correlated with SPEC at nearly 1:1 in terms of scores as shown by Nuvia before they were purchased by Qualcomm.[1]
[0]https://browser.geekbench.com/v6/cpu/18801240 scroll down
[1]https://medium.com/silicon-reimagined/performance-delivered-...
Yes, they are imperfect, but they do broadly measure how fast a processor is, and can be used for comparison.
As other have stated and perhaps worth pointing out clearly incase people don't get it. If you dislike Geekbench for those reasons, it is highly likely you don't know what Geekbench is testing in the first place.
Personally I think Geekbench is a pretty damn good consumer testing benchmarks. I just wish there is something similar for Server testing PHP, Ruby, JVM, MySQL and Postrges etc.
Can't wait to see all the M1 to M6 results. Along with AMD Zen 6.
You can extract meaning from them! Find your current computer, find the target computer, calculate the percentage difference. 1000 is 1% better than 990, so it indeed doesn't mean anything at all.
Here's research done by Nuvia before they were bought by Qualcomm: https://medium.com/silicon-reimagined/performance-delivered-...
.. but it chugs power like it's not even funny.
I do like synthetic benchmarks as one input signal when evaluating a CPU; otherwise we go back to stupid numbers like frequency... which also never made sense because they had 1.8GHz AMD Athlon CPUs outperforming 2.4GHz Pentium 4's in 2002-3...
Doing a lot of real-world application testing is good, but there's always some you miss, and the worst part about it is that people start to lose patience when assessing.. How is a cinebench comparing to doing gamedev in UE5?
How is doing gamedev in UE5 comparing to doing gamedev in Snowdrop?
How does doing gamedev in Snowdrop compare to doing virtualisation (different CPUs handling that particular task better than others).
there's so many dimensions that it will always be true that there's not enough testing.
I'm not saying we shouldn't have rigorous testing like you say, in fact, what I'm actually saying is that "single number→would you like to go deeper" is a better pipeline than an excel spreadsheet that goes on for 10 pages (which still skips a bunch of nuance) and still better than one that goes on for 500 pages with a broad spectrum of topics.
The reason I'm so bitter about this is because outlets like LTT and Gamers Nexus seem to choose their games randomly (based on popularity I guess?) and so all the titles I worked on kinda got smeared by my "company"- but our games used hugely different game engines that work differently (Dunia vs Snowdrop handle CPUs... VERY differently. Snowdrop is built for multi-core. Anvil works best on a single core, and Dunia has trouble going passed 4 cores- so on large systems with multiple NUMA zones the performance is.. worse.
So the "battery of tests" always gave us a shitty score and reviewers just moved on believing themselves to be comprehensive arbiters of truth regarding performance and giving verdicts regarding the performance of games as a broad topic (which people take and don’t dig deeper themselves) and without regard to the utility of what they’re saying (500+ fps on CSGO isn't even renderable for example).
People might have been better served by looking broadly at how powerful the CPUs actually are and then digging in for their use case once they whittle a few down, because then also: developers will actually make software that tries to use the features on offer instead of assuming people will just buy CPUs that work better on their workloads.
It's a kind of "to big to fail" mentality where incumbents start being able to direct CPU sales based on those CPUs being optimised for their workloads. It's self-reinforcing.
Geekbench 5 is famously much better than Geekbench 6 for benchmarking these workstation-class CPUs (though many other benchmarks are better still, especially if you can grab the source code and compile them yourself).
I still like having a set of benchmarks that run across Android, iOS, Windows, macOS, Linux, and on Arm, X86, RISC-V, etc... even if imperfect, it's a point of reference to get a general feel. And the single core scores are a great representation of a 'feel' against baseline in day-to-day use.
It focuses more on ML than LLMs though.
If you ever want a cheeky laugh ask your llm of choice to write a satirical Userbenchmark amd review.
CPU: https://www.geekbench.com/doc/geekbench7-cpu-workloads.pdf
GPU: https://www.geekbench.com/doc/geekbench7-gpu-workloads.pdf
> The Clang workload uses the Clang compiler to compile the Lua interpreter, a popular open-source language interpreter.
People really shouldn't call Geekbench a synthetic benchmark anymore, since it has been using real world workloads for years now.
[deleted]
With inter-frame delivery codecs the hw encoder always focuses on speed, with a lean towards file size as well. It makes sense for most consumer use cases. 15x faster perhaps sure, but you might end up with a file almost 10x larger while still lower quality than a decent CPU encoding. Also the more off the beaten path of rec709 and rec2020 you go the less certain you can be that the hw encoder supports things.
[deleted]
On the other hand, whether the Geebench multi-threaded benchmarks are meaningful is questionable. Especially Geekbench 6 has a very poor scaling to many threads, which shows results that are quite uncorrelated with many practical workloads.
Moreover, the multi-threaded benchmarks are too short to reach a steady-state, so they show extremely optimistic throughputs for CPUs with poor cooling, like those from smartphones and laptops. Thus with Geekbench many smartphones and laptops appear to be competitive in multi-threaded performance with desktops or servers, while in real workloads their performance would be pathetic (because as soon as they would overheat, their performance would drop drastically).
Like any benchmarks, Geekbench can be gamed by CPU vendors.
For example, because already the older versions of Geekbench included secure hash computations, the Arm Aarch64 CPUs obtained good scores, because since 2012 they had special instructions and hardware for computing SHA-1 and SHA-256.
The x86-64 CPUs did not have such instructions, so they had bad scores. This prompted Intel to add a SHA ISA extension, but they added it only to the Atom CPUs, because only those competed with Arm CPUs and people compared their Geekbench scores.
For many years, among the Intel CPUs only the small and cheap Atom CPUs had SHA instructions, while their big and expensive desktop/laptop/server CPUs did not have SHA instructions, because at that time nobody compared their Geekbench scores.
This has changed only after the launch of AMD Zen, which included the SHA extension. Then, eventually, after the years during which Intel failed to progress beyond the Skylake derivatives, Intel finally added the SHA extension to all its CPU series, starting with Ice Lake, and since then all the x86-64 CPUs have it.
SPEC CPU is distributed in source form, to be compiled by the end user. There are restrictions on what kind of compiler options and other games you can play when making an official submission to SPEC, which Intel (and others) get around by publishing "estimated" SPEC scores and using those for marketing claims. In practice, the amount of bullshit in Intel's claimed SPEC scores is constrained only by what Intel's legal department is willing to risk getting sued over.
Geekbench is distributed in binary-only form with all binaries for all platforms originating from the author of Geekbench. All the major chip designers pay to see the source code and participate in the development, but the final decisions about what code goes in and how it's compiled are made by the author of Geekbench, not by the chip vendors. They just get to lobby, and AMD has every opportunity to call out Intel and Geekbench should the compiler options for the x86 builds be unfair.
Intel has a long history of cheating on SPEC, but cheating on Geekbench is more difficult because of the necessity of runtime binary patching and they didn't publicly try until this year, with limited success and lots of negative press: https://www.geekbench.com/blog/2026/03/geekbench-6-and-intel...
Thanks
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.
There are also things that are well-correlated with the single-threaded Geekbench result, like how responsive will appear an Internet browser, but for many professional uses the multi-threaded performance is much more important than the single-threaded performance.
For many CPUs, and depending on the computers in which they are installed, the single-threaded and multi-threaded results are completely uncorrelated, because during the multi-threaded benchmark the clock frequency in some computer may drop even 4 times (there are Intel CPUs with a so big ratio between the maximum turbo frequency and the base frequency), while in another computer it might drop only by 20%.
> 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).
(One could just as easily argue that the single-core test suite ought to exclude any task typically done with multiple threads in real-world usage.)
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.
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.
Geekbench isn't a server CPU benchmark that stresses 128 core CPUs.
The real truth is that if consumers don't benefit from knowing how well multicore workloads scale, then they can just look only at the single-core score. Skewing it on purpose by including things that genuinely only use ~1 core doesn't seem to serve to add value but only obfuscate the truth about how well a CPU is able to scale on multicore workloads, which does matter sometimes (like with modern video games.)
Yes this means that 128 core Xeon servers will maybe look especially good, but idk, what consumer hardware has 128 cores? Consumers are not considering a Mac Mini versus a fucking NVIDIA Vera rack, you know?
I fully accept that you could view it either way, but if you're going to have a multicore score at all, in my opinion, it may as well actually show you what multicore workloads look like. It is OK that consumers can't necessarily understand how this translates. If all they ever do is single core workloads, they will never have any benefit to looking at the multicore workload score for any Geekbench score on any Geekbench version, because otherwise the multicore score overstates the performance, whereas if they were to look at a version that has multicore including ~single threaded workloads, it would understate the multicore scaling.
Benchmarks are necessarily imperfect no matter how you shake it. For example, it is impossible for a general compute benchmark to show how much better the UX of two cores is over having just one core that is a bit faster.
Though, now that I say all of this, I get the strange feeling the nerve it's striking is fanboyism. What else would make people care this much, but perhaps the hardware vendor they are fans of showing up higher in the numbers? Well it ain't me. I couldn't care less how Apple and AMD and Intel compare in the Geekbench scores. Could be wrong, but somehow this just feels like a good bet.
Now the question is whether having a 3rd CPU score for embarrassingly parallel work makes sense for Geekbench. It probably does since many professionals also use Geekbench nowadays.
We do not know how much of the bad scaling of Geekbench 6 was due to Amdahl's law and how much was caused by an inept implementation.
Moreover, Amdahl's law is really important only for very short computational tasks, i.e. which do not need more than a few seconds or minutes for completion.
The bigger is the job that must be accomplished, the more likely it is that it can be reorganized in a way that tends to be embarassingly parallel, so that Amdahl's law has little importance.
So for jobs as big that they need hours, days or weeks to be completed by a computer, if they are well planned it is frequent to reach scaling factors not much lower than the number of available cores, even if that may be much more difficult to achieve for short jobs.
You're contradicting yourself. Do you want realistic scaling, or the kind of highly-tuned hand-optimized scaling that almost no real-world applications (especially in the consumer space) ever get?
In both of your comments here, you make very narrow assumptions about what constitutes a "real" workload, and you're excluding ordinary everyday consumer PC software from what you consider "real". Highly optimized software running on large servers aren't the only "real" workloads, and they're not the kind of "real" workload that Geekbench is trying to represent. For the kind of hardware and use cases that Geekbench actually targets, using the platform/compiler default synchronization primitives and doing work in short bursts interspersed with significant idle time is reasonable and realistic.
For the other multi-threaded tasks, like running certain CAD/EDA applications, I use well-optimized programs, either by others or by myself.
What I do is typical for a professional use of a computer.
The Geekbench multi-threaded results do not provide any useful information about how a computer will behave for such applications.
I agree that the Geekbench multi-threaded results may be representative for how a smartphone will behave if it will have small bursts of multi-threaded activity caused by casually written applications, interspersed between single-threaded execution.
This would be fine, if it would be more clearly specified when the Geekbench benchmark is distributed.
I know that I should trust only the single-threaded Geekbench results and for multi-threaded I should search other published benchmarks.
But others appear to not be aware of this and I have seen frequently erroneous claims on the Internet that some laptop or even some smartphone would match or exceed the performance of a desktop or of a bigger laptop, even one with a CPU with more cores, based on the published Geekbench multi-threaded results, while in reality that desktop or big laptop has a much greater throughput.
Geekbench has that as a subtest.
> For the other multi-threaded tasks, like running certain CAD/EDA applications, I use well-optimized programs, either by others or by myself.
Those seem pretty clearly out of scope. You want a workstation benchmark, not a consumer benchmark.
> This would be fine, if it would be more clearly specified when the Geekbench benchmark is distributed.
The descriptions of what Geekbench is are adequate. You're asking for Geekbench to exhaustively list what it isn't to stop you from imagining it to be a one-size-fits-all benchmark, which couldn't possibly exist.
> But others appear to not be aware of this and I have seen frequently erroneous claims on the Internet that some laptop or even some smartphone would match or exceed the performance of a desktop or of a bigger laptop, even one with a CPU with more cores, based on the published Geekbench multi-threaded results, while in reality that desktop or big laptop has a much greater throughput.
Again you seem to be unable to stop asserting that workstation or server use cases are the only ones that are real.
Yes, that's pretty much the whole point of Geekbench: to offer non-experts a way to measure CPU performance and produce scores that are relevant to a specific class of devices and users and use cases, rather than artificially inflated.
Benchmarking experts can already use something like SPEC, which does offer single-thread and both types of multi-thread test modes (SPECrate and SPECspeed).
To be honest, they are factoring in Amdahl's law, because they're actually not only including embarrassingly parallel workloads, they're just not including ones where the speedup factor is roughly 0. Frankly I should have acknowledged this in my initial response.
> Now the question is whether having a 3rd CPU score for embarrassingly parallel work makes sense for Geekbench. It probably does since many professionals also use Geekbench nowadays.
Including workloads that are almost entirely single-threaded does not tell you anything about the "multi-core" performance of the processor. It just biases the multi-core score to be lower, period.
It is true that even without that, the multi-core score will still be biased towards the rough average speedup factor of all of the workloads combined, but that's just the nature of an aggregate benchmark. If you wanted to know how it would perform on a specific task, you'd need a specific benchmark anyways. If they've done a good job, the multi-core scores should still be useful for comparison across processors for your average multi-core workload.
I think two things are true:
- If consumers almost only ever use single threaded workloads, then the multi-core score will always be misleading to them if it is anything above what the single core score is. They should be paying more attention to the single-core score.
- If consumers do have multi-threaded workloads, then a multi-core score that averages in a bunch of tasks with no multi-core speedup will also not be representative for them, as it will understate the performance benefits they can see.
If you wanted a more useful third number it would be a weighted overall score, but what is the objectively correct weight between single and multi-core? Even for consumers this is a challenging number to come up with.
But I know one thing: it is almost certainly not whatever weight you just happen to wind up with by just arbitrarily including whatever number of single-threaded tasks your benchmark happens to have in a multi-core benchmark score.