Java vs C++

General Discussions
#21
Uhm, being both a user of Netbeans & Eclipse I can certainly say that Eclipse isn't always as fast as most belive (sure the common case of 10 files makes it seem fast).

Generally Netbeans is slower than Eclipse, because it is SO much more feature packed! And is a lot more extensible than Eclipse!

Try working everyday with both programs. You will quickly realize that Eclipse is faster to open files and whatnot. But in terms of actually producing stuff, Netbeans is far better.

The perception of performance is very subjective!
I have a relatively fast computer - so both run fast. Thus I only care about what makes it easier for me to develop in.

Generally for simpler projects, Eclipse is better - but for J2EE and other complex stuff - NB is quite a bit better.

My main gripe with Eclipse:
Even a simple thing as cvs over ssh using plink (source forge projects, typically) doesn’t work using Eclipse! You need to use they’re “special” cvs thingy, rendering commandline unusable. Supposedly working on this though…

Ohh and not forgetting:
SWT is much faster than GTK2, Motif or Photon. This also has to be evaluated when selecting an IDE.
</OT rant>

#22

Bringing us back to the topic: you can use NetBeans to write C++ code :slight_smile:

#23

Netbeans lack refactoring tools. :frowning: That’s the main reason I use Eclipse. (And I HATe the Netbeans UI structure - it’s near impossible to configure the dang thing.)

In general (staying on topic) the tools for Java are better than for C++ I find… sure Visual Studio .NET is nice… but ti lack refactoring tools as well. The reflection information in Java class files makes some advanced tool development much easier in Java. Like auto code completion of methods for which you don’t have the source code etc…

#24

I use NetBeans together with RefactorIt as a plugin :slight_smile:
Very nice! But off topic again…

#25

ah, and, talking about IDEs… for C++, there is Studio.NET.

For Java, there is NetBeans, Eclipse, JBuilder, IntelliJ, JCreator, CodeGuide, Together … and you can all use them on the same project!! Choose your personal IDE of the day!

#26

IDEA! IDEA! IDEA! IDEA! ;D

That is all.

Sorry for the above silliness…

Moving BACK to the original topic of this post, I would like to ask you folks WHY this issue of Java versus C++ keeps coming up (aside from the obvious answer of new people who just become aware that this is a seven year old debate)? From a market perspective, is this REALLY such a big deal?

I’m very aware the number of commercially available Java-based games can probably be counted without taking off my shoes. :wink: Nevertheless, does Java still have the stigma amongst developers (not the users, they haven’t a clue - no disrespect meant) that it’s not usable for games?

#27

It’s all well and good having an idea but it doesn’t help if you don’t tell us what it is :stuck_out_tongue:

I think the java + games stigma is caused partly by applets and partly by the fact that no-one has written any mainstream large scale games in Java yet. I’m fairly sure they will, though.

#28

Not until, I suspect, we get a few much wanteded features in the language and JVM, these being: static import (so code looks natural and uncluttered to migrating C/C++ programmers); generic types, for the same reasons; and structs, to enable efficient buffer manipulation. All three of these things are effectively “missing” from Java currently, and to any sensible C++ programmer, you’d simply be taking a big step backwards to do without them.

Cas :slight_smile:

#29

I think the very nice text editor Jedit (www.jedit.org) is pretty fast, too. And it uses Swing. :slight_smile:
Usually when I showed it to new colleagues who didn’t like Java they didn’t even notice it’s been Java. :slight_smile: (on a 700 MHz PC.)

#30

naa, I don’t think specific Java features are the reason.

Gaming industry has a successful history with C++! There are the people, the tools, the know-how. C++ is proven to work and there are lots of best-practise examples. Why change? Not just bc. a poor developer says he likes one language more than another.

‘Its possible to do that in Java, too’ is no sufficient reason to change. There has to be a clear and BIG benefit!

‘Its easier to code’ helps the coder a bit, but not the customer. And the business looks at the customer!!

#31

I don’t really understand structs - I haven’t really played with C++ - am I right in thinking that they are designed to be effectively small buffered objects? In what way would java structs be different from a normal object?

#32

“Evaluating Java for Game Development”, By Jacob Marner, B.Sc., March 2002. http://www.rolemaker.dk/articles/evaljava/
Also please also have a look at the “Errata and the latest developments”.

Despite of its age of 1 1/2 years the study’s still interessting, also its benchmarks. I’m going to quote a few passages which I think are important. I won’t quote the un-tweaked benchmark versions, because if we talk about commercial game programming then it’s neccessary that the developers know how to programm efficiently in the language they choosed.

  1. 7.8 A particle simulator

The application is pretty CPU intensiv.

quote After I tweaked the programs, Java has seriously gained on C++. Java has not quite achieved C++ speed but is not very far of. This time the Jet version is the fastest of the Java versions, being about 30-50% slower than C++. The IBM VM and the Sun client VM follows just after being about 60% slower. (…)
[/quote]
2) 7.9 An object-oriented version of Life

quote After we performed the tweaking the C++ program gained about 25% in speed. The Java version became much, much faster.
The application running on the Sun JDK 1.4 server VM is 2-3 times faster than the fastest C++ version. Tweaking the Life application approximately yielded about a factor of 10 in speed! This shows just how important it is to perform tweaking of Java code, while it is not so important for C++ code. (…)
[/quote]
Today’s (complex) commercial games do use OO in a very intensive way; especially AI and that like. This is a clear pro for Java. :slight_smile:

  1. 7.10 A 3D demo

It uses OpenGL für C++ and Java (Gl4Java) and one time Java3D with Java.

quote In the chart above all the curves are clearly grouped into two distinct groups. Within each group the compilers/JVMs all perform almost identically, which make it hard to discern the individual curves in the chart.
The fastest versions are the two C++ versions. The GL4Java implementation is a little slower but they all stay within the same main group of curves. Much slower is the Java3D implementation of the demo. (…)
[/quote]
Now it would be interesting to know how Gl4Java competes with Jogl. Because one of Jogl’s main developers is Ken who works at SUN in the JVM 1.4.x Hotspot team (correct?) I’d would think that Jogl is even faster than Gl4Java?

  1. 9 Conclusion

[quote]In contrary to popular belief, Java applications are in fact not much slower than C++ applications when they have been tuned for performance. A rough estimate based on the various benchmarks would say that tweaked Java code is a little slower than C++; typically 20-50% on the average, but this is hard to tell for certain because of the large variations in the speed seen in the benchmarks. The slowdown is less in 3D applications, where performance mostly depends on the performance of the 3D hardware and not on the programming language used.
For untweaked code, Java is much slower than C++, often a factor of three or four. This makes it vital to tweak the performance critical sections of Java code.
Java increases the overall productivity of a software project with about 30% and the productivity of the code phase with about 65%. This is quite a significant increase.
This productivity increase makes Java a good choice for low-profile games and for high profile games in genres that do not rely on maximum performance to ensure sales. It is especially good for low-profile games since the cost of Java tools and libraries are significantly lower than those for C++. For high profile games that do not need maximum performance, the use of Java will increase productivity and thereby allow a better game to be produced for the same money. (…)
With the development of the Java Game Profile, the rapidly improving development tools for Java, and the still improving speed of Java virtual machines, it is likely that the viability of Java for game development will improve in the future. However, as it stands now, Java can only be used for games that do not need to be ported to consoles and only partially for games that rely on maximum performance to ensure sales.
[/quote]
One pretty important sentence I found in the study has been: [quote]One should always take a benchmark with a grain of salt since it not completely represents a full application."
[/quote]
Make that a “big grain of salt”.

The conclusion “(…) that tweaked Java code is a little slower than C++; typically 20-50% on the average, but this is hard to tell for certain because of the large variations in the speed seen in the benchmarks. The slowdown is less in 3D applications, (…)” is important because most of today’s game use 3d even if they’re isometric.
Also we’ve to consider that now we use Java v1.4.2 and I think it’s correct to say the JVM has been getting (a little bit) faster from version to version.

Well, I could imagine a full blown Java-OpenGL-game which would have approx the speed of C++ with +/- 5%, which doesn’t matter then.

Let’s wait and see. :slight_smile:

#33

[quote]I don’t really understand structs - I haven’t really played with C++ - am I right in thinking that they are designed to be effectively small buffered objects? In what way would java structs be different from a normal object?
[/quote]
Technically, a struct is identical to a class, just everything defaults to public instead of private. Structs in C++ are usually used just like C structs are, a collection of public fields, with few if any methods, and nothing private.

But, most C/C++ implementations will align the struct in memory how it was defined in source code. So you can get a pointer to a struct, and just read it in “raw”, and the data will come in in the order it was defined in source code. Or you can grab a chunk of memory, and cast its pointer to your struct pointer, and boom, instant struct object.

I don’t believe the standards have anything to say about that, and that behaviour is not guaranteed (please correct me if I’m wrong).

In Java, an object does not make that guarantee. If it has an other object defined in it, it’s really just a reference to that object which is very likely living someplace else entirely in memory. So you can’t just grab a chunk of memory in java and turn it into an object.

#34

[quote]“Evaluating Java for Game Development”, By Jacob Marner, B.Sc., March 2002. http://www.rolemaker.dk/articles/evaljava/
Also please also have a look at the “Errata and the latest developments”.

Despite of its age of 1 1/2 years the study’s still interessting, also its benchmarks. I’m going to quote a few passages which I think are
[/quote]
LOL: (in the “latest updates” found on that page)

"www.java-gaming.org (p.77)

This site was at it original launch very promising and seemed to be part of the new style with Sun Microsystems to support game developers. Unfortunately the site has deteriorated into a long series of bad excuses for missing updates and generally don’t have any content at all. Even the forums are becoming more and more deserted. The two Sun Microsystems representatives seems to use no time anymore on the community or the site.

I can only conclude that Sun’s interest in gaming is waning and Java developers should therefore not rely on game specific updates."

I have to confess, the first and second time I read the report I thought it was 70-90% rubbish, and not worth reading. The methods were unscientific, the author was clearly ignorant of a lot of the context of what he was doing, and it seemed on the whole something I might expect from a precocious school child. IIRC the approach to benchmarking was also badly flawed.

…but a lot of people seem to think it’s good, so I guess I’m just a miserable old git, who for some reason doesn’t like it. :slight_smile:

#35

If there are better reports on the topic “programming games with Java compared to C++” I’d love to quote it. I just don’t know of any.

#36

Aw you guys are too good… you already covered this prefectly and to death.

What they said :slight_smile: But here’s a few more comments.

And algorithms tuned for C run faster in C. Algorithms tuned for Java run faster in Java.

Certain types of operations are inherently faster in C (for instance random access into arrays) and some others are inherently faster in Java (memory allocation/deallocation and recursion for instance.)

For some reason, FFTs rock in Java. Everyone I know who has tried implementing FFTs in Java and C find the Java version beats the C version.

For some good C v. Java speed comparisons see this somewhhat older article:

http://www.aceshardware.com/Spades/read.php?article_id=153

And this update that updates his numbers for more recent JVMs.

http://www.visi.com/~khuber/java/JavaC.pdf

Finally I wanted to make sure you weren’t laboring under a common misconception. i heard the word “interpreter” used. Modern java VMs are NOT interpreters. They are run-time compilers. The important code is compiled, just like in traditional C, its just that the compilation happens at run-time rather then at build time. In either case what gets executed is native machine code.

In fact, run-time compilers have access to system specific information that build-time compilers generally don’t and thus can do optimizations that build-time compilers generally don’t.

#37

Btw. IMO Marner’s paper is highly flawed. I have issues with a number of his benchmarks and how he approached his analysis.

Although he did quite a job of self-marketing this paper, IMO there are much better measurement and analysis jobs out there, such as the Chris Rijk article I pointed to above.

#38

“… they blasted my paper for my inaccuracies and presumptions so they must be worthless.”

Courtesy of the JPK translator.

:wink:

#39

::slight_smile:

#40

In terms of “slow”, I believe that people refer to the start up speed instead of running speed. But they need to understand that loading an application from VM is surely slower than loading it natively. Java programs MAY start up 2 times or even 3 times slower than C/C++ programs, but the development period is much shorter than C/C++. Memory leak is another problem of programming in C/C++ while you rarely have memory leak in Java because you do NOT have to worry about allocating/deallocating memory. If you want to learn OO programming, you can start with Java no matter what kind of program you want to start with. However, if you want to know more about memory access or 3D programming, you should stick with C/C++ because I still think that Java3D is not mature for programmers to create decent 3D applications yet. But it is growing up pretty quick. Pay full attention, perhaps when you are familiar with Java, Java3D is mature enough for you to do some 3D shooting game programming. Good luck.

:wink: