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

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

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

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.

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?

At my house :)
I don't have a website yet but google pages might help me out there. The
engine is still in a very early planning/coding phase, and isn't in a
working condition yet as I've got a lot of base code work to do and I
was needing the X headers (since I'm on linux).
My original design was based off of:
http://www.geometrictools.com/
Which is the design OGRE was based off of. But I've always had in the
back of my mind to go with the approach done by:
http://openscenegraph.org/
I'm open to joining others on their engine instead of doing my own, but
a lot of them don't seem to be active. Well maybe in a month or so I
might have something to show, depends on how much overtime I have to
work at my real job.

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.

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

(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?)

At the time, simplicity. I think they thought that 16 bits was as big as Unicode
characters were ever going to get. Given that (incorrect) assumption, it was a
sensible decision - it lets you treat a string as an array of characters, which
is hugely convenient for all sorts of things. You can't do that with UTF8.
cheers
Mike

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).