No, it's like comparing sprinters by having them run, and someone telling you: "hey, the problem is not that sprinter X is ten times slower. The problem is what you want to do in the real world. Do you want to go from A to B? Why not take the bus, etc".

[I'm not saying this about the L1i cache case specially, which is a good point, but rather for the prevalent response to any benchmark in Go-land, a defensive attitude which I have not witnessed in any other language community. Usually Python, JS, Ruby, Rust etc guys get on to fixing such microbenchmark behavior or explain why it's as it is. Go guys just propose you forget about it and rewrite your code in another way].

I don't care about a specific real world case of getting from A to B, or how it can be done faster in another way. I care about measuring sprinters. The case that's important here is benchmarking itself. How fast each and every instruction of a similar type executes in a language.

E.g if I do:

for i in range(10): print i

and

for i:=0; i<10; i++ { fmt.Print(i); }

I don't care if this kind of code is not representative of an actual program, I don't care if the code inside the loop might take more time in most cases, I don't care if I can write some particular program using some other structure.

I only want to know why this takes X time in Python and c*X time in Go, and if the c factor can be improved.

Suggestions about "real world programs" and "write this another way and then measure" in this regard are counter-productive, because they focus not on raw benchmarking the language but on specific cases.