Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (553)
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  
  Performance Comparisons  (Read 3889 times)
0 Members and 1 Guest are viewing this topic.
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Posted 2004-06-17 20:47:07 »

I'm surprised this hasn't been posted yet (did I miss it?)

http://www.sys-con.com/story/?storyid=45250

It's all ready been on /. for two days...

Offline princec

JGO Kernel


Medals: 366
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2004-06-17 21:25:31 »

Coz it's just another load of pointless bollocks again :/

Cas Smiley

Offline JasonB

Junior Member





« Reply #2 - Posted 2004-06-17 22:32:31 »

There should be a study done on how easy it is to make a benchmark show whatever the hell you want it to by anyone who has an axe to grind.

EDIT: just found this:  http://cpp.student.utwente.nl/benchmark/

Proving that you have to be a real dumbarse to publish anything that says X might be faster than Y, because it'll take no time at all for someone to prove you wrong.

Grin

On a related note, it does appear to have set off a bunch of blog-based diatribes from all and sundry.  From those (quite-rightly) picking holes in his methodology, to ex-syscon editors having a go at the magazine (and each other) for linking/quoting from it.  All most amusing.  Do these people have nothing better to do?  Have they not heard of "set phasers to ignore"...?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #3 - Posted 2004-06-17 23:48:08 »

yeah... it wasn't done very well.. but at least it will get a few people to update their perception of Java, just by keeping the mud slinging and exposing them to new information.

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #4 - Posted 2004-06-17 23:58:03 »

Quote
EDIT: just found this:  http://cpp.student.utwente.nl/benchmark/


Ah well that is actually quite favorable as well!  So even after fixing a lot of the issues with the initial test it still shows Java as quite competitive.  Still beating even the Intel compiler on 6 of the tests (!) and coming very close to it's performance (still beating GCC with optimizations) on others.

Overall this is still good information for people enlightened enough to update their perception of Java.  Always the best tool for the job, and this shows that Java is applicable to more jobs than many would think.

Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #5 - Posted 2004-06-18 02:54:22 »

*yawn* Smiley

So what does the benchmark show?

It demonstrates that the java kitchensink is pretty well done, that you have to do all that stuff for yourself if you need it in c/c++ and of course that c++ is damn ugly Wink

Nothing new Grin

弾幕 ☆ @mahonnaiseblog
Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #6 - Posted 2004-06-18 04:22:44 »

The pure fact that they (the C++-guys) are doing those benchmarks shows how scared they are about Java performance.

In former times, only Java-guys performed the benchmarks to show 'we can compete!'. Nowadays, THEY (the C++ guys) do the benchmarks to show 'look, we can still hold it!'.

This makes me feel very comfortable. Smiley

BTW, for FlyingGuns I never performed any benchmarks (how fast can I iterate a list?? pointless....). I just let it go and performance never has been a problem....

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline princec

JGO Kernel


Medals: 366
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #7 - Posted 2004-06-18 07:16:59 »

The only benchmark I have or need is 60 frames per second, nothing more, nothing less...

Cas Smiley

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #8 - Posted 2004-06-18 08:06:55 »

I just noticed that in the updated C++ code, created objects aren't deleted which is kinda debatable isn't it?
IMHO this really shows that it's almost impossible to do an apples-apples comparison of 2 different languages using microbenchmarks.

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #9 - Posted 2004-06-18 11:58:34 »

Quote
I just noticed that in the updated C++ code, created objects aren't deleted which is kinda debatable isn't it?

Absolutely - they were mistaken about the concept of garbage collection.  At the very least they should have put in a C++ garbage collector.  They seem to think that since you don't explicitly delete in Java then to fairly compare you shouldn't delete the objects in C++ -- idiots.  (The garbage collector is doing the 'deletes' for us you fools!!  That's not the same as omitting them entirely!)

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Mark Thornton

Senior Member





« Reply #10 - Posted 2004-06-18 12:25:04 »

They are partly right in that it would be unfair to base comparison on a Java app that was so short that it didn't need to collect anything at all. Java code should be designed so that the total space allocated over the course of the test is several times the size of the heap.
Offline princec

JGO Kernel


Medals: 366
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #11 - Posted 2004-06-18 14:05:49 »

The problem with MBs like all this is at the end of the day they test ... a program that does nothing. Imagine if you had an infinitely clever JVM and an infinitely clever C++ compiler:

> java -jar test.jar
Execution time : 0.0s

> test.exe
Execution time : 0.0s

because they don't actually do any bloody work. What a waste of everybody's time this benchmarking thing is.

Cas Smiley

Offline NVaidya

Junior Member




Java games rock!


« Reply #12 - Posted 2004-06-18 15:41:42 »

Quote
They are partly right in that it would be unfair to base comparison on a Java app that was so short that it didn't need to collect anything at all. Java code should be designed so that the total space allocated over the course of the test is several times the size of the heap.


Sigh...I agree. And have you actually tried that in any decent sized application ? I sometimes encounter GC pauses of 10s and above (on an Xmx of 300MB) and with just a few passes.

What we need at the very least is an order of magnitude more performant GC. Are the GC implementations (Sun, IBM, HP,...) the very best that are known to humankind or are there some exotic alternatives buried in the academia ? We need a selfless consortium of all the bigwigs in the industry to pool their resources to take GC to the next quantum level.

Gravity Sucks !
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #13 - Posted 2004-06-18 16:43:23 »

Quote


Sigh...I agree. And have you actually tried that in any decent sized application ? I sometimes encounter GC pauses of 10s and above (on an Xmx of 300MB) and with just a few passes.

What we need at the very least is an order of magnitude more performant GC.


I've never had a GC problem since 1.3.x, and I've worked on datasets of several times the available memory; given the current variety of GC options available on the Sun JVM's, I automatically distrust anyone who is having problems with them.

I'm not claiming you're wrong in your case, but it would seem to me that the majority of people do not need a more performant GC, given how very few of the claimed GC problems in places like this turn out to be actually the GC at fault (most are something different; many are just stupid programming Sad ).

malloc will be first against the wall when the revolution comes...
Offline princec

JGO Kernel


Medals: 366
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #14 - Posted 2004-06-18 17:51:45 »

Could still do with escape analysis and Structs! That'd give us an order of magnitude more performance, and no mistake.

Cas Smiley

Offline NVaidya

Junior Member




Java games rock!


« Reply #15 - Posted 2004-06-18 18:30:26 »

Quote


I've never had a GC problem since 1.3.x, and I've worked on datasets of several times the available memory; given the current variety of GC options available on the Sun JVM's, I automatically distrust anyone who is having problems with them.


I envy you  Smiley. You said "variety of GC options". I say that's what makes me faint-hearted to try out all of them for a *particular* JVM version, conjure up a recipe based on my heuristics, and then distribute it as sacrosanct to clients with various configurations. I agree with you that it is a worthwhile exercise to adopt better coding practices to keep the GC quiet. But playing with the options...remember Sun has marked them with an "XX".

Alright, things appear to be a little different with 1.5. In fact, Sun probably realized that the options are one too many for the mere mortals merriment, that they have this new adaptive policy. Haven't tried that yet.

In my apps. (primarily sciviz, and a little into games - blame you all !), I don't do any exotic creation of millions of objects. My requirements are mainly pretty humble - dynamically resizing primitive array lists (hand rolled by self since collections are just too awe-inspiring Smiley ). It is simply difficult to anticipate the size of the arrays - unless I go overboard. And I think that when I repeatedly allocate very long arrays (but not typically many of them) the GC appears to have some difficulty.

BTW, why is this Structs proposal still in the cold ? Sun should either evaluate it and ditch it or come up with a better equivalent.


Gravity Sucks !
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #16 - Posted 2004-06-20 19:47:55 »

Quote
Could still do with escape analysis and Structs! That'd give us an order of magnitude more performance, and no mistake.

Cas Smiley


Yeah, yeah, all my votes for structs are there already   Roll Eyes Smiley
But what exactly do you mean by escape analysis? I only heard it has something to do with allocating on stack instead of the heap which supposedly would lessen the stress on the GC, but can you shed some more light on this? How would that help performance so much?

Offline Micke

Senior Newbie




Yada-yada


« Reply #17 - Posted 2004-06-21 03:54:24 »

I think there were some words about it in http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=Tuning;action=display;num=1076185882;start=23

/M
Offline Mark Thornton

Senior Member





« Reply #18 - Posted 2004-06-21 06:12:41 »

Quote

Sigh...I agree. And have you actually tried that in any decent sized application ? I sometimes encounter GC pauses of 10s and above (on an Xmx of 300MB) and with just a few passes.

My regular job involves datasets up to 1GB or so. If the task will need say 300MB of live data, then it helps a lot to set the minimum heap size to at least that. This avoids many cycles of increasing the heap by a small amount. The current GC do a full collection before increasing the heap size, and if you start from the default minimum size heap this will happen a LOT before you get your 300MB in the heap.
Offline Mark Thornton

Senior Member





« Reply #19 - Posted 2004-06-21 06:17:10 »

Quote
Could still do with escape analysis and Structs! That'd give us an order of magnitude more performance, and no mistake.
Cas Smiley

I would be surprised if you got anywhere near that level of performance increased except perhaps in unusual corner cases. Research papers on escape analysis rarely quote much more than around 20% increase. In the early days of Java when GC was very much worse, the gain would have been rather greater, but now with improved gc for short lived objects the value of escape analysis has declined.
Offline NVaidya

Junior Member




Java games rock!


« Reply #20 - Posted 2004-06-21 09:51:17 »

Quote

My regular job involves datasets up to 1GB or so. If the task will need say 300MB of live data, then it helps a lot to set the minimum heap size to at least that. This avoids many cycles of increasing the heap by a small amount. The current GC do a full collection before increasing the heap size, and if you start from the default minimum size heap this will happen a LOT before you get your 300MB in the heap.


Oh, yes I do that all the time as a matter of sheer habit if you're referring to keeping Xms and Xmx to be the same and equal to 300MB, for instance. If you look at some of my earlier e-mails under "GC Implementation Specifics" and "Problem with OutOfMemoryError" under this tuning topic, you will notice that that's what I do. I picked up this hint, to be honest, from the Sun Performance Tuning "white paper".

Just to keep the record straight, I've been fairly vocal in claiming that Java's polymorphic method call and number crunching performances have been quite good and, if I may guardedly say so, even better than C++ in some cases with the server option.

In principle, my application should be able to handle gigabytes of data, even if not taxed typically in one shot, but certainly when run in a transient mode with hundreds of streaming datasets all within a max heap of 300-500MB or so. Each time a new dataset comes in, a dataflow network in conjunction with Java3D's scenegraph structure, updates itself automatically and allocates and deallocates memory for humble things like texture mapping to more exotic things like dynamically phong shaded haloed lines, texture advection, animation, and convolution etc.

Some of my microbenchmarks for stressing gc indeed show that the gc munches garbage as if it were the last sweetest thing on earth Smiley.

Let me know if you or folks here run into any extra-ordinary gc pauses.

Gravity Sucks !
Offline princec

JGO Kernel


Medals: 366
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #21 - Posted 2004-06-21 11:01:55 »

I think escape analysis would definitely be a boon; a 20% performance increase from their use would be fantastic for applications where GC starts to cause trouble. There are some more unusual uses for Java where the increased predictability of garbage generation and collection are very worthwhile goals too - realtime TV graphics, an area in which I work, is a constant battle against allocation. It's not actually the collection that's the problem as such, it's just that it invariably occurs when you get a new() in the middle of a frame render... and it only takes *1* dropped frame for the production team to scowl nastily and make noises about using C instead. So I have to go through my code with an ultrafine toothcomb all day long optimising perfectly decent bits of OO and replacing them with ugly bits. Consider:

1  
for (Iterator i = graphics.iterator(); i.hasNext(); ) { ((Renderable) i.next()).render(); }


Once that's been through the inliner and code profiler there is no reason for it to put anything on the heap at all. Unfortunately it might just happen that it's the straw that breaks the camel's back and it triggers a teeny little collection just at the wrong moment...

Cas Smiley

Offline Mark Thornton

Senior Member





« Reply #22 - Posted 2004-06-21 11:15:56 »

I happily concede that real time tasks could benefit from escape analysis. In general programming a more important benefit may be psychological --- it would encourage people to use Iterators and not indulge in some much premature optimisation.
Offline princec

JGO Kernel


Medals: 366
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #23 - Posted 2004-06-21 12:18:59 »

Exactly. And all those stupid, stupid, unsafe private static final Vector3fs I keep hanging around in Alien classes to do collision detection stuff would be history as well. No GC on Earth can keep up with 5,000 new Vector3fs every frame without glitching frequently but escape analysis would solve the problem instantly without compromising the code paradigms. Or somesuch.

Cas Smiley

Offline NVaidya

Junior Member




Java games rock!


« Reply #24 - Posted 2004-06-21 12:35:10 »

Quote

........
So I have to go through my code with an ultrafine toothcomb all day long optimising perfectly decent bits of OO and replacing them with ugly bits.
.......
Cas Smiley


You know....I couldn't have phrased it any better Smiley.

I try not to comment on gc issues here because somehow I got the general impression that smart gamers pre-allocate objects and gc is a non-issue. But I also feel that if at all there is some group that can legitimately take performance issues to Sun, then surely no group more well poised and qualified than this !

On a very philosophical level I keep debating to myself if sometimes predictability of performance is more important than performance itself....



Gravity Sucks !
Offline princec

JGO Kernel


Medals: 366
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #25 - Posted 2004-06-21 12:57:48 »

Predicability is nearly always more useful.

Cas Smiley

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #26 - Posted 2004-06-21 14:34:43 »

If I understand the whole concept correctly, escape analysis would also mean that many programs will allocate less memory, am I right?
Another question, if lots of temporary objects are deleted 'instantly', would that not have a negative impact on creation of those objects? I'm thinking that 'eden' stuff and such.

Offline princec

JGO Kernel


Medals: 366
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #27 - Posted 2004-06-21 14:45:25 »

Eden still has its place. Escape analysis is performed after inlining and can only be performed on small windows of code. Eden will trap those objects that fall outside the window, but which still are only very short lived. However, escape analysis will likely substantially reduce the number of objects being created in eden in the first place. The real guys to ask are Excelsior, as they've had it for quite some time in Jet and there's no denying Jet performance blows the current VM away in several areas.

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #28 - Posted 2004-06-21 15:04:25 »

Quote
I try not to comment on gc issues here because somehow I got the general impression that smart gamers pre-allocate objects and gc is a non-issue.

I for one am fed up of writing methods that take 6+ float and int args when really what they should be taking is (say) a couple of Vector2f's and a Colour4f object. Yet I'm ever so slightly paranoid that making these objects every frame for processing then chucking them away is going to make the GC eat my performance.

I suppose its only a minor gripe, but just occasionally when I get a bug because I stuck the parameters in slightly wrong is a bug I could of avoided. Embarrassed

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline NVaidya

Junior Member




Java games rock!


« Reply #29 - Posted 2004-06-21 20:42:49 »


That's a notorious bug which is oblivious to age, experience, and expertise :-). 11.00PM-3.00AM is a good time to troubleshoot those.

Gravity Sucks !
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 (16 views)
2014-08-28 18:26:30

CopyableCougar4 (25 views)
2014-08-22 19:31:30

atombrot (38 views)
2014-08-19 09:29:53

Tekkerue (34 views)
2014-08-16 06:45:27

Tekkerue (32 views)
2014-08-16 06:22:17

Tekkerue (20 views)
2014-08-16 06:20:21

Tekkerue (31 views)
2014-08-16 06:12:11

Rayexar (66 views)
2014-08-11 02:49:23

BurntPizza (44 views)
2014-08-09 21:09:32

BurntPizza (34 views)
2014-08-08 02:01:56
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

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!