On C/C++ undefined behaviours

[retard]

Sun, 22 Aug 2010 15:50:10 -0400, Nick Sabalausky wrote:

> "retard" <re at tard.com.invalid> wrote in message
> news:i4rqp4$1egl$2 at digitalmars.com...
>> Sun, 22 Aug 2010 17:50:06 +0200, Andrej Mitrovic wrote:
>>
>>> Quake 2 is a 13 year old game. :)
>>>
>>>
>> The original argument was that Java code is slow, no matter what you're
>> trying to do. What kind of performance levels are you expecting?
>>
> Nobody said that.

In my opinion bearophile spread more or less anti-Java FUD.

"That code is the "exception that confirms the rule" (I don't know how 
this is normally written in English). The rule is that Java code is 
slow ;-)"

Maybe I am not understanding what he means. To me Eclipse feels bloated 
and slow, but it doesn't tell anything about Java in general. If I buy a 
new CPU, the Java programs will run faster than C++ ones now on the 
current CPU. Why is the small performance difference that significant?

> Java apps just tend to be slower than C/C++/D ones.
> Strutting out a GPU-bound game that was well-known to run blazingly fast
> on sub-GHz hardware in *software* rendering mode, and saying "Look it's
> a few hundred fps on my multi-core" doesn't really do much to disprove
> that.

(I don't think the Pentium 2/3 desktops managed to run it that quickly. 
These were the first games that started the GPU race. It was the original 
Quake that used software rendering.)

Note that my low-end HTPC has 4.32 times the resolution and 17 times the 
frame rate of the high-end Pentium 2 I used to play the original game 
with). That's a 7300% speedup. According to Moore's law the hardware got 
6400..12800% faster during that period. So definitely Java is not a 
bottleneck in game development in these kinds of games.

I'm just asking, why software like this should be written in buggy D if 
production ready Java already executes fast enough? You must desire 
absolute hard-core super mega performance to justify the use of D.

Another question is, why would anyone use D/Phobos for writing server 
side XML intensive applications if Java is so much faster? Fixing the 
libraries first tends to be bad for productivity. If I had to choose 
between a production ready Java XML library and something half-baked for 
D, my boss would treat me as lunatic if I told him to first wait N months 
to bring the half-baked amateur library on par with Java and only after 
that write the code in this language that no other company uses anywhere. 
I'd need to work on free time to make this a reality.