Apples and Oranges
Programming languages are compared against each other as though their designers intended them to be used for the exact same purpose - that just isn't so.
Programming in Lua
Lua is a tiny and simple language, partly because it does not try to do what C is already good for, such as sheer performance, low-level operations, or interface with third-party software. Lua relies on C for those tasks.
What sort of problems is Erlang not particularly suitable for?
Most (all?) large systems developed using Erlang make heavy use of C for low-level code, leaving Erlang to manage the parts which tend to be complex in other languages, like controlling systems spread across several machines and implementing complex protocol logic.
[pdf] Measuring the Haskell Gap
One can, with sufficient effort, essentially write C code in Haskell using various unsafe primitives. We would argue that this is not true to the spirit and goals of Haskell, and we have attempted in this paper to remain within the space of
reasonably idiomatic Haskell. However, we have made abundant use of strictness annotations, explicit strictness, and unboxed vectors. We have, more controversially perhaps, used unsafe array subscripting in places. Are our choices reasonable?
The difficulty is that programming languages (and programming language implementations) are more different than apples and oranges, but the question is still asked -
Will my program be faster if I write it in language X? - and there's still a wish for a simpler answer than - It depends how you write it!
Measurement is not prophesy
The performance of a benchmark, even if it is derived from a real program, may not help to predict the performance of similar programs that have different hot spots.
It may seem paradoxical to use an interpreted language in a high-throughput environment, but we have found that the [pdf] CPU time is rarely the limiting factor; the expressibility of the language means that most programs are small and spend most of their time in I/O and native run-time code.
Since compiler optimizations and code changes also alter layout, it is currently impossible to distinguish the impact of an optimization from that of its layout effects. ... the performance impact of -03 over -02 optimzations is indistinguishable from random noise.
Would you believe us if we told you:
we can predict the benefit of our optimization, O, by evaluating it in one or a few experimental setups using a handful of benchmarks? Again, you should not: we all know that computer systems are highly sensitive and there is no reason to believe that the improvement with O is actually due to O; it may be a result of a biased experimental setup.