2 ms·
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 b
by BeeOnRope 8y ago
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).
- andreas-a 8y agoSection 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/ 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.
- BeeOnRope 8y agoRight, 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 http://uops.info/html-instr/SHLD-1633.html You can see the varying latencies on Nehalem for op1->op1 versus op2->op1. Great work!