Yawn. It is not possible to directly compare languages wrt speed: we only can compare the speed of their implementations and reason about the features that make a language amenable to optimizations.
And we all know this.
So why, despite this knowledge, do we engage in "language speed flamewars" like this?
That's a valid question, and it belongs in the field of psychology of hackerhood. Does anyone have a reply to wager?
> So why, despite this knowledge, do we engage in "language speed flamewars" like this?
That was exactly the point.
The reason why this happens is because people are - just like me - invested in their tools, they want to tell themselves they made the right choice. And then they want to tell the world the same thing.
For me it doesn't matter which language is faster in a project. The parameter space that decides which language is 'right' is rarely determined by raw speed. But for those cases where raw speed is the determining factor you could do a lot worse than using C, and if you have latency requirements it is almost unavoidable on most ordinary platforms that we use.
I for one find things like these extremely interesting. The more there's analysis about performance implications of certain ways of doing the task the better. The only thing I'm left missing here is to actually look into the profiling information(branches, caches, instructions per cycle etc.), especially on the compiler generated assembly to see what exact instruction sequences are to blame, and if there are ways to save cycles here or there.
If only there were more things like this in the internets with deep analysis about performance of a given piece of code... :)
It was pretty long as it was... Tacking on a code generation section to show why certain things are inefficient (and the associated detour to how the standard library is implemented which would be required reading to understand all the implications) would make the article three times as long. I promised I'd have it done by Monday.
> So why, despite this knowledge, do we engage in "language speed flamewars" like this?
Because here in the real world, speed sometimes matters? And many languages are fairly closely associated with given implementations that live in the real world, and are more or less fast.
These days, I mostly write Ruby because time to market is more important than having code run fast, but in its current form, it's generally a slower language than C. There, I said it! Yes, of course I really mean implementation, but realistically, there are no Ruby implementations that are faster than compiled C code.
I submit that these are really always about implementation speed. And this matters because at the end of the day we will be using an implementation, not a pure language without implementation.
And we all know this.
So why, despite this knowledge, do we engage in "language speed flamewars" like this?
That's a valid question, and it belongs in the field of psychology of hackerhood. Does anyone have a reply to wager?