Amdahl's law is one thing, and an inefficient implementation of a concurrent program is another thing.

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.

If they had an embarrassingly parallel test, Intel would be exclusively promoting that misleading number just like they do with Cinebench. Let's not create even more totally unrepresentative benchmarks.

> Given that Geekbench is a consumer workload benchmark, it makes sense to factor in Amdahl's Law. Period.

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.