3 ms·
To be fair, you didn't say how much or how I would get it. I imagine if I were to show up at your doorstep with cap in hand, I might get a penny off of you. If
by dalke 11y ago
To be fair, you didn't say how much or how I would get it. I imagine if I were to show up at your doorstep with cap in hand, I might get a penny off of you.
If the optimizer is enabled, and the upper bound hard-coded, then the compiler pre-computes the loop. This is the entire code from llvmgcc:
_main:
0000000100000f10 pushq %rax
0000000100000f11 leaq 72(%rip), %rdi ## literal pool for: sum: %lu
0000000100000f18 movabsq $49999995000000, %rsi
0000000100000f22 xorb %al, %al
0000000100000f24 callq 0x100000f34 ## symbol stub for: _printf
0000000100000f29 xorl %eax, %eax
0000000100000f2b popq %rdx
0000000100000f2c ret
Which means you are right - it's hard to beat a pre-computed constant.
I think I owe you a penny.
- karlheinz_py 11y agothanks for this insight, I've countered the problem with command line args. Now the C compiler can't guess how many loops will be made and therefore the test shows the same speed as C without using optimisation. But Go keeps having consistent speed, faster than C. I'm curious what kind of optimisation the Go compiler applies. See the update for further details..
- karlheinz_py 11y agoEdit: I thought C optimisation wasn't working but I repeated the tests and now C keeps having the same speed with optimisation despite passing the number as command line argument. This also suggests that the value is not calculated at compile time..