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

In article <dvpmc3$15sk$1@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

"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message news:dvppn6$1ans$1@digitaldaemon.com...
> In article <dvpmc3$15sk$1@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

Craig Black wrote:
> "Kevin Bealer" <Kevin_member@pathlink.com> wrote in message news:dvppn6$1ans$1@digitaldaemon.com...
> 
>>In article <dvpmc3$15sk$1@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 
> 
> 

Since we're talking about maintainablility vs performance, and someone just mentioned video games.

I was thinking, maybe a game engine can be a killer D app. It can demonstrate both the high performance and maintainability advantage that D provides.

Game engines are complicated, many game engines use very bad coding practices to gain performance (i.e. sacrifice maintainability in favor for performance).
Some people try to use Java to overcome the maintainability issue, but in the end they sacrifice performance.

I think D can win over both C++ and Java in this field (and in many fields, actually). What I'm trying to say is, I think a game engine can be a killer app that grabs everybody's attention towards D.

Craig Black wrote:
> <snip> 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 
> 

Here are some interesting aspects of Java game development.

1) Quake2 in Java achieves ~85% performance of the C version : http://www.bytonic.de/html/benchmarks.html

2) An interesting blog post about programming Java on cell phones : http://www.armadilloaerospace.com/n.x/johnc/Recent%20Updates

Hasan Aljudy wrote:
> I was thinking, maybe a game engine can be a killer D app. It can demonstrate both the high performance and maintainability advantage that D provides.

Working on it...

"Hasan Aljudy" <hasan.aljudy@gmail.com> wrote in message news:dvq9ds$1uca$1@digitaldaemon.com...
> Since we're talking about maintainablility vs performance, and someone just mentioned video games.
>
> I was thinking, maybe a game engine can be a killer D app. It can demonstrate both the high performance and maintainability advantage that D provides.
>
> Game engines are complicated, many game engines use very bad coding
> practices to gain performance (i.e. sacrifice maintainability in favor for
> performance).
> Some people try to use Java to overcome the maintainability issue, but in
> the end they sacrifice performance.
>
> I think D can win over both C++ and Java in this field (and in many fields, actually). What I'm trying to say is, I think a game engine can be a killer app that grabs everybody's attention towards D.

Me too.. ;)

And so is BCS, and on quite a sophisticated one, if I remember correctly.

Lucas Goss wrote:
> Hasan Aljudy wrote:
> 
>> I was thinking, maybe a game engine can be a killer D app. It can demonstrate both the high performance and maintainability advantage that D provides.
> 
> 
> Working on it...

where?

In article <dvqb9h$20j6$1@digitaldaemon.com>, clayasaurus says...
>
>Craig Black wrote:
>> <snip> 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
>> 
>
>Here are some interesting aspects of Java game development.
>
>1) Quake2 in Java achieves ~85% performance of the C version : http://www.bytonic.de/html/benchmarks.html
>

I just couldn't help it... Had to add - because I've seen this before - that they've apparently undergone a large amount of effort in tuning the Java code, but have not tuned the C version along side it (because chances are that quite a few of the algorithmic changes are applicable to the C code as well).

Plus there isn't any details - like how the C version was built. I know of a project not too long ago where they burned a lot of cabbage on tuning a Java app. in a few bottleneck areas. There happened to be some overlap with another (C++) application, and a while later the Java developers said "Ah-Ha!" it's even *faster* and went and had a beer. The C++ team came in the next morning, added '-O2' to the make files, removed some instrumentation, rebuilt, and ... some of the Java ended up being converted to C++.

Don't get me wrong - the Bytonic stuff is cool, and perhaps is a 100% legitimate comparison, but I get the feeling that type of stuff goes on a lot (with a lot of things, not just Java).

>
>2) An interesting blog post about programming Java on cell phones : http://www.armadilloaerospace.com/n.x/johnc/Recent%20Updates

In article <dvq3n5$1nqc$1@digitaldaemon.com>, Craig Black says...
>
>
>"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message news:dvppn6$1ans$1@digitaldaemon.com...
>> In article <dvpmc3$15sk$1@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