[HN Gopher] Ask HN: Why are older processors slower at the same ...
___________________________________________________________________
Ask HN: Why are older processors slower at the same frequency?
I am a software engineer so I am pretty knowledgeable in the topic
of computers in general, but this specific question continues to
bother me. Why does a processor from 2015 at 2.5GHz run slower than
a processor from 2022 at 2.5GHz? What should I look at
specifically? Is the difference reported somewhere? In general:
how can I tell when I need to replace my processor with a new one
(without needing to manually compare the new and old one...)? I
think looking at the GHz and number of cores is not enough anymore.
Author : etamponi
Score : 15 points
Date : 2022-09-24 17:49 UTC (5 hours ago)
| kadoban wrote:
| Besides what others have mentioned, caches sizes and speeds help
| a lot, and I/O speeds in general (mostly in that some machines
| from 2015 might still have an hdd, not too many these days).
| toast0 wrote:
| In a word, IPC, instructions per clock cycle. Even in most, non-
| pipelined, strictly in-order processor, some operations take more
| cycles to complete than others: division is almost always much
| longer than addition, although some processors simply don't
| divide or multiply so everything can be equal speed.
|
| Adding more, cache and memory interfaces are important too;
| instructions don't run without data, and while early computers
| often had synchronous ram as fast as the cpu clock, that's not
| possible anymore, data that's not in registers takes time to load
| and store. Super scalar, out of order execution, etc mask some of
| that, but not all of it.
| DamonHD wrote:
| Clock frequency and cores were never really enough. When I
| benchmarked hardware for <ABigBank> years ago, the OS made quite
| a bit of difference as well. Eg WinNT was maybe ~2x slower for
| I/O for a given MHz of CPU than SunOS or Linux, IIRC.
| detaro wrote:
| Actual performance is based on two things: clock speed, and how
| much useful work the CPU design can do per clock step.
| improvements in the former have kind of stopped, so now most of
| the improvements happen in various aspects of the latter.
|
| The best comparison is and has always been benchmark results.
| IceWreck wrote:
| If you want to compare CPUs do benchmarks like Geekbench instead
| of comparing a single metric.
| tlb wrote:
| Modern CPUs can look ahead in the instruction stream and run 4 or
| more instructions simultaneously. This isn't easy: you have to
| respect data dependencies where one instruction depends on the
| output of a previous one. When something depends on a load
| instruction that missed in the cache, CPUs can keep going farther
| ahead and do some other work while waiting for load to complete.
|
| This "speculative out-of-order execution" requires a huge number
| of transistors to consider various combinations of future
| instructions it might be able to execute every clock cycle, and
| burns some extra power doing that. So although most of the basic
| ideas were known by the late 90s, adding more transistors in
| every generation lets it do more and more in parallel.
|
| Also, faster and larger caches cause fewer stalls.
|
| Also, modern cores are better at predicting branches, so they can
| proceed to start executing instructions past a branch before
| knowing which way the branch is going to go. If it guessed wrong
| about the branch, it has to undo the results of some
| instructions. So it adds a lot of complexity to track each side-
| effect that might need to be canceled.
|
| Also, SIMD parallel has gotten much better. Some modern cores can
| do 8 floating point operations per cycle using AVX2 or Neon.
| While older SIMD systems had very limited instructions sets, you
| can do a lot with modern ones. x86 SIMD instructions can process
| 32 bytes at a time. With a great deal of cleverness, you can do
| some byte stream operations in less than one cycle per byte. See
| https://arxiv.org/abs/2010.03090
|
| GPUs generally do 32 parallel floating point operations per core
| per cycle, with hundreds of cores.
|
| Also, main memory is gradually getting slightly faster and wider.
|
| Lastly, more cores are good. Back when the most cores you could
| get was 4, it was barely worth writing parallel software because
| all the locking slowed things down almost as much as the 4 cores
| speeded things up. But high-end Xeons can have 40+ cores, which
| makes it worth the hassle of writing parallel code. And GPUs have
| 1000s of cores, so it's worth a lot of complication to make use
| of them.
| sys_64738 wrote:
| Process fabrication improvements can mean a basic CPU design gets
| faster with no new redesign. Faster memory chips also with the
| same improvements.
| baybal2 wrote:
| smoldesu wrote:
| Like other comments said, there are a lot of factors that go into
| determining the performance of a clock cycle. One of the more
| interesting fields here is the optimization of instructions
| themselves - Agner Fog has a great document[0] comparing the
| performance of common x86 instructions across multiple CPU
| generations. It becomes really easy to see how great the early
| Ryzen chips were despite their low clock speeds.
|
| [0] https://www.agner.org/optimize/instruction_tables.pdf
| giuliomagnifico wrote:
| Because a CPU is more complex, you have also to look at the other
| parameters, like the RAM clock (that's handled by the cpu), the
| instructions set, the other connections BUS, etc... obviously if
| we are comparing a same x86 architecture and not ARM vs x86 or
| other RISC vs CISC.
|
| Using only the clock is like comparing two cars using only the
| number of horsepowers without the weight, aerodynamic, frame,
| etc...
___________________________________________________________________
(page generated 2022-09-24 23:02 UTC)