Stroustrup's talk on C++0x

[Robert Fraser]

> I suppose most application programs will run in a VM in the distant future,
> but at the moment at least my PCs are crying for mercy if I try to run
> bigger Java apps (running code analysis for a relatively small Java GUI app
> took about 2 hours in Eclipse). Flash applets aren't any better: a 300x200
> mpeg2 movie can choke the system even though mplayer plays several
> simultaneous 720p streams just fine. The only .Net app I've used was a
> video card control panel on Windows. It felt too unresponsive to be usable
> in the long term.

Really? JIT compilers (LaTtE, Sun Java 5+, probably IBMs JVMs .Net runtime, Mono...) compile things to native code, so besides a little overhead as far as the compilation goes at startup, they should run just as fast as native code, if not faster.

I think one of the problems as far as speed is concerned is that the languages were not designed for pure efficiency, and make heavy use of heap allocation, etc.

That said, there are already some applications that run faster on a JIT VM because the VM can do certain optimizations that a native compiler can't, and, further, can do it transparently (without programmer interaction). Especially as multi-cores become more prevalent, VMs will be able to automatically vectorize/parallelize loops, which means that, if nothing else, they provide the power to spare the "average developer" who might not know so much about optimization or paralellism, from those horrors.

Flash is a different story, as I doubt ActionScript is JITed. As far as Eclipse goes, the IDE does a _lot_ behind the scenes (it compiles any changes every time you stop typing for a couple seconds, marks semantic errors & resolves bindings as you type, etc., etc.), so on slower computers it might sometimes feel a little sluggish. Java's String class is also partly to blame (40 bytes of heap-allocated overhead for every string is a lot), but that's more an issue with the coding style & standard library than with VMs in general.