Intel i7 loop performance anomaly

Re:Intel i7 loop performance anomaly by songgao on Tuesday December 03, 2013 @03:15PM (#6842860)

I tested on Intel Xeon W3680, which is at least 2 years old, and the result is opposite. Perhaps it only happens on newer CPUs?

  gcc -O2 -o main main.c
  perf stat -r 10 -e cycles,instructions ./main t
  
   Performance counter stats for './main t' (10 runs):
  
       2,408,573,034 cycles                    #    0.000 GHz                      ( +-  0.07% )
       2,401,351,221 instructions              #    1.00  insns per cycle          ( +-  0.00% )
  
         0.723734145 seconds time elapsed                                          ( +-  0.12% )
  
  perf stat -r 10 -e cycles,instructions ./main c
  
   Performance counter stats for './main c' (10 runs):
  
       2,802,522,431 cycles                    #    0.000 GHz                      ( +-  0.00% )
       3,201,523,974 instructions              #    1.14  insns per cycle          ( +-  0.00% )
  
         0.842082646 seconds time elapsed                                          ( +-  0.07% )

[ Parent | on HN ]

Re:Intel i7 loop performance anomaly by rayiner on Tuesday December 03, 2013 @03:19PM (#6842885)

That's Nehalem u-arch, which (unlike Sandy Bridge and Haswell), does not have a u-op cache. So that's an interesting data point.

[ Parent | on HN ]

Re:Intel i7 loop performance anomaly by songgao on Tuesday December 03, 2013 @03:41PM (#6843041)

I didn't know about u-op and just looked it up. Could you explain it into more details? How does it involve in this case?

[ Parent | on HN ]

Re:Intel i7 loop performance anomaly by pygy_ on Tuesday December 03, 2013 @04:22PM (#6843278)

µ-ops stand for micro-operations. Behind their CISC frontend, modern [0] x86 (and x64) actually perform as RISC processors. x86 opcodes are translated to these µops on the fly, and executed.

I'm not familiar with the caching mechanism, but here's an educated guess. There are potential optimizations in the CISC -> RISC translation, according to the x86 opcode sequence (reorder operations in order to run some of them in parallel, for example), and it is possible to cache them, sparing cycles in the process, since the processor wouldn't have to analyze the code each time to perform the optimizations.

Edit: apparently, my guess was correct :-) Thanks to Symmetry for the confirmation.

[0] By modern, I mean "not ancient". The first processor to do that was the Pentium Pro.

[ Parent | on HN ]

Re:Intel i7 loop performance anomaly by Symmetry on Tuesday December 03, 2013 @04:25PM (#6843297)

x86 instructions are often big and complicated and hard to decode, so much so that the machine doesn't use them internally in the various buffers and so forth that make up it's out of order engine. Instead, they're translated into a different set of instructions called uOps which only live inside the inner part of the CPU.

Translating them takes energy, and can potentially be the limiting factor in how faster certain programs can be run. That means that recent Intel designs keep a small buffer of uOps that correspond to instructions it's likely to see again quickly. This can help a lot in loops.

[ Parent | on HN ]