Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (517)
Games in Android Showcase (123)
games submitted by our members
Games in WIP (577)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Java, C/C++, and performance  (Read 3474 times)
0 Members and 1 Guest are viewing this topic.
Offline digitprop

Junior Duke





« Posted 2005-06-08 09:31:42 »

Every once in a while, I am involved in a discussion of Java's performance, as compared to C or C++. Personal experiences vary widely, as do industry statements and research reports. While reports come up in fairly regular intervals that indicate a closing of the performance gap between Java and C++, and while some benchmarks seem to indicate a performance penalty of <1.5, personal experiences report a performance penalty more in the range of 10 to 50.

I don't use C++, and I was curious if any of you can shed some light on this matter. GUI issues apart (Swing IS slow), what do you think? I know that benchmarking is an arcane science of its own, but what is your gut feeling?

M. Fischer . www.digitprop.com
Offline kevglass

JGO Kernel


Medals: 191
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #1 - Posted 2005-06-08 09:39:09 »

Round and round in circles we go, what the answer is, nobody (really) knows!

The really nice thing about java is that you can create a proof of performance/concept in such a short time frame that you can easily check whether there will be a problem within your initial investigations, and of course the language features and stability make it far more desirable to use than C++.

That said, in my experience, having working extensively in both C++ and Java, I've not really experience any significant slow down using Java. At the micro/trivial level I've written and run some bench marks which show C++ to be considerably quicker. However, at the abstract/real problem level I find my algorithm design in Java is far better since I'm not worrying about the langauge details as much, and hence my solutions tend towards better performance and scalability.

Personal opinions, obviously.

Kev

Offline Mark Thornton

Senior Duke





« Reply #2 - Posted 2005-06-08 09:44:37 »

personal experiences report a performance penalty more in the range of 10 to 50.
What type of code leads you to that conclusion? I haven't seen a difference of that magnitude since checking someones code to find that they were comparing buffered I/O on C++ to unbuffered I/O in Java.
The other case where such large differences can arise is where the total execution time of the application is very much less than 1 second (in which case who cares anyway). If this operation is done many times, then one approach is to move the activity into a persistent process and thus pay the startup penalty only once.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 409
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #3 - Posted 2005-06-08 10:12:12 »

I generally find that if I can more or less get double the raw performance of the current client 5.0 VM if I use C++ to do the job, on things like ogg decode and so on. The server gets much much closer, sometimes faster at certain things. However there's three bugbears:

1. Startup time using the Hotspot VMs, especially the server VM, mean that anything that's otherwise only meant to take a moment in C++ tends to take 10x as long in Java. Boo!

2. There's more to performance than just speed: we might want to measure it by memory consumption, and there Java will tend to score poorly.

3. Most of us in here write the kind of code that C is ideal for - raw single threaded game logic and lots of API calls to graphics APIs. This is exactly what Java is worst at, of its many applications. Java has lots of cleverness for multithreaded and I/O applications and nifty memory allocation strategies and dynamic code execution but if you're not actually doing any of that you're left with a system that's irritatingly hobbled in a few important areas for games development.

This is not to say it's not great; it's just less than it could be.

Cas Smiley

Offline digitprop

Junior Duke





« Reply #4 - Posted 2005-06-08 15:19:32 »

Thanks for your insights. The figure of 10- to 50-fold lower performance is not mine - these are numbers people came up with in conversations. Not using C++ (although I have some C++ experience from several years ago), I was in no good position to argue. Still, I have been very happy with Java throughout the last 7 years, and I would not want to change to C++ for performance reasons if not absolutely necessary and absolutely justified by hard evidence.

You are right that the high productivity of Java makes up for the lack of performance (if there is any) for most applications.

M. Fischer . www.digitprop.com
Offline Mark Thornton

Senior Duke





« Reply #5 - Posted 2005-06-08 16:03:41 »

The figure of 10- to 50-fold lower performance is not mine
Just hearsay then. Some people haven't bothered to recheck their data for many years --- they are comfortable with their prejudices. Some even continue to quote old information quite deliberately with malicious intent.
Offline digitprop

Junior Duke





« Reply #6 - Posted 2005-06-08 20:05:11 »

Right, things can get very emotional in these advocacy debates. Still, this was from people I usually would not expect to blatantly make things up. I think part of the problem is that it is very difficult to set up a correct benchmark, especially between two different languages / architectures.

M. Fischer . www.digitprop.com
Offline Raghar

Junior Duke




Ue ni taete 'ru hitomi ni kono mi wa dou utsuru


« Reply #7 - Posted 2005-06-08 21:31:00 »

Performance between Java and Macro assembly is 51/50 - 17/21. C++ was in all tests slower than equal macroassembly. Not surprising if we would consider that algorithms were simple and possible compiler optimalization of C++ was possible to do in Macro ASM as well after education from dissasembly. ~_^  (Note I didn't included starting times or ASM would win too easily)
Best answer is it depends on programmer and computer on what it would be runned. Java programs are consistent enough to speed up, and very likely don't crash, if they are used after several years on a more recent CPU. (Slow incorporation of new things and late deprecations might be sometimes advantageous.)
Because majority of future computers would be multicore, all programs should support multiple threads. And don't forget that Mickerosoft might actually improve windoze into something that would somewhat suport preemptive multithreading. (It's still event based system that would have problems with future CPU.)

If you would like to talk with C++ persons, you might cite this:

T"he reasons for 68 kb code for a simple string on the screen isn't just a problem with STL, but a, how to talk about it, behaviour that is hard to accept by an assembly programmer. (To put it simply, you not only get your chicken, you get also your aunt, your elephant, and your ship. They are nicely lined just behind your back so you will not see them. It also add a nice box with message on top of that.)"

(The message is something about .net. It's poetical for purely C++ program.)

It would be also nice to see some examples.
Offline zingbat

Senior Duke




Java games rock!


« Reply #8 - Posted 2005-06-11 13:54:03 »

Right, things can get very emotional in these advocacy debates. Still, this was from people I usually would not expect to blatantly make things up. I think part of the problem is that it is very difficult to set up a correct benchmark, especially between two different languages / architectures.

What i was told from a reliable source is that tweaked C++ code is faster than Java code and tweaked assembler code is faster than C++ code, but the advantages are so small it often doesn't pay for the time spent tweaking it. There are a couple of cases where you are required to program in assember (like parts of the Linux kernel or graphics drivers, doom3 also had some code in assembler) but nothing i recall would be absolutly necessary for doing games in Java since the most the heavy stuff is taken care by the opengl binding.
Offline arne

Senior Duke




money is the worst drug- we should not let it rule


« Reply #9 - Posted 2005-06-25 18:42:58 »

a good algorithm is much much better than a crap algorithm in whatever "faster" programming language !!!
So in java you can more easily keep track of what you're doing, so you don't tend to making so much crap stuff, so you get maybe even faster !!

:: JOODE :: Xith3d :: OdeJava ::
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Raghar

Junior Duke




Ue ni taete 'ru hitomi ni kono mi wa dou utsuru


« Reply #10 - Posted 2005-06-25 19:49:06 »

The above mentioned people are not interested in better algorithms, they are more interested.
1. Language iching.
2. Laying shit on language they don't know, and will not use lastest version to do some testing.
3. Talking shit.
Offline zingbat

Senior Duke




Java games rock!


« Reply #11 - Posted 2005-06-26 00:26:14 »

The above mentioned people are not interested in better algorithms, they are more interested.
1. Language iching.
2. Laying shit on language they don't know, and will not use lastest version to do some testing.
3. Talking shit.

Yeaaaaaah. Java benchmarks are bigger than everyone else and balls and crap.

Given the quality of the last posts, could a moderator move this thread to the childrens forum.
Offline Raghar

Junior Duke




Ue ni taete 'ru hitomi ni kono mi wa dou utsuru


« Reply #12 - Posted 2005-06-26 10:42:00 »

We don't have children forum. They are more productive and they could be smarter by a larger margin.
Offline uj

Junior Duke





« Reply #13 - Posted 2005-07-18 15:49:10 »

There's a microbenchmark in the July 2005 issue of C/C++ Users Journal. C++, C# and Java are being compared in 18 tests.

There are four Java runtimes present: Sun server, Sun client, IBM and Excelsior. Among them the clear winner is - IBM. In all tests it's as fast as the C++ compilers.

Unfortunately the IBM Java runtime seems to be available only for IBM computers. At least that's the impression I got after visiting their homepage. Is this so?

Does anyone have experience with IBM Java? There's just one version. Is it sluggish on clients?
Offline zero

Junior Duke





« Reply #14 - Posted 2005-07-18 16:22:26 »

Some collegues and I wrote an adminstration tool for room assigments (mainly GUI and DB stuff), which had to run with a IBM JVM, some years ago.

At that time, IBM JREs and JDKs properly work on any hardware we testest it (none of them was IBM). The only drawback was that SUN already had released their JDK at version 1.4 and using IBM we had to stuck with 1.3.. On the other hand the swing implemtation was incredibly fast for that time and some minor diffrences, like both, the space and return key were default accepters for JButtons, let the users feel more familiar since it was more close to the default behavior of other (windows) apps.
Unfortunately I cannot say anything about the latest IBM JREs/JDKs, but arent't there any newer ones that version 1.4.x ?


Btw. what is your general impression about the benchmark, is it serious ?
I'm getting very curious, since the overview tells that the author is dealing with 3D hardware, software-performance evaluation, and benchmark/tool development - guess I have to buy that issue..

Best regards
-Michael
Offline uj

Junior Duke





« Reply #15 - Posted 2005-07-18 21:04:21 »

Btw. what is your general impression about the benchmark, is it serious ?

Yes it's serious but you have to draw your own conclusions because no evaluation was offered.

I'm generally quite sceptical to micro-benchmarking and don't pay too much attention but what struck me this time was the excellent performance throughout by the IBM runtime. It was a little disappointing that it seems to be available for IBM computers only.

The main reason I bought the magazine was for the article about bridging C++ and Java. To combine the strengths of both languages is probably a better strategy than to hope for one to "beat" the other in all categories.
Offline Jeff

JGO Coder




Got any cats?


« Reply #16 - Posted 2005-07-19 03:30:58 »

Performance between Java and Macro assembly is 51/50 - 17/21. C++ was in all tests slower than equal macroassembly.

Assembly exceles at tiny problems of minimal complexity.

C excels at ertain kidsn fo medium scale problems.

Java exceles at comples problems.

Any code that you could comfortably write in assembly is almost certainyl to small and trivial a case to give any meaningful Java
results.

Its that simple.

P.S.  Java beats the crap out of any C but MSVC on WIn32 for allcoation/deallocation.  Any algorithym whioch does heavy constant allocation/deallocation ash erpformed better in Java then C for a long time.   For some reason I don't fully understanbd, I've seen three C v. Java FFT shoot outs and  in each case the final maximally tuned Java beat the pants of the maximally tuned C.

You know what IQ tests measure, right?  The abiltyi to take an IQ test.  SImilarly microbenchmarks measure a systems ability to run the microbenchmark and thats about it.  They can be useful in Java ocne you have ALREADY profiled a real app and found a bottleneck in helping probe the system to understand exactly what is causing that biottleneck, but thats about it. Out of context they mean almost nothing.


Not surprising if we would consider that algorithms were simple and possible compiler optimalization of C++ was possible to do in Macro ASM as well after education from dissasembly. ~_^  (Note I didn't included starting times or ASM would win too easily)
Best answer is it depends on programmer and computer on what it would be runned. Java programs are consistent enough to speed up, and very likely don't crash, if they are used after several years on a more recent CPU. (Slow incorporation of new things and late deprecations might be sometimes advantageous.)
Because majority of future computers would be multicore, all programs should support multiple threads. And don't forget that Mickerosoft might actually improve windoze into something that would somewhat suport preemptive multithreading. (It's still event based system that would have problems with future CPU.)

If you would like to talk with C++ persons, you might cite this:

T"he reasons for 68 kb code for a simple string on the screen isn't just a problem with STL, but a, how to talk about it, behaviour that is hard to accept by an assembly programmer. (To put it simply, you not only get your chicken, you get also your aunt, your elephant, and your ship. They are nicely lined just behind your back so you will not see them. It also add a nice box with message on top of that.)"

(The message is something about .net. It's poetical for purely C++ program.)

It would be also nice to see some examples.
Quote

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
Pages: [1]
  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.

TehJavaDev (38 views)
2014-10-27 03:28:38

TehJavaDev (29 views)
2014-10-27 03:27:51

DarkCart (43 views)
2014-10-26 19:37:11

Luminem (24 views)
2014-10-26 10:17:50

Luminem (29 views)
2014-10-26 10:14:04

theagentd (35 views)
2014-10-25 15:46:29

Longarmx (63 views)
2014-10-17 03:59:02

Norakomi (61 views)
2014-10-16 15:22:06

Norakomi (50 views)
2014-10-16 15:20:20

lcass (46 views)
2014-10-15 16:18:58
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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!