Adrian (a.delete@this.acm.org) on May 26, 2022 6:09 am wrote:
> -.- (blarg.delete@this.mailinator.com) on May 26, 2022 5:23 am wrote:
> > Michael S (already5chosen.delete@this.yahoo.com) on May 26, 2022 3:36 am wrote:
> > > Sorry for may be naive question, in recent couple of years I was not following.
> > > How the ST field at the fastest stock frequency (no overcloking) looks by now?
> > > Say, Apple M1 (Pro/Max/Ultra) vs Zen3 with big cache vs regular
> > > Zen3 vs Alder Lake vs Rocket/Tiger Lake vs Comet Lake?
> > > Non-FP scores are of primary interest.
> >
> > Not sure why you bring up Intel's older processors, but again, depends on what you measure exactly.
> >
> > SPEC2006 is somewhat an industry standard, and you can find a ranking here:
> > https://www.anandtech.com/bench/CPU-2020/2797 - ranking does include SPECfp,
> > so you'd have to go to individual scores if you just want SPECInt results.
> >
> > The AMD 5800X3D and Intel 12900KS are missing from the list, though
> > I'd still expect Alder Lake to come out on top for SPEC.
>
>
> SPEC2006 might be an industry standard, but I do not trust at all that list of results from Anandtech.
>
> For benchmarks written in high-level languages, the compiler used and the compilation options
> can be the cause of much higher differences in benchmark results, than the differences in
> actual achievable CPU performance, which are very small for the top competitors.
>
> Only for a few of the CPUs listed by Anandtech it is possible to discover, by diving into the corresponding
> Anandtech articles, the compiler versions and the compiler options. Even in those cases, the values used do
> not appear to be optimal or uniform across the reviews separated by long times, of many months or years.
>
> It is pretty certain that Apple M1 has a performance that is overestimated on that list, by
> using a clang version appropriate for it, while the x86 CPUs use also clang, with less appropriate
> versions and options, instead of using a new enough gcc with the best options.

No. On modern OoOE processors, compiler has huge effect only when something can be vectorized by another compiler but not vectorized by another compiler. It affect specFP much more than specINT.

Breakdown of the individual subtests of specINT 2006 at anandtech:

https://images.anandtech.com/graphs/graph16252/111158.png

Apple CPU's do much better only in 456.hmmer.

And that's a benchmark which prform LOTS of loads(almost 50% of all instructions) and very little amount(~7%) of branches.
Apples huge 128 kiB L1D cache can easily explain the huge difference in this test.

There is nothing in the results suggesting something is "unfair" or "broken by apples compiler".