On C/C++ undefined behaviours

[Nick Sabalausky]

"retard" <re at tard.com.invalid> wrote in message 
news:i4s1ft$2fed$1 at digitalmars.com...
> 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.
>

Well, I tend to feel that the "Java is fast now! Honest!" that a lot of 
people say is pro-Java propaganda. *shrug*

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

Quake 2 had both software and hardware rendering built-in. I played it in 
software mode a lot before I got my first 3D card. Quake 1 did have hardware 
mode too, although it was added as a separate "glquake" after Quake 1 was 
released. Quake 3 Arena was the first Quake to require hardware 3D (and was 
also the first id game to bore me, but that's unrelated ;) )

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

In the decade or so since that game was released, AAA games have been using 
far more polys, far more textures, more rendering passes, more physics and 
AI processing, etc. And yes, a fair amount of that is GPU-bound but the CPU 
still needs to drive it, and if you plop a modern video card into, say, a 
Pentium 2 system, it's not going to run, say, Splinter Cell or Halo very 
well, and even those are close to ten years old. So the CPU performance *is* 
still important. (Although personally, I have zero interest in whether or 
not a game *looks* any better than Splinter Cell or Halo, but unforunately, 
I seem to be in the minority on that among gamers and game devs.)

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

Well, for one thing, because D isn't anywhere near the enormous 
pain-in-the-ass that Java is. And because, like I said above, most games 
these days (for better or worse) require quite a bit more computational 
power, even on the CPU, than the Quake 2 engine did. And because id put an 
enormus amount of pioneering work into *getting* Quake to run that fast in 
the first place (a fair amount of which the Java port inherited), and devs 
don't like to have to put that much work into it to get good results.

> Another question is, why would anyone use D/Phobos for writing server
> side XML intensive applications if Java is so much faster?

Java is *not* faster at XML. Phobos just has a half-baked xml lib. Take any 
of the other xml parsers for D, even ones that haven't gotten as much time 
and energy put into optimization as the Java one has most likely gotten will 
probably still run at least comparably to Java, if not better. (And the 
D1/Tango xml parser makes it very clear that there's a LOT of room for 
improvement over the Java one).