Hacker News Reader

Comment by mgraczyk | Hacker News Reader

I think It's because the branch target is a memory access, so the dcache causes the execution pipe to stall on the load. In the tight loop with a call, the branch target is a call and there is time enough to pull from dcache before the load data is needed. I suspect that the i7 can't pull data from dcache immediately the jne instruction, so you get a hiccup. Try adding a second noop in to tightloop as the target for jne.

View on HN

The trace cache on that chip likely stores a u-op trace that includes the target of the call instruction, which means the memory subsystem shouldn't even need to fetch it separately since it'll come straight back from the trace cache right in line as part of the instruction sequence.

I think you might be right about stalls.

Here is a version of unsigned j; for (j = 0; j < N; ++j) { counter += j; __builtin_prefetch(&counter, } } void nop_wait() { unsigned j; for (j = 0; j < N; ++j) { unsigned x = counter; /* 4 or more __asm__("nop"); __asm__("nop"); __asm__("nop"); __asm__("nop"); counter = x + j; } } tightloop: 3,000,314,154 cycles 2,400,971,094 instructions 0.788256283 seconds time elapsed loop_with_call: 3,000,314,154 cycles 2,400,971,094 instructions 0.788256283 seconds time elapsed nopwait: 2,679,341,970 cycles 4,000,906,874 instructions 0.704209471 seconds time elapsed vs

  prefetch: 2,586,821,497 cycles 2,800,888,975 instructions

0.679998564 seconds time elapsed

This is on a Intel(R) 4004e0: 31 c0 4004e2: 0f 18 0d 87 04 20 00 4004e9: 48 8b 15 80 04 20 00 4004f0: 48 01 c2 4004f3: 48 83 c0 01 4004f7: 48 3d 00 84 d7 17 4004fd: 48 89 15 6c 04 20 00 400504: 75 dc 400506: f3 c3 400508: 0f 1f 84 00 00 00 00 40050f: 00 2,445,505,116 cycles 2,800,857,971 instructions 0.643010038 seconds void loop_dummy_read() { IACA_START; unsigned j; unsigned dummy_read; for (j = 0; j < N; ++j) { dummy_read = dummy; counter += j; } IACA_END; }

< movq counter(%rip), %rdx addq %rax, %rdx addq $1, %rax cmpq $400000000, %rax nopw 0x1(%rax,%rax,1) movq %rdx, counter(%rip) jne .L3

The fastest version that I could find is to do a prefetch of counter at the end of the loop .... speaking of which isn't that nopw that GCC uses for alignment a prefetch instruction too? Is the CPU tricked by the fake address used there?

  void prefetch() { 0, 3); nops seem right, 3 nops are slower */ #    0.000 GHz                      ( +-  0.01% ) #    0.80  insns per cycle          ( +-  0.00% ) ( +-  0.02% ) #    0.000 GHz                      ( +-  0.01% ) #    0.80  insns per cycle          ( +-  0.00% ) ( +-  0.02% ) #    0.000 GHz                      ( +-  0.37% ) #    1.49  insns per cycle          ( +-  0.00% ) #    0.000 GHz                      ( +-  0.54% ) #    1.08  insns per cycle          ( +-  0.00% ) Core(TM) i7-2600 CPU @ 3.40GHz

[can't edit previous post]In fact replacing the nopw that is used for alignment by a prefetch instruction gives me something slightly even faster:
  00000000004004e0 <prefetchit>: xor    %eax,%eax prefetcht0 0x200487(%rip)        # 600970 <counter> mov    0x200480(%rip),%rdx        # 600970 <counter> add    %rax,%rdx add    $0x1,%rax cmp    $0x17d78400,%rax mov    %rdx,0x20046c(%rip)        # 600970 <counter> jne    4004e2 <prefetchit+0x2> repz retq nopl   0x0(%rax,%rax,1) #    0.000 GHz                      ( +-  0.52% ) #    1.15  insns per cycle          ( +-  0.00% ) time elapsed

That's almost 20% faster than the original. Not bad at all.

I think I've discovered that the target of the prefetch is irrelevant, and that what matters is that the store-to-load forwarding does not try to execute in the same cycle.  For Sandy Bridge, I'm finding that I can get slightly better performance with a dummy load of an unrelated volatile variable:
  volatile unsigned dummy = 0; /div>

The prefetch is only serving as 6-byte padding here. The nopw instruction performs no memory access, it does not double as a prefetch.There are remarkably few memory accesses actually being performed in that loop. The CPU is using store forwarding to cache the 'memory' accesses in the store buffer, which means most accesses are not even accessing L1 cache (if this were the case, we would not have such a low count of cycles per iteration).
The best result I've got is by inserting a 6-byte nopw right before the store:
    .L3: div>

What trace cache?That's a P4 thing, not a Core thing http://en.wikipedia.org/wiki/CPU_cache#Trace_cache
Edit: ok, Core has a uop cache http://en.wikipedia.org/wiki/Micro-operation_cache#Micro-ope...
You don't need a trace cache to do what you suggest, it just predicts the branch and goes from there

noops are removed by the scheduler. happening precisely, this might not help.

Reply on news.ycombinator.com