FWIW you've linked Geekbench 4; Geekbench 5 is https://www.geekbench.com/doc/geekbench5-cpu-workloads.pdf
I agree these benchmarks have issues, but there's a consistent trend (eg. AnandTech's SPEC results are similar—they use active cooling to avoid the question about thermals) and the most reliable benchmarks, like compilers, aren't outliers.
True that, they did increase the book size and yet it's till below the dict size:
compresses and decompresses a 2399KB HTML ebook using the LZMA compression algorithm with a dictionary size of 2048KB.
Doing the test below 4MB of L3 would hurt, doing with with less than 2MB would decimate the test.
for instance: Integer WorkloadsLZMA CompressionLZMA (Lempel-Ziv-Markov chain algorithm) is a lossless compression algorithm. The algorithm uses a dictionary compression scheme (the dictionary size is variable and can be as large as 4GB). LZMA features a high compression ratio (higher than bzip2).The LZMA workload compresses and decompresses a 450KB HTML ebook using the LZMA compression algorithm. The workload uses the LZMA SDK for the implementation of the core LZMA algorithm.
They compress just 450KB of text as a benchmark - even the dict size is greater then the input. If both fits the CPU caches - the results are supreme, if not - horrible compared to the former. Also it'd vastly depend how fast the CPU can switch to full turbo mode (for servers that doesn't matter at all)
[0]: https://www.geekbench.com/doc/geekbench4-cpu-workloads.pdf