Hacker News Reader

Comment by CalChris | Hacker News Reader

Latency numbers will differ (a lot) because the definitions of latency these sites use differs. Agner uses the delay that the instruction generates in a dependency chain. uops.info uses number of clock cycles that are required for the execution core to complete the execution of all of the μops that form an instruction. instalatx64 uses latency means the time that it takes for the next dependent same-type instruction to start. These are very different definitions.

For example, Agner gives a latency of 2 for pop r while uops.info gives 6.

View on HN

The "number of clock cycles that are required for the execution core to complete the execution of all of the μops that form an instruction" is the definition that Intel uses in its manuals to define latency.

It is actually not the definition that uops.info uses. Instead, it uses a definition that takes into account that different operands of an instruction might be ready at different times (see section 4.1 of the paper that mentions Intel's definition as a "common definition" and then continues to introduce the new definition). Furthermore, uops.info also considers latency differences that can occur if an instruction uses the same register for multiple operands (the SHLD instruction is an example for this).

Is it even possible to measure the latency by Intel's definition? I think "operational" definitions that correspond to something you can actually measure (and by extension apply to measured performance in real code too) are far preferable.

In theory "it is complicated" because an instruction might have N inputs and M outputs and the latency matrix might have different values for every element in that N x M matrix, but in practice instructions have 1 output and the inputs are usually symmetric with regards to latency so one figure is enough for most. It's worth calling out the exceptions though, and uops.info is supposed to do that I think (an example would be great).

Section 7.3 of the paper describes several such examples.

On Sandy Bridge, for example, the result of the "AESDEC XMM1, XMM2" instruction is ready 8 cycles after XMM1 becomes available. If only XMM2 is on the critical path, however, the result is already available after a bit more than one cycle.

On Nehalem, the SHLD R1, R2, imm instruction has, according to Intel's manual, http://instlatx64.atw.hu/, and IACA, a latency of 4 cycles. Agner Fog reports a latency of 3 cycles. The measurements on uops.info show that the latency from R1 to R1 is 3 cycles, while the latency from R2 to R1 is 4 cycles.

Right, I read the paper and saw the examples, but I meant more an example of if/how this information is surfaced in the results as collected at uops.info.

Anyways, it is all there, using your SHLD example:

http://uops.info/html-instr/SHLD-1633.html

You can see the varying latencies on Nehalem for op1->op1 versus op2->op1.

Great work!

All of the memory-source instructions in Agner's guide don't really have a meaningful latency. In particular, the input and output domains are different. In the case of pop, the input is memory and the output is a register, so you can't really measure the latency of pop in isolation: you need to chain it together with at least one other instruction whose inputs and outputs are in the opposite domain (eg push, or mov [memory], reg).

Agner says himself that he "arbitrarily" divides the latency between load and store type instructions in these cases which gives the mostly meaningless value of 2 for load-type instructions.

Reply on news.ycombinator.com