Unrelated, do FPUs on modern CPUs use FMAs to both multiply and add or do they use mul/add-only units?
Execution units are often pipelined
41–50 of 102 posts
Re: Execution units are often pipelined
#42Unrelated, do FPUs on modern CPUs use FMAs to both multiply and add or do they use mul/add-only units?
Probably to do multiplies, as the extra add is basically free. Adds are cheaper.
Re: Execution units are often pipelined
#43Pipelining is the direct reason behind 1996 Quake running 30 fps on Intel Pentium 133 but requiring 233MHz from Cyrix and 166MHz from AMD K6 to reach same result. 20 fps needed 75MHz Intel Pentium, 133MHz Cyrix and 100MHz AMD K5.
Re: Execution units are often pipelined
#44Is anything important not pipelined?
Memory barriers come to mind.
Re: Execution units are often pipelined
#45Earlier quoted context omitted.
Nope. 1957 in a transistorized computer is far too late for the origin of pipelining. Pipelining had already been used in computers with vacuum tubes a few years before and it had also been used already a decade earlier in computers with electromechanical relays, i.e. IBM SSEC, which had a 3-stage pipeline for the execution of its instructions (IBM SSEC had a Harvard architecture, with distinct kinds of memories for…
The earliest "pipeline" example I can find is the portsmouth block mills [1] implemented by Marc Brunel[2]/Henry Maudslay[3] around 1802 [1] https://en.wikipedia.org/wiki/Portsmouth_Block_Mills [2] https://en.wikipedia.org/wiki/Marc_Isambard_Brunel [3] https://en.wikipedia.org/wiki/Henry_Maudslay
Before that you had bucket brigades.
Re: Execution units are often pipelined
#46What I am interested to know is who invented pipelining? I tried googling but without much success. Does anybody know?
Come on, this isn't like the invention of calculus. Pipelining is just assembly line processing that anyone who managed or designed any factory would have implemented as soon as the transistor real estate became available.
Re: Execution units are often pipelined
#47Earlier quoted context omitted.
Presumably by analogy to production lines in factories?
Actually, it’s just obvious when you design the most basic ALU and the circuits for doing the carry.
Pipelining requires inserting extra (costly) flip-flops and intuitively one might think that this would decrease the performance. It is not that easy.
Re: Execution units are often pipelined
#48Pipelining is the direct reason behind 1996 Quake running 30 fps on Intel Pentium 133 but requiring 233MHz from Cyrix and 166MHz from AMD K6 to reach same result. 20 fps needed 75MHz Intel Pentium, 133MHz Cyrix and 100MHz AMD K5.
Specifically, Carmack exploited the fact that on the Pentium, integer instructions could run in parallel with floating-point division[0]. This goes to show that an optimization that usually gets you ~10% might get you 200% depending on what software you're running. And that no implementation detail is safe from an ambitious software engineer.
Re: Execution units are often pipelined
#49These days CPUs are so complex and have so many interdependencies that the best way to simulate them is simply to run them! In most real code the high throughput of these sorts of operations means that something else is the limiting factor. And if multiplier throughput is limiting performance then you should be using SIMD or a GPU.
Very true. To paraphrase a saying, CPU amateurs argue about micro-benchmarks on HN, the pros simulate real code.
The amateurs usually run benchmarks (because they can't reason about it as they lack the relevant knowledge) and believe they got a useful result on some aspect when in the fact the benchmark usually depends on other arbitrary random factors (e.g. maybe they think they are measuring FMA throughput, but are in fact measuring whether the compiler autovectorizes or whether it fuses multiply and adds automatically).
A pro would generally only run benchmarks if it's the only way to find out (or if it's easy), but isn't going to trust it unless there's a good explanation for the effects, or unless they actually just want to compare two very specific configurations rather than coming up with a general finding.
Re: Execution units are often pipelined
#50Earlier quoted context omitted.
> I don't think anyone is talking about "fetch, decode, operate, retire" pipelining (though that is certainly called pipelinig): only pipelining within the execution of a instruction that takes multiple cycles just to execute (i.e., latency from input-ready to output-ready). I'm curious what you think the distinction is? Those statements are equivalent. The circuit implementing "an instruction" can't work in a single…
Independently scheduled and queued execution phases are qualitatively different from a fixed pipeline.
An OoO design is qualitatively different from an in-order one because of renaming and dynamic scheduling, but the pipelining is essentially the same and for the same reasons.