On: Go vs. C vs. pypy/Python loop performance comparison

[dalke]

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 → dalke]

thanks 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 → karlheinz_py]

Edit: 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..