Robin Sheat wrote:
> On Tuesday 14 November 2006 13:28, Crispin Cowan wrote:
>
>> It means that compromising performance
>>
> It's not necessarily a given that runtime performance is compromised. There
> are situations where Java is faster than C (I've tested this on trivial
> things).
Here it is "bytecode vs. native code generator", not "Java vs. C."
Remember, I advocated Java over C++ in the first place :)
Even in the bytecode vs. native code generator contest, there are cases
where each will win:
* bytecode interpreters always lose; they really are just a kludge
* JIT can win if it uses dynamic profiling effectively and the
application is amenable to optimization for decisions that need to
be evaluated at runtime
* JIT can be a lose because of the latency required to JIT the code
instead of compiling ahead of time
So:
* JIT will win if your application is long-lived, and has a lot of
dynamic decision making to do, e.g. making a lot of deep object
member function calls that are virtual, or just a lot of
conditional branches.
* Native code will win if your applications are just short-lived,
because they are dispatched as children from a dispatcher process
o You pat the JIT cost each time it starts
o The short lifespan doesn't give dynamic profiling time to do
its thing
> Personally, I find the programmer time to be much better used in Java too.
>
No argument from me. I advocate Java, I just want a native code
generator instead of bytecode.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering, Novell http://novell.com
Hack: adroit engineering solution to an unanticipated problem
Hacker: one who is adroit at pounding round pegs into square holes
_______________________________________________
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
