If you bundle JIT with garbage collection, bounds checking, and all the usual things that come with the JVM/CLR and execute on current hardware, probably not.
If you were to JIT a language like C it would probably be faster as you could optimize to specific hardware. OpenCL uses JIT for example and it's many times faster than static compilation (because it can take advantage of extra hardware at runtime).
The issue to contend with is the reality that about 30 years of the industry have gone into making C fast, everything from compilers to the way CPUs are designed. There's likely no inherent reason any style of compilation / execution couldn't beat static compilation, it's just we need the same level of resources and hardware support for those execution models.
For instance with garbage collection and bounds checking you no longer need an MMU.
Right, that is the point that both Herb and myself agree on: current managed languages have chosen paths where fewer errors, safety and productivity are more important than raw performance.
That said, although bounds checking eliminates some of the reasons for MMUs, it does not really solve many other features that we take for granted today that depend on MMUs, like on-demand-loading.
Garbage collectors and VMs typically use the MMU to improve the performance of their own operations. You use the MMU to cause execution to stop, you use MMUs to setup redzones on the stack to avoid checking on every function entry point for how much space is left on the stack and VMs use the MMU to map their metadata into their address space without having to load them from file and provide the services on demand.
> That said, although bounds checking eliminates some of the reasons for MMUs
Microsoft had a research OS called Singularity that was written in C# mostly and could be run in real memory mode because they didn't need the barriers.
Inferno (developed pretty much by the same team that recently created Go at google, and before created Plan 9 and Unix) doesn't need a MMU either, this is a great advantage when running on hardware without an MMU (there is a pretty good port to the Nintendo DS), and also makes it easier to port to platforms with an MMU (a single guy ported it to the PS2 in his spare time), MMUs are one of the main sources of platform-specific complexity.
Is that "If you were to JIT a language like C it would probably be faster" true? I think a JIT C compiler would run into trouble with alias detection. Let's say that it removes an if statement because the variable a in the "if(a)" that starts it always is false. In C, code like "x->y = 1;" could affect the value of a, as could _any_ pointer dereference. If the JIT cannot prove that that could happen, it would have to insert a check "does this modify a?" for every such statement. I think there will be quite a bit of code out there where even a very smart JIT would not be able to conclusively prove that such aliasing does not happen.
Also, I do not accept that OpenCL argument. IMO, OpenCL is more similar to static compilation than to a JIT. It is as if you recompiled your kernels whenever you changed your video card (perhaps also when you change its configuration); it does not do things that a JIT would do, such as "hm, most of the pixels are black; let's optimize for that case".
We (compiler optimization folks) have gotten very good at making pointer and alias analysis fast, particular simple pointer analysis like you might find in JIT. For a JIT, you would likely write out conservative but correct static results in whatever the equivalent of "javac" is for your C jit, and then refine it in the JIT. You'd invalidate it if you saw accesses you can't account for come up later on.
Even if you didn't want to do that, on demand CFL reachability formulations of pointer analysis can calculate reasonable pointer results for individual pointers fast enough if it became important.
Realistically however, no JIT is going to do advanced pointer analysis, unless you have CPU to burn.
As for "conclusively prove that aliasing does not happen", you don't actually have to, because if it is truly going to improve performance, you can insert runtime checks.
if (&a == &b)
<do super fast thing>
else
<slower fallback code>
If your C program has aliased pointers to different types, you are already running in undefined behavior land. The JIT is just as free to optimize away that test as the static compilers that optimize it away today.
OpenCL is only vaguely JIT like in the common sense. If I recompiled Photoshop so each image transform were completely unrolled and optimized for the image's dimensions, that'd be a closer approximation. It's more like online static compilation. You could kind of get the same effect using libtcc. [Now I'm not sure if I'm agreeing or disagreeing with you. I can't quite articulate the difference between JIT and "online static compilation", but I feel there is one.]
If you bundle JIT with garbage collection, bounds checking, and all the usual things that come with the JVM/CLR and execute on current hardware, probably not.
If you were to JIT a language like C it would probably be faster as you could optimize to specific hardware. OpenCL uses JIT for example and it's many times faster than static compilation (because it can take advantage of extra hardware at runtime).
The issue to contend with is the reality that about 30 years of the industry have gone into making C fast, everything from compilers to the way CPUs are designed. There's likely no inherent reason any style of compilation / execution couldn't beat static compilation, it's just we need the same level of resources and hardware support for those execution models.
For instance with garbage collection and bounds checking you no longer need an MMU.