3) GHz cannot be used as a speed comparison outside of the same generation of CPUs. A 10 year old 3.5GHz gets nowhere near the same compute power as a modern day 2.4GHz.
For a lot of basic operations, this is often false.
I have an application I'm working on and tested it across three different generations of CPUS going ~10 years back.
The code was written in C and the fundamental steps were to: mmap() two arrays of structs from a sata 3 SSD, compare the two, and write the intersection to a block of memory. The data size of each array was multiple gigabytes and the operation took more than a full second.
The ~10 year old low powered Xeon L5640 beat the higher-speed ~5 year old Xeon E5-2667 v2, and was only slightly beaten by the 3 year old i7-4790k. In short, they all ran at roughly the same speed.
I would say that this is because of the limits of the SSDs, but then I tested by holding that data in memory rather than disk, then ran the intersection. Same result.
This is a very basic operation that tests the performance of the CPU and memory. And for operations like these (ie: not using SSE2, AVX, etc), the perceived performance difference to the vast majority of people for a secondary home machine may be negligible.
That really depends on your load. I once feared a huge performance regression when a test took 2 minutes instead of 40s. Turned out one instance ran on a i7-6xxx machine, and the other on a i7-9x0. Normalizing for the different clock, the newer CPU had a 20% better IPC.
Disclaimer: I don't recall exact numbers, but they should be somewhat close to those given.
> I would say that this is because of the limits of the SSDs, but then I tested by holding that data in memory rather than disk, then ran the intersection. Same result.
Wouldn't it then just be testing the limits of your memory?
