OT, but AFAIK, all id Software games starting with glQuake have supported OpenGL. And that means all games based on the QuakeII/QuakeIII/Quake4/Doom3 engines have been using OpenGL aswell. I think you'll find that's a reasonable number of well known games, all being said...

Quote:Original post by Ahnfelt

Quote:Original post by Christian Weis
That's the point. Most objects only survive for a short period. So why not just place them on the stack. Even if generational GCs can handle them somewhat effectively, they won't do it as good as a stack can. And please note that generational GCs are very complex and therefor hard to maintain and even harder to debug. A stack would be so pretty simple and powerfull.

Actually, blindly allocating on the stack when the object only lives for the duration of a function can be quite ineffective. Consider the following C++ example:

void foo() { MyObject object(); object.doStuff(); while(...) {some long-lasting loop not using object} }

will keep object alive for far longer than it needs to be. Even worse is a recursive function that stack allocates a temporary object before the recursive call, thus filling up the stack with temporary "dead" objects.

...

But obviously stack allocation can be a speedup when used with care. It's just that it's a burden on the programmer.

Region-based memory management may be the solution, allowing most objects to be statically memory managed with little programmer interference. I haven't read the whole article yet though. Edit: eeeek, it's even more technical than I expected. Maybe I'll wait for the Wikipedia entry ;-)

I'd never sad that object's should be placed on stack blindly. And the example you've presented is correct but only for beginner/unexperienced coders. And stack allocation is not a burden but more an exoneration and more freedom of decision-making.

Quote:Original post by Ahnfelt
A GC would free these as soon as they're dead and the memory they take up is needed.

This depends on the implementation of the GC. In fact most GC's does simply nothing but waiting until a given threshold is reached. This threshold is typically 3/4 of available RAM. Generational GCs may jump in more often but the main problem of the GC in Java is:
You cannot know for sure!

Another problem of java is the high memory consumption. Every object in Java is bloated with a bulk of stuff:
- Pointer to its class
- Reflection-cache/data
- Internal statistics/data needed for HotSpot compilation
- Synchronization-objects for GC/lazy loading
- VM internal bull-shit
However there're cases where you can live without the above stuff. But in Java it's impossible to declare some kind of *naked* class.

In theory a HotSpot/JIT-compiler can do much better than a static compiler like in C++, that's true. But in practice it cannot. If you have ever compiled a multi-mio LOC application with all optimizations turned on you know that this takes hours to complete. Just because the compiler spends most of the time (90%-95%) optimizing the code. So how many time do you think has a JIT to compile a class/method in native form? Do you really think that a JIT has enough time to do fency optimizations? In fact a JIT has only few milli-seconds. Maybe some inlining here and there. Maybe some peep-hole optimization. That's it. But no time for heavy time-consuming global optimizations.

cu,
Chris

Quote:Original post by CaptainJester

Quote:Original post by Captain Goatse
I think it is a very bad idea to push this issue down because language X happens to be your favorite language, since in reality it is a issue. I just finished porting some 2d physics code from C++ to Java and I'll have to say I am very disappointed in the pure number crunching performance of Java. With the C++ application I am able to push through 500 objects that consist of a polygon easily, whereas the Java application starts struggling heavily if the number of objects exceeds 100. Same computer, same code, different languages.

And therin lies the problem. You wrote C++ code in Java, that will always take a penalty. When you are writing in a language you have to write in that language, not just copy code over fix the errors and say it's done. Any half decent Java programmer could look at your code and double it's output without breaking a sweat.

Oh please, tell me how do I increase the speed of raw calculation code by utilizing these advanced features of Java? There is only a number of ways you can do x*y. Also thankyou for making useless assumptions on my skills and the skills of the people I work with.

Quote:Original post by Ro_Akira
OT, but AFAIK, all id Software games starting with glQuake have supported OpenGL. And that means all games based on the QuakeII/QuakeIII/Quake4/Doom3 engines have been using OpenGL aswell. I think you'll find that's a reasonable number of well known games, all being said...

For purely 3D graphics yeah, but for everything else, sound, networking, input, it uses DirectX. I also think you will get more dev effort put into D3D drivers than OpenGL but thats just opinion.

Seems to me that Java means OpenGL unless you want to get into writing wrappers. Not via necessity, but just pragmatically.

S

Quote:Original post by Christian Weis

Quote:Original post by Ahnfelt
A GC would free these as soon as: (they're dead and the memory they take up is needed).

This depends on the implementation of the GC. In fact most GC's does simply nothing but waiting until a given threshold is reached. This threshold is typically 3/4 of available RAM. Generational GCs may jump in more often but the main problem of the GC in Java is:
You cannot know for sure!

Sorry for being ambigious, see the inserted grouping paranthesis for my intended meaning.

But the point is that until you've eaten up that RAM, you don't really need to free up memory.

Quote:Original post by Christian Weis
Another problem of java is the high memory consumption. Every object in Java is bloated with a bulk of stuff:
- Pointer to its class
- Reflection-cache/data
- Internal statistics/data needed for HotSpot compilation
- Synchronization-objects for GC/lazy loading
- VM internal bull-shit
However there're cases where you can live without the above stuff. But in Java it's impossible to declare some kind of *naked* class.

Apart from the pointer to it's class, I believe all of the above is stored in the class, not in the object. So it's a non-issue.

I'm more worried about the security features of Java, but I need to read up on that.

I can see where you're going with the restrictions on JIT optimization. I wonder if it caches some of the compiled native code on the disk somewhere for next time.

If you want to make DirectX games with all the goodies that come with it, and don't mind that your games only run on Windows, you should certainly use C#. I, for one, care enough about other platforms to stick to portable game libraries and Java (or maybe Scala running on the JVM).

On the topic of efficiency, it won't take long to convince me that Java does not optimize number crunching a lot - because I don't care. It's not a problem; just make sure your design allows you to reimplement the bottlenecks in C where it might be needed. That is, when everything works and you want a few extra frames per second or lower cpu usage. Anything else is premature optimization.

As for virtually any hobby coder, he won't need those extra frames per second.