28-Way Linux CPU/System Comparison From Old To New

[austin754]

Why did you miss BLAKE2? It'd have been useful to see real regardless-of-clock-differences single-core performance over the years...

Note that aobench, encode-mp3, encode-flac, compress-zstd and scimark2 are all single threaded. Some of these might be slightly limited by I/O (encode-flac) and some by memory (compress-zstd and to lesser extent scimark2). However, overall I would expect them to give at least an overall comparison of single-thread performance.

As far as blake2 goes, the workload runs in less than 0.5 seconds on my i7-4770 (~0.47 seconds) and hence will be even faster on the the fastest CPUs. I put more stock in a single-threaded benchmark like compress-zstd that runs for a more reasonable time than a benchmark that finishes in less than half a second.

--mev

[Adarion]

I would have expected an i7 8086 K CPU - especially today(!).
It's 40 years of i 8086.

[Michael_S]

It's funny how the 1990s and early 2000s spoil us. My parents' first computer was ludicrously expensive in 1996 with its Pentium processor screaming along at 120MHz. The replacement in 2002 or so was at 700 MHz and had a larger cache. Imagine that kind of jump.

Three desktops in my house have AMD chips from 2010-2013. But I've got 12GB+ of RAM and SSD for the boot drive in each box, and I really don't see anything here to make me upgrade.

[carewolf]

I think you should have eithrer removed the AMD E-350 or used a logarithmic or squareroot scale, as is it is almost impossible to read the graphs

[Azpegath]

Michael, how many threads are used during the compilation tests?

[ferry]

Just a tip, when you see graphs turn out the way these did just exclude AMD E-350. While it's a datapoint extra it's so off the rest that it "ruins the graphs" somewhat since the rest become compressed. They didn't really sell many of them anyway.

The graphs are ruined for another reason: Performance is a relative measure. And as with most relative relative measures we are mostly interested in 'how much more / less'. What you need with performance measurements is a logarithmic measure ln(nr of sec.), but this give a non-intuitive value and you loose the relation with real world results, same as with an 'index'. Best solution is to use a logarithmic scale.

Michael, how about that?

(graph done with LO Calc, any mistyped benchmarks are unintentional)