Java, C#, VM Performance and Benchmarks

[Kevin Bealer]

In article <dvq3n5$1nqc$1 at digitaldaemon.com>, Craig Black says...
>
>
>"Kevin Bealer" <Kevin_member at pathlink.com> wrote in message 
>news:dvppn6$1ans$1 at digitaldaemon.com...
>> In article <dvpmc3$15sk$1 at digitaldaemon.com>, Craig Black says...
>>>
>>>There are so many people that are fooled by benchmarks indicating that 
>>>Java
>>>performs as well as C++.  Don't be an idiot!  Yes, there are programs that
>>>you can write in Java that will run as fast as the equivalent C++ 
>>>programs.
>>>These programs are typically small.  Notice that they do not use a lot of
>>>object instantiation.  In other words, you don't see a lot of "new 
>>>MyClass"
>>>in these programs.  But try to write a 3D game engine in Java.  I've 
>>>talked
>>>with some of the best game programmers in the world and they say the same
>>>thing:  Java is damn slow.
>>>
>>>-Craig
>>
>> I've talked to Java people who've said that Java is pretty fast, and the
>> performance loss is not too big of a deal.  But if you talk about putting 
>> 4
>> integers in a class and then creating a container of those, they see that 
>> as
>> just a poor design, performance wise.
>>
>> In D you can do this with struct (similarly in C++), and it doesn't hurt
>> performance at all.  In Java, I think most experienced people would unroll 
>> the
>> struct and use an array of int.
>>
>> In other words (if this anecdote is true in general), experienced Java 
>> folk see
>> performance coding as a matter of getting rid of abstractions (i.e. class
>> definitions and the associated objects), because proliferating objects is
>> expensive in Java.
>>
>> D (and C++) allow you to keep these abstractions at no runtime cost, but 
>> the
>> language is a bit more complex (or in the case of C++, much more) by 
>> virtue of
>> having the extra syntax to make it possible.
>>
>> Kevin
>
>Abstraction is priority one when it comes to maintaining code, especially if 
>you have a lot of it.  If when using Java, I have to give up abstraction in 
>order to get performance, then my high performance Java code becomes less 
>maintainable.  I would definitely rather have the abstraction without the 
>performance hit.  D syntax is not much more difficult than Java.  Further, 
>it has much more expressive power.  Thus, for high-performance coding, and 
>for maintainability, D is the best choice.
>
>-Craig 

Yeah - I agree.

I guess my point is that programmers tend to adapt to their environment as well
as adapting their environment to their needs.  The first direction is the path
of practicality, the second idealism.  Once upon a time, C programmers accepted
a loss of performance relative to FORTRAN or assembler, C++ programmers accepted
name mangling and no ABI, and Java programmers accept the fact (those that are
aware of it), that a tradeoff exists between abstraction and performance, even
when it doesn't in other languages.

(And in many cases Java isnt this tradeoff, it just throws a little performance
or power out the bus window, e.g. using UCS-16 instead of UTF8 (what is the gain
here?), or having no unsigned types (simplicity I guess).)

Fact is, for most people, the existence of that (unnecessary) Java specific
tradeoff is acceptable, and so is the included tradeoff of losing performance in
exchange for abstraction 80% of the time and vice versa the other 20.  Sometimes
what they get in exchange, is job opportunities in a larger job market.  For
others, the benefit is not having to fight C++'s sometimes infuriating drowning
in details feeling.

And then there are those who see a way to build a language that has both parts
and thus defeats the tradeoff.

Kevin