none (none.delete@this.none.com) on November 18, 2020 8:07 am wrote:
> Chester (lamchester.delete@this.gmail.com) on November 18, 2020 7:02 am wrote:
> [...]
> > Sure, Cinebench isn't the best representation of average workloads. But SPEC is far
> > worse. No consumer cares about SPEC. The subtests are mostly based off applications
> > no one uses, or very specific scientific simulations.
>
> I'm convinced gcc (or clang) is used by many more people than Cinebench.
>
> Anyway Cinebench is too much about FP to be in any way an average representation of
> anything beyond rendering; can you point to a study of its characteristics to disprove
> that? And even for rendering I guess most people now run renderers that use GPU
> acceleration.
>
> SPEC has a good advantage for benchmark specialists: source is available for study and its
> characteristics have been thoroughly studied. It's not a toy for end-users such as
> Cinebench. But as any benchmark it should never be used without running other benchmarks.
>
> > It's even useless as a benchmark
> > to see whether your system is working properly, because it's so overpriced.
>
> Cinebench is also a poor use for that as it doesn't stress enough the CPU. I prefer to use
> programs such as prime95 for CPU stressing.
>
> And as far as price goes, again it's not an end-user app or a toy.
>
> > Also, some SPEC numbers make it seem like negative SMT scaling is common. It's not. I've
> > personally never seen an application that can use all available threads do worse when
> > SMT is enabled. Can we stop looking at the irrelevant pile of garbage that is SPEC?
>
> Because you never saw that happen, it can't happen in a real world application?

FPGA fitting (or p&r, if you prefer X language) would have seen huge slowdowns from SMT if software devs were naive. Fortunately, they are not naive and never use more threads than the # of physical cores, so the slowdown is minimal.
Except, I suppose, when it's run under hypervisor that lies about physicality of cores.