> Speaking as a compiler guy, yes, you can make almost any of them as fast as each other given enough time and effort.
But putting time and effort into a JIT may not be as effective as choosing a different language.
So, the most "bang for your buck" may be using a JIT for a language like Python. Sure, it won't be as fast (at least, not until a huge amount of work has been done on it), but it can get faster. Trying to beat C + a good C compiler is ... ambitious.
Yes, fortran is actually faster than C for some things. OK, C++ with the right templates, or a later C standard can theoretically do what Fortran does (remind me again - pass by reference, no recursion, and bounded arrays rather than pointers?). And Intel tends to be faster than gcc.
There's no way you can make broad statements (like "nothing will beat C" or "fortran is actually faster than C for numerical stuff") without having a few exceptions. Actually, Pypy is faster than C, in extremely specific circumstances (i.e. ones which were set up by the Pypy people to show off, see "PyPy faster than C on a carefully crafted example" ... thought they point out there are things you could do in C to make it win).
The most bang for you buck in JITs is for dynamic languages, because while stuff like type inference can exponentially explode, you'll only really have 1 type in many cases (i.e. a float), and the JIT can pick that up. And getting Python within an order of magnitude of C would be a massive win.
So, the most "bang for your buck" may be using a JIT for a language like Python. Sure, it won't be as fast (at least, not until a huge amount of work has been done on it), but it can get faster. Trying to beat C + a good C compiler is ... ambitious.