D vs VM-based platforms

[Dave]

gareis wrote:
> Sean Kelly wrote:
> ...
>> That said, JIT optimization is still a relatively new practice, and 

But the optimizations are the same (basically), and the best and brightest have been at it for 
years. I'd venture a guess that more has been / still is being spent on VM research rather than 
static compiler research. Over roughly the past 10 years, I've seen several articles promising Java 
would exceed C and Fortran in 'a year or two'. A couple of years later I also recall finding some 
pretty large performance regressions between major releases of their Java VM. I still think 1.3 does 
some things better than 1.6 and it's been, what, 5 years? Interestingly, Sun is still improving 
their static compiler tools though.

>> with more cores being added to computers these days it's entirely 
>> possible that a JIT optimizer could run on one or more background CPUs 
>> and do much better than today.
> 
> And then you're sacrificing two or three cores to run one thread, rather 
> than sacrificing most of the developer's computational power at compile 
> time and running as efficiently (or more so) with at most one core per 
> thread.
> 
> Now, if the compiler cached its optimizations on disk, you could 
> potentially get similar optimizations after some large number of runs. 

Sun's Hotspot does this (but it's not explicitly cached on disk).

> However, in the interim the program would run slower than the optimized 
> precompiled code, and would start slower than the JIT code that didn't 

That's why Sun has both a 'client' and a 'server' VM.

> cache its optimizations (because that caching takes disk time, and 
> that's one of the most expensive resources).
> 
> Of course, your runtime compiler can optimize for your user's current 
> CPU, even if that changes. I suppose you could create binaries optimized 
> for each CPU and have a script determine which is appropriate for the 

I know Intel and (IIRC) to a lesser extent MS VS2005 C/C++ as well as Sun and HP compilers will 
compile this right into the binary for you (and then the best code is picked at runtime). Seems to 
work pretty well from what I've seen.

> current CPU, but that's spending disk space (also quite scarce) in 
> exchange for CPU time (relatively abundant).
> 
> I don't know how to solve this problem, but it's an interesting one.