Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  Java vs C++  (Read 7562 times)
0 Members and 1 Guest are viewing this topic.
Offline Breakfast

Senior Member




for great justice!


« Reply #30 - Posted 2003-07-30 12:52:15 »

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?
Archimedes
Guest
« Reply #31 - Posted 2003-07-30 12:54:41 »

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


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

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


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

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?


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


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."
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. :-)
Offline tortoise

Junior Member




<3 Shmups


« Reply #32 - Posted 2003-07-30 15:09:20 »

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?


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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #33 - Posted 2003-07-30 21:23:32 »

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


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

malloc will be first against the wall when the revolution comes...
Archimedes
Guest
« Reply #34 - Posted 2003-07-31 06:45:09 »

Quote

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


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

JGO Coder




Got any cats?


« Reply #35 - Posted 2003-08-02 05:27:36 »

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

What they said Smiley  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.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Jeff

JGO Coder




Got any cats?


« Reply #36 - Posted 2003-08-02 05:30:41 »

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.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Jeff

JGO Coder




Got any cats?


« Reply #37 - Posted 2003-08-04 23:04:13 »

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

".. they blasted my paper for my inaccuracies and presumptions so they must be worthless."

Courtesy of the JPK translator.

;)



Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline markuskidd

Junior Member


Medals: 1



« Reply #38 - Posted 2003-08-05 02:59:31 »

Quote

".. they blasted my paper for my inaccuracies and presumptions so they must be worthless."

Courtesy of the JPK translator.

;)




::)
Offline hksduhksdu

Junior Newbie




Linux + Java = Perfect


« Reply #39 - Posted 2003-08-13 02:38:50 »

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
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kfoong

Senior Newbie




umm... something...


« Reply #40 - Posted 2003-08-14 08:35:04 »

I'm quite sure that java interprets it then it compiles it...

It's true that the risk of memory leaks in C/C++ is greater than Javas because you have do allocate the memory and deallocate it, but it really depends on the programmers skill. He/She can deallocate the memory as soon as it is not needed, making the memory have more room to do stuff while java does not, not as soon as you might want it to be. Making C/C++ have more efficient memory handling. But as I said earlier, it really depends on the programmer.

But reading all of this, I am half-convinced that it is better to learn Java. Maybe I'll stay with java, Ill just make a game and see if i like it, otherwise ill go back trying to learn the complexities of C++.
Offline aldacron

Senior Member


Medals: 9
Exp: 16 years


Java games rock!


« Reply #41 - Posted 2003-08-14 08:55:45 »

Nice theory, but it doesn't really fly. I don't care how many years someone programs with C/C++ they are still going to have memory leaks *because* of the fact that they have to allocate memory manually. And this has nothing to do with garbage collection, which you seem to infer.

I recently wrote a C library of generic collections for a short course I was giving at a local institute. I have written countless linked lists and dynamic queues in the past, but even so I still found through testing that there was a leak in my circular linked list. This is one of the many reasons that I prefer Java in most cases.

Quote
It's true that the risk of memory leaks in C/C++ is greater than Javas because you have do allocate the memory and deallocate it, but it really depends on the programmers skill. He/She can deallocate the memory as soon as it is not needed, making the memory have more room to do stuff while java does not, not as soon as you might want it to be. Making C/C++ have more efficient memory handling. But as I said earlier, it really depends on the programmer.

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #42 - Posted 2003-08-14 10:41:49 »

Quote
I'm quite sure that java interprets it then it compiles it...


A C/C++ compiler also interprets and then compiles it.   Wink

Offline hksduhksdu

Junior Newbie




Linux + Java = Perfect


« Reply #43 - Posted 2003-08-14 12:35:45 »

aldacron is absolutely right.  Look at those commercial PC games, software.  They do always release new patches to fix memory leaks, do you think those software developers high school students? or lack of experience?  No matter how good  you are, even the C inventor Dennis Ritchie, memory leak is just unavoidable.  The way you can say is that experiencers know how to find and fix the memory leaks FASTER than non-experiencers.

For Java, I don't care if it's interpretted first then compiles or what, as long as the program runs well and is stable, with 2 to 5 times shorter development time than C/C++, what do you expect more?

Actually, Java is compiled first, then interpretted.  Code is compiled into bytecode, and bytecode is interpretted into machine language.

Wink
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #44 - Posted 2003-08-14 13:36:49 »

These days we just have object leaks instead which are every bit as irritating as memory leaks but fortunately a lot easier to find thanks to the debugging interface in the JVM.

Cas Smiley

Offline tortoise

Junior Member




<3 Shmups


« Reply #45 - Posted 2003-08-14 14:00:57 »

Quote

and bytecode is interpretted into machine language


If by interpretted you mean compiled, then yes.


I find it interesting that in the year 2003 the whole Java vs C/C++, particulary in regards to memory, debate is still going on. Two different approaches. Each with their own advantages and disadvantages. Different situations lend themselves to different approaches. Move on people Smiley
Offline ChrisM

JGO Coder


Medals: 1
Projects: 1


END OF LINE.


« Reply #46 - Posted 2003-08-14 16:33:53 »

Agreed!  *click*

-SG

Pages: 1 [2]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Riven (12 views)
2014-07-29 18:09:19

Riven (9 views)
2014-07-29 18:08:52

Dwinin (9 views)
2014-07-29 10:59:34

E.R. Fleming (26 views)
2014-07-29 03:07:13

E.R. Fleming (10 views)
2014-07-29 03:06:25

pw (40 views)
2014-07-24 01:59:36

Riven (39 views)
2014-07-23 21:16:32

Riven (27 views)
2014-07-23 21:07:15

Riven (28 views)
2014-07-23 20:56:16

ctomni231 (59 views)
2014-07-18 06:55:21
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!