Hacker News Reader

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; }

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.40GHzView on HN [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: class="border-t border-slate-200/70 pt-4 text-center text-xs text-slate-400">Reply on news.ycombinator.com