We are in agreement if I understand you correctly.
I don't care whether Nim code runs 0.5% or 3% slower than C code. In fact, I
think that whole benchmarking is irrelevant except for a rough overview ("Nim
is within x% of C's speed").
Reason (and C/C++/D developers might want to read this carefully): Looking at
the code created by - even very good - C compilers everyone with some not
insignificant knowledge of ASM will concur that developing in ASM is the way to
get the fastest code. Unfortunately though, ASM (next to some other issues like
portability problems) also has the major disadvantage of being ridiculously far
away from the problem domain. So, if we were serious about it we needed to make
my axis longer to fit ASM quite a bit beyond C, at the extreme end of runtime
speed but also extreme distance to problem domain.
In other words: If we _really_ were obsessed with runtime speed we should chose
ASM over C - but we don't, i.a. because we would pay with a very significant
increase in development time, more and more difficult to spot bugs, etc. So the
reality is that C developers already made a compromise trading development
speed for runtime speed. Nim developers do the same - but with a much, much
better deal; we get a ton of lower dev. time, fewer bugs, etc. for what in the
end is a ridiculously low runtime price even if it happened to be 5% less speed
than C.
And btw - albeit largely theoretically right now (I assume) - we even _could_
compensate and reach C's RT speed due to Nims compiler having much more
information than a C compiler (almost always has) due to factors like e.g. Nim
strong static typing which allow the Nim compiler to generate C code that then
again would allow the C compiler to create faster code.
