D vs Java

[Dave]

In article <dvkklp$2pl$1 at digitaldaemon.com>, Walter Bright says...
>
>"Dave" <Dave_member at pathlink.com> wrote in message 
>news:dvkbvk$2hn5$1 at digitaldaemon.com...
>> IIRC, there was some argument a while back that they weren't running the 
>> tests
>> long-enough to take advantage of Hotspot. Since then they've increased the
>> length of the tests to account for that (and startup time is subtracted 
>> from
>> those results as well, I believe).
>
>I attended a seminar at SDWest which talked about the "myth" of slow Java. 
>Turns out, the code is interpreted for a while, then it gets compiled, then 
>certain things can *invalidate the compiled code* so it goes back to 
>interpreting it, then compiling it again, etc.

That explains a lot... I had read somewhere a while back that some parts of
earlier VM's had to be 'detuned' because optimizations based on real-time info.
were often counter-productive and/or causing bugs in apps. I guess in some cases
they decided to invalidate cached code rather than 'detune' it.

>
>Is it invalid to include all these compile times, even if they occur well 
>into the execution, as part of the benchmark time? I don't think so. At the 
>end of the day, the time the user is sitting their waiting is what matters, 
>and that will include all the startup, interpretation, compilation and 
>recompilation times.
>
>The presenter confidently predicted that in 10 years, Java will outperform C 
>in the general case. Color me skeptical. 
>

It's funny, but I've read predictions like that every year for the last 10 <g>
And for many things I think the original JIT's were still the best.

>From what I gather, there has been huge amounts of R & D into the problem from
all kinds of organizations - I figure by now if they haven't figured it out
there are reasons other than for trying. A manager I know likes to call stuff
like that "polishing the turd" <g>