I respectfully disagree they are the "best" - the results are wildly off target with actual real life results when sampled across CPUs of varying ages and types. I've pretty much learned through trial and error ("why are these E5-2660v2 numbers so much lower than the E5645?!") they are rather useless to actually judge a CPU's performance and return results of the actual work units themselves.

Not to mention they measure a single thread on a single core, which is wildly different when you fire up all 20 threads at once on a 10-core Xeon - thermal / cooling is now in play and a ton of other factors. Apps like stress-ng fire up a 1-per-thread process and perform a much larger, more in depth and broad set of tests that show what real life is like when you start cooking the sockets and provide realistic simulations. It's the same reason you use fio instead of dd when performing disk I/O tests, real life is random and messy and noisy.

There's a french website, WUProp, that does detailed analysis of all projects generated job/cpu data provided by those who've got their client connected to their BOINC project. It's a low/no load project (NIC) that just captures job stats, CPU, OS etc. That one tells which CPU gives the best points per job type.

Edit: Here http://wuprop.boinc-af.org/results/delai.py

I do not know anything about the Dhrystone benchmark, but I do know a lot about the Whetstone one. This one is widely believed to be a good test of floating point calculation, but actually it is just awful.

Whetstone is comprised of a bunch of loops, each of which is designed to test some aspect of the machine and its compilation system. These were selected based on the frequency of use as instrumented by the Whetstone Algol 60 compiler system. Typically each item under test was put into a loop executed (IIRC) 10,000 times. One of these loops does a bunch of floating point operations. Hence people thought it measured floating point operations. Actually this loop was meant to measure the call and return overhead, and the floating point operations were not of interest.

BUT this is just an illusion. Modern compilers do extensive optimization. I was involved in the design and implementation of the C compiler optimizer when I was working at Bell Labs. And we absolutely clobbered that loop. The significant optimizations we did were first:

I moved all the floating point operations outside of the loop, since the calculations were invariant and did not need to be performed more than once. Then a live-dead analysis removed the loop code and the single set of floating point instructions since the values of the calculations were not used. So any compiler written after about 1980 would do the same. It, basically, does not test floating point operations at all.

For sure, and the floating point libraries as well. The man who wrote the most recent versions of these libraries (by recent, I mean around 1985) had the office next to mine. He hand coded them in assembler for the machines we were using (mainly pdp-11/45s and 3B-20 machines). I think we did them for the SPARC as well, but I am not sure about that.