Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (542)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (606)
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  
  Performance Myths  (Read 10774 times)
0 Members and 1 Guest are viewing this topic.
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Posted 2003-05-18 15:12:56 »

Great article here http://www-106.ibm.com/developerworks/java/library/j-jtp04223.html?ca=dgr-lnxw01JavaUrbanLegends

Offline Herkules

Senior Devvie




Friendly fire isn't friendly!


« Reply #1 - Posted 2003-05-18 15:25:39 »

Very good article. There are far too many myth around that make people tweaking thing before they ever get a problem....

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

Senior Newbie





« Reply #2 - Posted 2003-05-18 18:33:27 »

The article says these 3 things are legends:
1. Synchronization is really slow
2. Declaring classes or methods final makes them faster
3. Immutable objects are bad for performance

Yet, it doesn't show any measurements showing that they really are legends.

There is a lot of discussion about this article on Slashdot:
http://developers.slashdot.org/developers/03/05/17/175255.shtml?tid=126&tid=156&tid=108

For example "jdennett" tells that these 3 things were the main performance problems in his project (using J2SE 1.3):
1. Synchronization
2. Object creation
3. Immutable objects

He also says: "Funny that the article "debunks" these myths without figures, when our thorough measurements showed that the problems are real, and in our case would have killed our chances of meeting performance targets had we not found them and dealt with them."

I haven't done any measurements related to these things myself, so I'm not saying what is right and what is wrong. I am just saying that I only trust  performance measurements (well not even all of them), not words  Wink
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

« JGO Spiffy Duke »


Medals: 439
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #3 - Posted 2003-05-18 22:12:11 »

Hm, the advice in the article is rather like giving fireworks to children.

It doesn't matter how slow synchronization is, for example: you use it because you have to use it, not because it's fun to type 'synchronized'.

And whereas I don't think declaring a method final makes them faster, I have a feeling it speeds up Hotspot's compilation because it doesn't have to think quite so hard about whether a method is or isn't final.

And as for mutable objects - well, the example in the article is just plain daft. The guy should try writing a game, and then he'd know about performance and optimisation and the perils of excessive object creation.

Different strokes, innit? A J2EE programmer wouldn't know performance if it poked him up the arse with an immutable instance of a final class.

Cas Smiley

Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #4 - Posted 2003-05-18 22:36:25 »

Quote
I have a feeling it speeds up...


Now you're doing it... Smiley

In terms of making methods final... while it is possible that such a thing would make it easier for HotSpot to optimize, my own measurements have shown no effect on the performance when adding the final keyword.

True that enterprize apps have different performance goals, but the main thing is not to base things on guessing when you have performance tools like profilers to give you real information.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #5 - Posted 2003-05-19 18:06:33 »

Indeed; I spoke to the author specifically about the object-creation situation, and cited a few examples (in the java.* libraries) where the overhead for object-creation is so mind-bogglingly huge that it can single-handedly destroy your app (i.e. make performance go from great to so completely dog slow that you can't actually use the darn thing).

His view was that these examples show why the main thrust of his article (don't trust myths, write it properly, then optimize only what your profilers tell you to) is so important.

I think, in light of that response, that the article could more accurately be described as "don't assume you actually have a clue what is fast and slow in the esoteric details of compiled code" - but the actual title is a lot more attention grabbing Smiley.

For me, this happens to relate to when we were talking about articles we'd like to see on JGO, and I said I'd like someone to do a regularly-updated column on the evolution of the JVM's. Stuff like "Hey, 1.4.5 is out, and the following optimizations aren't worth doing any more (they don't work) and bugfixes mean you can get rid of the following workarounds". Well. that's probably way too hopeful - but even just a regular article (in the same format each time) for each and every point release would make life sooooo much easier.

e.g. I recently realised I no longer had a clue what the threading model was for java - what percentage of it is handled by the OS scheduler, and what percent by java etc. Current API docs and tutorials at java.sun.com suggest there is a crap java scheduler by design in every JVM (one of the tutorials in particular actually states various things along the lines of "no java thread does/can do this" which is only true if they all use an old scheduler); my memory of how it used to work was that you were scheduled by the OS, UNLESS your OS was too rubbish to have a decent pre-emptive scheduler, and hence your java implementation simulated one for you.

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

Junior Newbie




Don't believe everything you read.


« Reply #6 - Posted 2003-05-21 18:29:45 »

Quote


He also says: "Funny that the article "debunks" these myths without figures, when our thorough measurements showed that the problems are real, and in our case would have killed our chances of meeting performance targets had we not found them and dealt with them."

I haven't done any measurements related to these things myself, so I'm not saying what is right and what is wrong. I am just saying that I only trust  performance measurements (well not even all of them), not words  Wink


I made a deliberate choice to omit numbers from the article.  Why?  Because that would probably just create tomorrow's urban performance legends.  Any numbers I posted would be specific to my hardware configuration, JVM, whether I have enough memory to avoid garbage collection during the benchmark run, and all the other factors that bias microbenchmarks.  It would be out of date tomorrow.  

Instead of just believing "X is slow" and "Y is fast", I was hoping to encourage people to take responsibility for their own applications, through measurement, not guesswork.  You're right -- you shouldn't believe me.  Try it for yourself.  

I don't claim that my article authoritatively "debunks" any of these myths.  But if I've motivated just a few readers to try measuring something for themselves, then this article has succeeded.  
Offline BrianGoetz

Junior Newbie




Don't believe everything you read.


« Reply #7 - Posted 2003-05-21 18:34:44 »

Quote
Hm, the advice in the article is rather like giving fireworks to children.

It doesn't matter how slow synchronization is, for example: you use it because you have to use it, not because it's fun to type 'synchronized'.



And I thought I was trying to take the fireworks away from the children.  Did you misread the article?  I thought i stated pretty clearly that (a) performance was a bad reason to compromise the thread-safety of your code, and (b) said compromises probably won't have the performance benefit you think it will anyway, so don't bother.  

You are correct, synchronization (where needed) is not optional.  And knowing where its needed is often hard to figure out.  The performance impact, real or imagined, should not enter into that determination.  

However, many developers are far too willing to compromise the thread safety of their programs because they think that doing it right will be too slow.  By offering some balance to the "synchronization is so slow that we can't even think about using it" myth, maybe people will be less likely to give in to their tendency towards premature optimization.

Offline BrianGoetz

Junior Newbie




Don't believe everything you read.


« Reply #8 - Posted 2003-05-21 18:38:34 »

Quote

I think, in light of that response, that the article could more accurately be described as "don't assume you actually have a clue what is fast and slow in the esoteric details of compiled code"


That would have been a good title, had I thought of it, but of course the editors wouldn't have let me do that.  

But thank you for stating my point more clearly than I did  Smiley

Offline princec

« JGO Spiffy Duke »


Medals: 439
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2003-05-21 21:35:28 »

I did think it was a good article generally! But the object creation example doesn't really work out with the current state of play in Java games development, which brings me back to kids and fireworks. What'll happen is someone will try writing a game and create tons of objects and then complain that the garbage collector is crap (which is exactly what's happened) when in fact it's not crap at all! There's just different and better ways to do things when writing games. (Perhaps you could add a footnote to the article and put your comments you've posted in here in it? Because they shed a subtly different light on a good article which is perhaps easily misinterpreted)

Cas Smiley

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

Junior Newbie




Don't believe everything you read.


« Reply #10 - Posted 2003-05-22 03:24:51 »

Quote
(Perhaps you could add a footnote to the article and put your comments you've posted in here in it? Because they shed a subtly different light on a good article which is perhaps easily misinterpreted)

Cas Smiley


After the brutal coal-raking I got on slashdot, I've been thinking about doing a follow-up where I can clarify some of these issues.  From what I saw on /., its a lot easier to misinterpret than I thought!

I do focus almost entirely on server-side issues -- I often conduct performance audits for consulting customers.  So what I say in the article is drawn from mistakes I've seen in the field, which is server applications.  

The point you make about game development, which is pretty different in character from server-side apps, fits pretty well into the point of the previous article ("Performance management -- do you have a plan?"), which is before you try and tune, know what your performance objectives and requirements are.   Game development is one of the areas where these requirements are easiest to quantify (doesn't make them easy to achieve, though.)  

Cheers,
-Brian

PS Thanks to all on this board for engaging in a much more intelligent and respectful debate than the folks on Slashdot.  Makes me want to lurk here more often.  
Offline Abuse

JGO Knight


Medals: 15


falling into the abyss of reality


« Reply #11 - Posted 2003-05-22 06:42:20 »

hehe, u can blame me for sending you the link to here Grin

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #12 - Posted 2003-05-22 09:58:20 »

Quote


That would have been a good title, had I thought of it, but of course the editors wouldn't have let me do that.  

But thank you for stating my point more clearly than I did  Smiley



Smiley I've preached the same points myself, having learnt both from experience and some good teachers. I did wonder for a moment whether I was describing a summary of your article, or a summary of the article I would have written myself Wink

On a related note, there was a thread a while back on compiler optimizations:

http://www.java-gaming.org/cgi-bin/JGOForums/YaBB.cgi?board=Tuning;action=display;num=1035780858;start=30

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

Junior Devvie





« Reply #13 - Posted 2003-05-22 14:40:13 »

Quote

The point you make about game development, which is pretty different in character from server-side apps, fits pretty well into the point of the previous article ("Performance management -- do you have a plan?"), which is before you try and tune, know what your performance objectives and requirements are.   Game development is one of the areas where these requirements are easiest to quantify (doesn't make them easy to achieve, though.)  
 


Exactly!  Performance goals can be very different depending on what kind of game you are writing.  There's vastly different performance requirements for:

1) Single-player video games
2) Mobile games
3) Persistent worlds

And also different genres: action vs strategy vs FPS vs puzzle.

For example, for the MMO strategy game we're working on, transactional reliability for certain types of network messages is more important than latency or per-message throughput.  And the 3D portion of the client has different performance requirements than the 2D portion.  And the server-side AI has different requirements than the client-side AI, etc, etc, etc.

And all of those requirements are very different than for a standalone shooter game.

Make it run, make it run correctly, make it run fast -- in that order!

Offline Mamoulian

Senior Newbie





« Reply #14 - Posted 2003-06-20 18:34:52 »

From my last large project I just noticed one difference: methods with final attribute do speedup in 1.1.8. Maybe it was the special implementation (Lotus Notes server and servlet enfgine with 1.1.8 )...

With 1.3 I couldn't see a real difference
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #15 - Posted 2003-06-23 12:50:57 »

That makes sense.
You shouldn't use the final keyword to speed things up, but only for design reasons.
Recent hotspot versions are smart enought to do clever inlining (to optimize) without using the 'final' keyword, where older implementations used the final keyword to do such optimizations.

Erik

Offline Jeff

JGO Coder




Got any cats?


« Reply #16 - Posted 2003-06-24 21:15:48 »

FWIW

I'm going to jump in here and defned the author.  In general I agree with the statements listed on the top assuming you are ina modern VM environment (IBM or Sun JDK 1.3 or better.)

I just "love" guys who post "I tried to write a Java program once. It was slow, java sucks."  Which is what your slashdot poster sounds like.  Lets we forget the first program ANY of us wrote in ANY new environment sucked.  the problem wasn't the environment but rather our own knowledge and/or expectations.

Its a whole lot like saying "I tried to cook once. It tasted awful. Fire sucks."

In particular its pretty obvious he did NOT know what he was talking about in regards to synchronization.  Since 1.3 synchronization itself has been pretty much free.  The locks arent taken until contention occurs.  Which means he had contention and THAT was what was slowing his code down.  

That means either synchronization was necessary for the code to work right at all OR he was over-synchronizing and making his code needlessly linear.  In either case its not synchronization thats the issue but how the code is written.

Or he is just totally wrong about where his bottleneck was.  Unless he carefully profiled thats a strong possability.

The most intelligent thing on this subject I've seen is the post that "trying to determine bottlenecks in a dynmaically compiled environment is difficult at run-time and nearly impossible at code-design time."  (Paraphrased, pardon me.)

The best advice for fast Java code is to write clean, clear well encapsulated code that can be tuned easily, then take a profiler to it and tune it.

Do that and you can get C/C++ level performance.




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 #17 - Posted 2003-06-24 21:19:40 »

Another common myth:

"Calling through interfaces is slower then calling through the class itself."

Totally wrong.   Based, as many of these are, on a mistaken belief that Java VMS work like C++ compilers.

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 erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #18 - Posted 2003-06-25 11:16:36 »

The problem seems to me is not that java is slow, but the fact that it is a very popular belief that it is.

At work, I always have to defend the fact that java is not the believed performance bottleneck when a client complains that 'Help, the server is overloaded! Isn't that because of the java stuff running on it?', or 'Oh no, is it a java program? It will tax my server too much, because its so slow!', or just recently 'I want it done in C++ because it will be too slow in java'.
Until now I have always been able to convince them with hard evidence like profiler output and such, but the very fact that the belief of java's bad performance is so popular is quite annoying, really.

Offline Mark Thornton

Senior Devvie





« Reply #19 - Posted 2003-06-25 12:38:41 »

Unfortunately there are still enough cases where Java is still slow to sustain the belief that it is slow in general. It doesn't help that products like NetBeans are rather optimistic with their minimum machine specification (notably with regard to available memory).
Offline EvilJohn

Junior Newbie




Less Talk, More Beer.


« Reply #20 - Posted 2003-06-26 01:21:41 »

Okay, time to un-lurk for a moment. I see a lot of programmers complain about the preception of Java performance, especially as it relates to games. They talk about a mass misconeption of java performance in nearly paranoid, Oliver Stone-like terms.

I don't really see the point. Talk will convert no one.  The Java Game that will change people's mind isn't here, and for the moment isn't even on the radar. Until someone does something outstanding, and of commercial quality deailing with negative vibes won't go away.

As an abstract, Quake3 now runs over 200 FPS on my computer. Even if Java runs half as fast as C++ (which we all know is bogus), shouldn't a Java version of the game give me 100 FPS? I wish somebody could show me this.

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #21 - Posted 2003-06-26 06:45:10 »

Quote
Unfortunately there are still enough cases where Java is still slow to sustain the belief that it is slow in general. It doesn't help that products like NetBeans are rather optimistic with their minimum machine specification (notably with regard to available memory).


Yes, you have a point there. Swing apps seem less responsive and memory hungry than native windows apps.

Quote
Okay, time to un-lurk for a moment. I see a lot of programmers complain about the preception of Java performance, especially as it relates to games. They talk about a mass misconeption of java performance in nearly paranoid, Oliver Stone-like terms.

I don't really see the point. Talk will convert no one.

The Java Game that will change people's mind isn't here, and for the moment isn't even on the radar. Until someone does something outstanding, and of commercial quality deailing with negative vibes won't go away.

As an abstract, Quake3 now runs over 200 FPS on my computer. Even if Java runs half as fast as C++ (which we all know is bogus), shouldn't a Java version of the game give me 100 FPS? I wish somebody could show me this.


I agree that java needs a real showcase to change people's minds, but you really need to back up your statements regarding regarding java's performance compared to C++. Now you're just hanging on to the myths and nothing more.

Erik

Offline EvilJohn

Junior Newbie




Less Talk, More Beer.


« Reply #22 - Posted 2003-06-26 06:55:15 »

Quote
...but you really need to back up your statements regarding regarding java's performance compared to C++. Now you're just hanging on to the myths and nothing more.


No, I don't. That's the point, I'm not wasiting my breath trying to convince people of something they do not want to believe.
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #23 - Posted 2003-06-26 07:40:31 »

Well, I was talking about real life situations where customers point to java as the source of their performance troubles. In *every* case these customers were proven wrong and java was never a bottleneck. This was not just based on words but on hard numbers. I didn't want to convince them, I simply *had* to, which can be annoying and a waste of time.

What I don't understand is that you 'unlurk' with
Quote
which we all know is bogus
statements, but don't care to back them up because you're
Quote
not wasiting my breath trying to convince people of something they do not want to believe
.
This doesn't seem very constructive.

Erik

Offline William

Junior Devvie




No Exit


« Reply #24 - Posted 2003-06-26 09:13:25 »

Quote
The Java Game that will change people's mind isn't here, and for the moment isn't even on the radar. Until someone does something outstanding, and of commercial quality deailing with negative vibes won't go away.

Why would someone who can create this kind of game use a language that won't let them port the game to consoles?
Offline princec

« JGO Spiffy Duke »


Medals: 439
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #25 - Posted 2003-06-26 09:55:00 »

Hm, didn't we rant about the console thing 2 years ago?

Cas Smiley

Offline William

Junior Devvie




No Exit


« Reply #26 - Posted 2003-06-26 10:21:44 »

Yes we did, but as long as the problem remains it's useless to dream of the kind of games that EvilJohn described. Sure, DukeNukemForever might have been out by now if 3DRealms had written it in Java, but they will probably never use Java as long as they have to rewrite the game in C++ for the PS2.

The best we can really hope for from the big-budget companies is a MMORPG (if that genre does not work out on consoles, something that I imagine might happen) or a high-performance niche game like IL-2 Sturmovik, but neither is likely to have top-FPS-quality graphics.
Offline princec

« JGO Spiffy Duke »


Medals: 439
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #27 - Posted 2003-06-26 10:54:47 »

There's no solid reason we can't have a JVM on PS2 developed by a 3rd party developer. Nor is there a good reason we can't have OpenGL drivers on it. And there's no reason the LWJGL can't be ported to run on them, giving you instant portability....

...except that I came to the conclusion that Sony-san does not want this to happen to PS it would devalue the whole product by diluting its exclusivity. How do you control franchise licensing for a Java title? How is Sony-san going to extract his yen from Alien Flux?

The conclusion we came to (and again, more recently in an interview with Java Developers Journal) runs something like this:

Me: Sony don't need a JVM in reality because it loosens their grip on the PS franchise.

JeffK: Oh no it doesn't

Me: Oh yes it does

ad absurdum in the face of absolutely no evidence either way!

But to throw a small spanner in the performance myths works here: unfortunately on every platform that isn't a desktop computer of some sort, Java performance is largely pitiful. I use CrEme on an iPaq - it's got a 200MHz ARM processor in it: it's fast but somehow CrEme manages to run far slower than the slowest of slow things. And all those little tricks like putting final everywhere and not calling interface methods unfortunately work. But it's still too damned slow to run a game on it. I could port LWJGL to CrEme really easily (once we put the 2D API together) but there's no point yet because the performance is abysmal. That's where your Java performance problems are. And you can bet if someone ports a JVM to Playstation that it'll be a big pile of slow shite that is shunned by Playstation developers. I'll put a fiver on it if anyone cares to bet me.

Cas Smiley

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #28 - Posted 2003-06-26 13:44:03 »

Quote
... And you can bet if someone ports a JVM to Playstation that it'll be a big pile of slow shite that is shunned by Playstation developers. I'll put a fiver on it if anyone cares to bet me.


I'll start a book; I'm offering odds of:

 1-10: performance is acceptably good if it's done by IBM or Sun officially
 1000-1: IBM will do it officially
  5-1: An enterprising intern in IBM's Sony-partnering group will do it and release it as an alpha product
 100-1: performance is good otherwise

...but I'm not honouring bets until I've had down payments from the first 100 peopl  Cool

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

Senior Devvie




ooh ooh eee eeee


« Reply #29 - Posted 2003-06-26 14:04:23 »

I'd like to put 5 on "Sony doesn't see Java as a viable contender and they are doing just fine as the way things are now, thank you".


Don't send a man to do a monkey's work.
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.

Elsealabs (20 views)
2014-12-28 10:39:27

CopyableCougar4 (21 views)
2014-12-28 02:10:29

BurntPizza (25 views)
2014-12-27 22:38:51

Mr.CodeIt (15 views)
2014-12-27 04:03:04

TheDudeFromCI (20 views)
2014-12-27 02:14:49

Mr.CodeIt (26 views)
2014-12-23 03:34:11

rwatson462 (60 views)
2014-12-15 09:26:44

Mr.CodeIt (48 views)
2014-12-14 19:50:38

BurntPizza (98 views)
2014-12-09 22:41:13

BurntPizza (116 views)
2014-12-08 04:46:31
How do I start Java Game Development?
by gouessej
2014-12-27 19:41:21

Resources for WIP games
by kpars
2014-12-18 10:26:14

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