harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nick Lothian" <nloth...@educationau.edu.au>
Subject RE: I hope the JVM implements most using Java itself
Date Fri, 13 May 2005 05:26:17 GMT
> <constructive_interest>

[snip - I'm not qualified to answer the first question]

> This brings me to the second question. In my experience, 
> writing in Java and writing in C (and therefore thinking in 
> Java and thinking in C) tends to produce very different 
> programs. The languages just lead you in different 
> directions. "Language shapes thought," you know. So, although 
> one can argue that a Java program will ultimately be JITed 
> (or WATed or
> whatever) to machine code, the program itself will not be 
> written in the same way as a C program would be. Again, this 
> is subjective and I expect people will not always agree with 
> this. But I find that when I write C code, I'm thinking of 
> CPU efficiency, changing strings in-place, and using 
> pointers. Maybe *because* C is so painful, I tend to think of 
> the simplest, most direct way to accomplish what is needed.
> However, when writing Java, I find that I think more of 
> correct object abstraction for the problem at hand, code 
> reuse, classes that maintain consistent state. I don't think 
> twice of using a HashMap if it happens to be convinient, or 
> that inheritance will cause extra indirections at runtime.
> To summarize (and to get to the question already) - the point 
> is that language shapes thought. In other words, a program 
> designed in Java will naturally tend to be slower then a 
> program designed in C, simply because Java most naturally 
> expresses slower designs then C does. And the question is - 
> does this agree with anyone elses experiences? And if it 
> does, is it a valid argument against using Java for the 
> design and implementation of the VM?
> </constructive_interest>
> Regards
> -dmitry

I understand your logic, but I think it is flawed. Evidence shows that
Java code running in modern VMs is coming increasingly close to
hand-optimized solutions. One of the reasons often given for this is
that a Java program often expresses the aim of the program at a "higher
level" than an optimized C program, which gives the VM more room to
optimize it.

There are plenty of examples of "optimized" Java code becoming slower
than non-optimized code when a new VM came out because the VM can do a
better job optimizing than the programmer can.

In the area of VMs benchmarks like http://www.shudo.net/jit/perf/ shows
that the Jikes RVM (a pure Java VM) is very comptitive with other open
source VMs. 

I believe that Mono (the Open Source .NET implementation) is written
mostly in C#, and its performance is also very competitive.

As Bob Griswold said earlier:

"The performance of the VM doesn't actually matter that much in a
long-running application. It might make the code generation cycle faster
(leading to faster start-up time, but not if it takes time to optimize
VM) or GC's to happen faster, but the VM code takes up typically less
10% (usually far less than 10%) of the overall application performance
so even if you double the performance of the VM, you will only get a
improvement in overall application performance."


IMPORTANT: This e-mail, including any attachments, may contain private or confidential information.
If you think you may not be the intended recipient, or if you have received this e-mail in
error, please contact the sender immediately and delete all copies of this e-mail. If you
are not the intended recipient, you must not reproduce any part of this e-mail or disclose
its contents to any other party.
This email represents the views of the individual sender, which do not necessarily reflect
those of education.au limited except where the sender expressly states otherwise.
It is your responsibility to scan this email and any files transmitted with it for viruses
or any other defects.
education.au limited will not be liable for any loss, damage or consequence caused directly
or indirectly by this email. 

View raw message