Quote:Original post by nmi

Quote:Original post by Christian Weis
The most disadvantage of java for me is that you cannot create objects "on the stack". The stack is the fastest memory allocator and GC available on all platforms and languages. It's a shame the java ignores this fact.
So all objects that are only needed within a method-scope per example need to be garbage collected. Placing such objects on the stack like in C++ would unburden the GC dramatically and also increase performance a lot.

Another drawback is the lack of operator overloading. Especially when deadling with highly mathematical software like 3d games with lost of linear algebra. Defining all vector/matrix operations as operators would increase readability. Java doesn't support this because it doesn't belong to OOP.

...
Since most objects only survive for a short amount of time, only very few data needs to be copied when the heap is garbage collected. So there really is no need to store objects on the stack.

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.

Quote:Original post by nmi
Operator overloading is not part of the java language right now, but implementing operator overloading in a java-compiler is not that complicated:
http://www-gs.informatik.tu-cottbus.de/grogra.de/xlspec/ch11s02.html#s-operator-methods
(XL is a language that extends Java by some features)

This is interesting to read but it shows the problem with GCs. If you look at the code:

Complex operator+(Complex b) {  return new Complex(this.real + b.real, this.imag + b.imag);}

Everytime two complex numbers are added there's a new object allocated that needs garbage collection. That's pure unnecessary overhead. The same problem occurs with string concatenation via "+"-operator. That's why many people use the ugly StringBuffer instead because of this issue.

cu,
Chris

Quote:Original post by Shabadoo

Quote:Original post by shamy
... java programs are alot slower then the programe being developed in c++

eesh... do we have to go over this again? C++ is faster in some cases, Java is faster in others. If you like Java use Java, if you don't, use C++ (or Python, C, VB, Delphi, COBOL, etc).

Quote:Original post by shamy
and where is java language best used?

Everywhere, of course(*).

Cheers,
Brett

(* This opinion may not be relevant to the real world)

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.

From someone's view who has been following Java for past five years Java has always been in the future. Java will be this and Java will be that and the performance WILL be greatly enhanced. The major problem, however, is that while Java has gotten faster and the library is great, it is not exactly built for game programming.

Simultaneously Sun isn't a big enough player to focus on game programmer's needs. They rely heavily on volunteer work and the small games community is excellent. Sun focuses on enterprise development and quite frankly all this talk about the great future of Java is inane drivel. It has always been that way and nothing has happened. I like the language and the library, but the performance needed for cpu heavy games just isn't there.

For the type of stuffs I'm doing... it's all the same. I don't do all that much high end stuffs either. The only disadvantage I got is not being able to fall back on the native APIs for applets. That's about it. In the long run, I found other ways to do what I want without resorting to the native system.

I suppose I've gotten really lazy with memory micro-management. That being indirectly due to me not caring about the garbage collecting since most of it's automatic and all.

I still enjoy a good language holy war though.

I like the above post.

And truthfully people, most of the money of the game industry is in console games and MMOs - all of which (that make lots of money) are written at least partially in C or C++ today.

But:

1. Most of us are never going to work on those big money projects.
2. Most of us will write several games between now and then.
3. Almost any current technology is "good enough" for most games.
4. The industry is constantly improving and changing, so 10 years from now our Direct X 3 knowledge won't be so important, and our Python / LISP / Java / whatever skills will come in handy to whatever extend WE the programmer can leverage them, based less and lesss on machine cost, and more and more on our personal abilities to turn ideas into output.
5. With the rise of multi-core and higher thread counts, the industry is in a development / design paradigm shift right now. 5 years from now whatever language you are in, the ability to paralellize code well will be more important than the ability to get 100% performance from each thread. And hopefully new language constructs (or whole languages) will be built to facilitate this.
6. Getting something DONE is more important than starting something the "right way" (TM).

So code whatever interests you, in whatever language you like, that best allows you to enjoy your life, express yourself and share your visions with the world.

If your game rocks, most people will forgive you if it takes twice as much memory to run (higher level abstraction people).

If your game rocks, most people will forgive you that you spent twice as long optimizing the code as necessary (lower level code-to-the metal people).

Personally I do it all, I write in C++, C#, and ruby ... each depending on my interest and mood for the day / project.

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.

A GC would free these as soon as they're dead and the memory they take up is needed.

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

[Edited by - Ahnfelt on April 26, 2007 1:59:42 PM]

First things first, kudos to everyone for the civility in this discussion. It's great to see some real talk about this issue.

Quote:Original post by Christian Weis
Since most objects only survive for a short amount of time, only very few data needs to be copied when the heap is garbage collected. So there really is no need to store objects on the stack.

You can get around this stack problem by writing your own. In my last project I used an array stack of objects and then popping off as many as I need (I returned them to the stack myself, though you could probably write a manager to do it for you). I believe this is called using an "object pool", though I'm not entirely too sure on this one. Picking better data structures and algorithms helps get around these as well in all languages.

The thing about Java is that sometimes you might need to do things a little creatively to get around the GC, and some speed issues. When doing Java2D, I found out it was faster when using lots of translucency to throw in another buffer to render to, and then to blit that buffer to the back buffer, so in essence using triple buffering. (the following week I picked up LWJGL)

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.

I understand what you mean about speed, but could you elaborate about how works? If you're using a lot of method calls (i.e. accessors such as "gets" for rectange widths for example), remember that all methods in Java are dynamically bound, which means things can a tad bit slower. Also, short-lived objects can be slow (though there may have been recent improvements on this).

Quote:Original post by Captain Goatse
The major problem, however, is that while Java has gotten faster and the library is great, it is not exactly built for game programming.

I totally agree. However, there are a number of free 3rd party libraries that are good for game programming (I'm thinking LWJGL, and GTGE). Java's simple syntax made it easier for a somewhat clumsy person like me to pick up the language quickly since it doesn't suffer some nasty bizarre syntatical issues.

In short, which language you use should depend on what you're trying to do, and when you go about attacking the solution you need to play to the language's strengths (e.g. in Java you might want to go to native calls for really intensive number crunching).

Maybe someone could assemble hints about innovative solutions around some of Java's craziness?

Quote:Original post by lightbringer

Quote:Original post by pinacolada
In terms of raw speed- I know that Java can in theory be faster than C++ because they do lots of optimizations that C++ can't do. I don't think the reality has caught up to this theory yet, maybe some day it will.

When making a statement like this, can you also provide the basis for this statement? I'm not saying it's right or wrong, just wondering what exact data you're basing it on.

Sure, well I guess my primary data point is my experience using large Java apps, such as Eclipse and IntelliJ IDEA. Both these editors feel sluggish when responding to user input, especially after they've been running for a while. Their C++ counterpart, Microsoft Visual Studio, always feels lightning fast.

I'm sure that the Eclipse and IntelliJ people are all expert Java programmers, so in this case it seems fair to blame the platform for the sluggishness.


On a similar topic, all this talk of performance makes me think of another Java disadvantage: writing high performance Java code requires too much Java-specific knowledge.

C++ was always designed to be no more high level than necessary. And so there's nothing going on "behind the scenes", the program does what you tell it to and doesn't do what you don't. To put it another way, an expert programmer, who doesn't actually know much about C++, can walk up to a C++ compiler and write high performance code (if his algorithms are good).

Java on the other hand, has tons of stuff going on behind the scenes. And our expert programmer (who also doesn't happen to know much about Java) can't just walk up to a Java compiler and write fast code. He needs to be an expert at Java. He needs to understand all those runtime flags for specifying the behavior of the garbage collector. He needs to understand generational garbage collection, so that he can avoid letting objects unnecessarily survive to the old generation. He needs to know to use ByteBuffers when using JNI code. And the list goes on..

To make it worse, the rules of the game keep changing. Before 1.2, Java programmers were told that allocation was slow and they should use object pools. Now object creation is fast and object pools are bad. Escape Analysis didn't exist until 1.6. Now it does exist, and programmers should write code to take advantage of it. It's a lot to keep track of!

The expertise problem is an issue, say, if I'm running a company and I'm considering doing an entire AAA game in Java. Am I going to be able to find and hire 10 to 20 expert Java programmers?

Quote:Original post by pinacolada
Sure, well I guess my primary data point is my experience using large Java apps, such as Eclipse and IntelliJ IDEA. Both these editors feel sluggish when responding to user input, especially after they've been running for a while. Their C++ counterpart, Microsoft Visual Studio, always feels lightning fast.

Keep in mind that Eclipse is doing a hell of a lot more as you're typing than Visual C++. It's recompiling code on the fly.

Quote:C++ was always designed to be no more high level than necessary. And so there's nothing going on "behind the scenes", the program does what you tell it to and doesn't do what you don't.

The hell it does. Tell me: What happens when you do dynamic_cast? If you can tell me in less than 1000 words, you're wrong.

Quote:To put it another way, an expert programmer, who doesn't actually know much about C++, can walk up to a C++ compiler and write high performance code (if his algorithms are good).

Er, once you've explained to him when he should pass by reference and when he shouldn't, and when he should throw exceptions and when he shouldn't, and when he should use endl and when he shouldn't, and the difference between std::find and std::set::find, and when he should use std::vector instead of std::list even when he's doing a lot of middle-insertion. Oh, and don't forget to explain to him all the different common idioms for memory ownership transfer and how to recognize them and when he should use shared_ptrs and when he shouldn't.

And maybe that big ol' heap of gotchas is bigger than Java's big ol' heap of gotchas, and maybe it isn't. The bottom line is, any decently complicated programming language (and C++ is, heh, "decently complicated") will have such a heap. Throwing around a statement like "Java needs more special-purpose knowledge to obtain good performance" without real-world measurements is pulling facts out of your butt.