For example, for many years Intel chips had a multiplier unit on a single port, with a latency of 3 cycles, but an inverse throughput of 1 cycle, so effectively pipelined across 3 stages.

In any case, I think uops.info [1] has replaced Agner for up-to-date and detailed information on instruction execution.

---

[1] https://uops.info/table.html

Pipelining in stages like fetch and decode are mostly hidden in these small benchmarks, but are visible when there are branch misprediction, other types of flushes, I$ misses and so on.

Being able to execute multiple instructions is more properly superscalar execution, right? In-order designs are also capable of doing it and the separate execution unit do not even need to run in lockstep (consider the original P5 U and V pipes).

I don't think that's accurate. That latency exists because the execution unit is pipelined. If it were not pipelined, there would be no latency. The latency corresponds to the fact that "doing division" is distributed across multiple clock cycles.

"The best way to predict the future is to invent it" -- Alan Kay

> You need to actually run both

Always! If you're not measuring, you're not doing performance optimization. And if you think CPUs are bad: try benchmarking I/O.

Operating System (n) -- Mechanism designed specifically to prevent any meaningful performance measurement (every performance engineer ever)

If it's measurable and repeatable, it's not meaningful. If it's meaningful, it's not measurable or repeatable.

Pretty much.

Or put another way: an actual stop watch is a very meaningful performance measurement tool.

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.

I'd love to see an updated version. The article talks about how out-of-order execution has a high power overhead and produces relatively small performance gains, but the M-series chips from Apple have deep OOO and low power consumption; I'm curious to learn what they did differently.

On x86 Integer instructions _never_ waited for floating point opcode to retire. You can check it yourself by reading FPU status register busy flag - if FPU was blocking you could never catch it in BUSY state and FWAIT would be useless :-)

Abrash exploited the fact Pentium was the first time x87 FPU instructions could run pipelined overlapping one another. All other x86 vendors FPUs waited for previous FPU instruction to retire.

https://www.agner.org/optimize/microarchitecture.pdf page 47

    While floating point instructions in general cannot be paired, many can be pipelined, i.e. one
    instruction can begin before the previous instruction has finished. Example:
     fadd st1,st0 ; Clock cycle 1-3
     fadd st2,st0 ; Clock cycle 2-4
     fadd st3,st0 ; Clock cycle 3-5
     fadd st4,st0 ; Clock cycle 4-6
    Obviously, two instructions cannot overlap if the second instruction needs the result of the
    first one. Since almost all floating point instructions involve the top of stack register, ST0, 
    there are seemingly not very many possibilities for making an instruction independent of the
    result of previous instructions. The solution to this problem is register renaming. The FXCH
    instruction does not in reality swap the contents of two registers; it only swaps their names.

Both ways had been used for many centuries for the manufacturing of complex things, as ways to organize the work of multiple workers.

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 program and for data).

Before 1959, pipelining was named "overlapped execution".

The first use of the word "pipeline" was as a metaphor in the description of the IBM Stretch computer, in 1959. The word "pipeline" began to be used as a verb, with forms like "pipelining" and "pipelined" around 1965. The first paper where I have seen such a verbal use was from the US Army.

Outside computing, pipelining as a method of accelerating iterative processes had been used for centuries in the progressive assembly lines, e.g. for cars, and before that for ships or engines.

Pipelined execution and parallel execution are dual methods for accelerating an iterative process that transforms a stream of data. In the former the process is divided into subprocesses through which the stream of data passes in series, while in the latter the stream of data is divided into substreams that go in parallel through multiple instances of the process.

Usually FP adds take a cycle or two longer than FP multiplication.

That's indeed impressive.

I'll argue that we're definitely capable of making fully pipelined divisions, it's just that it's usually not worth the PPA.