4 ms·

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

by songgao 13y ago

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% )

rayiner 13y ago
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.
- songgao 13y ago
  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?
  - deleted 13y ago
    [deleted]
  - pygy_ 13y ago
    µ-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.
  - Symmetry 13y ago
    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.

by songgao 13y ago

rayiner 13y ago

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.

songgao 13y ago
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?
- deleted 13y ago
  [deleted]
- pygy_ 13y ago
  µ-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.
- Symmetry 13y ago
  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.