ShannonSmith
|
 |
«
Posted
2011-05-05 17:49:53 » |
|
I was wondering if anyone has done some performance testing on the escape analysis of the latest Java VM's. I have always thought the Java math libraries were pretty clunky and the ReadableVector style interfaces to be a bit of a hack. A really nice solution would be to have immutable Vector objects but I am worried about GC performance.
|
|
|
|
delt0r
|
 |
«
Reply #1 - Posted
2011-05-06 13:42:00 » |
|
I am sure you have heard the saying "Premature optimization is the root of all evil". Of course early on things like immutable vectors is something to think about.
My vector class has two methods for each operation, add and addThis for example. Plain add returns a new instance and addThis returns itself and has mutated itself. For the most part I code lazy like and use add() all the time and have not had any performance issues in my game. Also things like cross product always return a new instance (ie no crossThis() method).
You could extend this idea to a immutable subclass that throws exceptions for all the ***this methods, and hope the compiler sorts it out.
But YMMV. I write code first, get code working second, then worry about performance. I havn't noticed a huge performance boost with java 7 in my tests.
|
I have no special talents. I am only passionately curious.--Albert Einstein
|
|
|
Orangy Tang
|
 |
«
Reply #2 - Posted
2011-05-06 16:10:34 » |
|
Ever since 1.6 I've ignored using immutable interfaces and just returned copies of vectors for simple accessors, and I've yet to see any kind of performance decrease or even anything remotely like it in the profiler. I'd recommend writing the simplest possible code and worrying about it later.
|
|
|
|
Games published by our own members! Check 'em out!
|
|
princec
|
 |
«
Reply #3 - Posted
2011-05-06 16:16:20 » |
|
I got a noticeable (20% sometimes) speedup with Java 7 but I rarely use immutable objects - my pattern is still to use mutables. And often, heinously, reusing the same static final instance over and over again (as you can see from my horrible, horrible source code). I'd use immutable objects loads more if I could be guaranteed that garbage just won't get created all over the place. It's not a problem in general use, but if it gets into the wrong place in a main loop, here come the random pauses. Historically I've only ever been a stickler about random pauses because I did live TV graphics which don't allow a single frame to drop, ever  so take my advice for what it is... Cas 
|
|
|
|
gimbal
|
 |
«
Reply #4 - Posted
2011-05-09 09:20:45 » |
|
Same here, I have for example plenty of "scratch rectangles" I use to do general bounds checks and such. I could construct a new one every time, or I can just initialize a static final one and reuse that all over the place. I like to keep per-frame object creation to a minimum even if the JVM is good at optimizing that stuff, so the static finals it is. As long as the code is only touched by one thread, there is no problem.
|
|
|
|
princec
|
 |
«
Reply #5 - Posted
2011-05-09 10:06:49 » |
|
Increasingly I am considering using two threads for games now, so this pattern may come to an end. Cas 
|
|
|
|
Eli Delventhal
|
 |
«
Reply #6 - Posted
2011-05-09 15:27:48 » |
|
Increasingly I am considering using two threads for games now, so this pattern may come to an end. Cas  Just have public static final booleans too to act as locks! Yay!
|
|
|
|
Riven
|
 |
«
Reply #7 - Posted
2011-05-09 18:19:19 » |
|
Just have public static final booleans too to act as locks! Yay!
Maybe I missed the joke, but can you explain how you'd use a public static final boolean as a lock?
|
Hi, appreciate more people! Σ ♥ = ¾ Learn how to award medals... and work your way up the social rankings!
|
|
|
delt0r
|
 |
«
Reply #8 - Posted
2011-05-09 18:27:54 » |
|
Just have public static final booleans too to act as locks! Yay!
I assume you are joking. Just for those that perhaps don't get the joke (whatever that is). This wouldn't work. This is genrally wrong. 1 2 3 4 5 6 7 8
| volatile boolean lock=false; Vector v=new Vector(); .... if(!lock){ lock=true; lock=false; } |
The reading of lock is separate from the setting of lock. Two threads could read lock as false and then both set lock to true. Now both threads are using the object. So you can't use this as a lock. Use a lock as a lock. Now we have java.util.concurrent. you really have everything you need (more or less). edit: i forget you can edit your posts here... fixed a typo in the code
|
I have no special talents. I am only passionately curious.--Albert Einstein
|
|
|
pitbuller
|
 |
«
Reply #9 - Posted
2011-05-09 18:41:17 » |
|
Did you mean? if (!lock)
|
|
|
|
Games published by our own members! Check 'em out!
|
|
Riven
|
 |
«
Reply #10 - Posted
2011-05-09 18:50:35 » |
|
In defense of delt0r, it doesn't really matter 
|
Hi, appreciate more people! Σ ♥ = ¾ Learn how to award medals... and work your way up the social rankings!
|
|
|
Orangy Tang
|
 |
«
Reply #11 - Posted
2011-05-09 18:52:20 » |
|
As long as the code is only touched by one thread, there is no problem.
It's very easy to accidentally re-use the same scratch object even with one thread. What usually trips me up is util functions wrapping other util functions to provide a different interface. It's just easier to allocate things on the fly these days IMHO.
|
|
|
|
Eli Delventhal
|
 |
«
Reply #12 - Posted
2011-05-09 18:57:40 » |
|
Yes, I was joking. Although Riven's catch (making it final and thereby immutable) I wasn't intending. Har har.
|
|
|
|
delt0r
|
 |
«
Reply #13 - Posted
2011-05-09 18:58:10 » |
|
yes, I meant . I also agree with Orangy Tang. Thread local and just creating objects and letting the GC sort it out works fine for 99% of the code. For the rest there is things like blocking ques and ReadWrite locks.
|
I have no special talents. I am only passionately curious.--Albert Einstein
|
|
|
Riven
|
 |
«
Reply #14 - Posted
2011-05-09 19:08:17 » |
|
(not really directly addressing delt0r, but..) ThreadLocals are a really poor fit, as this topic is about performance. Behind the scenes it's just a hashmap which is sluggish compared to the TLABs (thread local allocation buffer) the JVM provides.
The more cores you have, the harder it gets to create a one-size-fits-all solution. It gets nasty very fast and sometimes the overhead of the GC just becomes acceptable, because it works (it's known not to have concurrency issues on new) and the GC can be tuned to be 'not so bad' with some trial and error.
|
Hi, appreciate more people! Σ ♥ = ¾ Learn how to award medals... and work your way up the social rankings!
|
|
|
delt0r
|
 |
«
Reply #15 - Posted
2011-05-09 21:01:55 » |
|
I should qualify how i use Thread Local. I use to initialize a field in a class that is only used in a single thread. Hence I do not call ThreadLocal.get in a loop or anything. I do let the GC do some lifting for me and allocate quite a bit "on the stack" which of course in java is on the heap.
So now we really are off topic. Well i guess if you let the GC do the work, then immutable vectors FTW.
|
I have no special talents. I am only passionately curious.--Albert Einstein
|
|
|
Eli Delventhal
|
 |
«
Reply #16 - Posted
2011-05-09 21:41:57 » |
|
It also really helps if you realign the dilithium crystals beforehand, and make sure the flux capacitor is oriented correctly.
|
|
|
|
lhkbob
|
 |
«
Reply #17 - Posted
2011-05-09 23:25:08 » |
|
It also really helps if you realign the dilithium crystals beforehand, and make sure the flux capacitor is oriented correctly.
Don't forget about charging the microscopic wormhole instigator, flipping the quibits and praying to the space turtle
|
|
|
|
delt0r
|
 |
«
Reply #18 - Posted
2011-05-10 06:23:22 » |
|
Space turtles are overrated.
|
I have no special talents. I am only passionately curious.--Albert Einstein
|
|
|
ra4king
|
 |
«
Reply #19 - Posted
2011-05-11 03:48:33 » |
|
Uhmmmm.......lolwut???
|
|
|
|
pitbuller
|
 |
«
Reply #20 - Posted
2011-05-11 07:14:21 » |
|
I like turtles.
|
|
|
|
ra4king
|
 |
«
Reply #21 - Posted
2011-05-11 15:46:48 » |
|
I like turtles.
^^ The summary of this entire thread 
|
|
|
|
Roquen
|
 |
«
Reply #22 - Posted
2011-05-11 17:41:39 » |
|
"Premature optimization is the root of all evil".
This is "totally" a misquote. It should read: "Premature coding is the root of all evil".
|
|
|
|
ra4king
|
 |
«
Reply #23 - Posted
2011-05-11 18:47:40 » |
|
Premature coding? Coding when you're not ready to? 
|
|
|
|
Eli Delventhal
|
 |
«
Reply #24 - Posted
2011-05-13 00:19:57 » |
|
"Premature optimization is the root of all evil".
This is "totally" a misquote. It should read: "Premature coding is the root of all evil". Premature ejaculation is the root of all couple squabbles.
|
|
|
|
ra4king
|
 |
«
Reply #25 - Posted
2011-05-13 04:05:51 » |
|
"Premature optimization is the root of all evil".
This is "totally" a misquote. It should read: "Premature coding is the root of all evil". Premature ejaculation is the root of all couple squabbles. Oh my god this seriously made me ROFL!! Bahahahahahah!!!!
|
|
|
|
Roquen
|
 |
«
Reply #26 - Posted
2011-05-13 05:55:42 » |
|
"Premature optimization is the root of all evil".
This is "totally" a misquote. It should read: "Premature coding is the root of all evil". Premature ejaculation is the root of all couple squabbles. Exactly! In both cases what started out so promising just ends up in an embarassing mess that needs to be cleaned-up and if you're luck you get the opportunity to start over. At least in the case of ejaculation you can pretend that it was the intended result by jumping up and yelling "I win! I win!".
|
|
|
|
ra4king
|
 |
«
Reply #27 - Posted
2011-05-13 06:04:17 » |
|
ROFL!! Please make it stop!! Bahahahahahaha!! I'm dying here! lolol
|
|
|
|
Eli Delventhal
|
 |
«
Reply #28 - Posted
2011-05-13 21:15:42 » |
|
In both cases you're trying to make things faster when really you don't need to.
|
|
|
|
|