ShannonSmith
Sr. Member  Posts: 365 Medals: 13
|
 |
«
on:
2011-05-05 13: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
Sr. Member Posts: 412 Medals: 12
Computers can do that?
|
|
«
Reply #1 on:
2011-05-06 09: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
JGO Kernel Posts: 2960 Medals: 37
Monkey for a head
|
|
«
Reply #2 on:
2011-05-06 12: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! Go get 'em! 
|
|
princec
« League of Dukes » JGO Kernel  Posts: 8086 Medals: 95
Eh? Who? What? ... Me?
|
|
«
Reply #3 on:
2011-05-06 12: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
Full Member Posts: 188 Medals: 11
|
|
«
Reply #4 on:
2011-05-09 05: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
« League of Dukes » JGO Kernel Posts: 8086 Medals: 95
Eh? Who? What? ... Me?
|
|
«
Reply #5 on:
2011-05-09 06:06:49 » |
|
Increasingly I am considering using two threads for games now, so this pattern may come to an end. Cas |
|
|
|
Eli Delventhal
« League of Dukes » JGO Kernel Posts: 3573 Medals: 44
Game Engineer
|
|
«
Reply #6 on:
2011-05-09 11: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! |
See my work:OTC Software<br /> Currently Working On:Secret project... I edit JGO in production, because I simply don't waste time writing bugs
|
|
|
Riven
« League of Dukes » JGO Kernel Posts: 5869 Medals: 255
Hand over your head.
|
|
«
Reply #7 on:
2011-05-09 14: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
Sr. Member Posts: 412 Medals: 12
Computers can do that?
|
|
«
Reply #8 on:
2011-05-09 14: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
Sr. Member Posts: 340 Medals: 9
|
|
«
Reply #9 on:
2011-05-09 14:41:17 » |
|
Did you mean?
if (!lock)
|
|
|
|
Games published by our own members! Go get 'em! 
|
|
Riven
« League of Dukes » JGO Kernel Posts: 5869 Medals: 255
Hand over your head.
|
|
«
Reply #10 on:
2011-05-09 14: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
JGO Kernel Posts: 2960 Medals: 37
Monkey for a head
|
|
«
Reply #11 on:
2011-05-09 14: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
« League of Dukes » JGO Kernel Posts: 3573 Medals: 44
Game Engineer
|
|
«
Reply #12 on:
2011-05-09 14:57:40 » |
|
Yes, I was joking. Although Riven's catch (making it final and thereby immutable) I wasn't intending. Har har.
|
See my work:OTC Software<br /> Currently Working On:Secret project... I edit JGO in production, because I simply don't waste time writing bugs
|
|
|
delt0r
Sr. Member Posts: 412 Medals: 12
Computers can do that?
|
|
«
Reply #13 on:
2011-05-09 14: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
« League of Dukes » JGO Kernel Posts: 5869 Medals: 255
Hand over your head.
|
|
«
Reply #14 on:
2011-05-09 15: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
Sr. Member Posts: 412 Medals: 12
Computers can do that?
|
|
«
Reply #15 on:
2011-05-09 17: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
« League of Dukes » JGO Kernel Posts: 3573 Medals: 44
Game Engineer
|
|
«
Reply #16 on:
2011-05-09 17:41:57 » |
|
It also really helps if you realign the dilithium crystals beforehand, and make sure the flux capacitor is oriented correctly.
|
See my work:OTC Software<br /> Currently Working On:Secret project... I edit JGO in production, because I simply don't waste time writing bugs
|
|
|
lhkbob
JGO Neuromancer Posts: 1174 Medals: 35
|
|
«
Reply #17 on:
2011-05-09 19: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
Sr. Member Posts: 412 Medals: 12
Computers can do that?
|
|
«
Reply #18 on:
2011-05-10 02:23:22 » |
|
Space turtles are overrated.
|
I have no special talents. I am only passionately curious.--Albert Einstein
|
|
|
ra4king
JGO Kernel Posts: 3155 Medals: 196
I'm the King!
|
|
«
Reply #19 on:
2011-05-10 23:48:33 » |
|
Uhmmmm.......lolwut???
|
|
|
|
pitbuller
Sr. Member Posts: 340 Medals: 9
|
|
«
Reply #20 on:
2011-05-11 03:14:21 » |
|
I like turtles.
|
|
|
|
ra4king
JGO Kernel Posts: 3155 Medals: 196
I'm the King!
|
|
«
Reply #21 on:
2011-05-11 11:46:48 » |
|
I like turtles.
^^ The summary of this entire thread  |
|
|
|
Roquen
JGO Strike Force Posts: 827 Medals: 25
|
|
«
Reply #22 on:
2011-05-11 13: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
JGO Kernel Posts: 3155 Medals: 196
I'm the King!
|
|
«
Reply #23 on:
2011-05-11 14:47:40 » |
|
Premature coding? Coding when you're not ready to?  |
|
|
|
Eli Delventhal
« League of Dukes » JGO Kernel Posts: 3573 Medals: 44
Game Engineer
|
|
«
Reply #24 on:
2011-05-12 20: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. |
See my work:OTC Software<br /> Currently Working On:Secret project... I edit JGO in production, because I simply don't waste time writing bugs
|
|
|
ra4king
JGO Kernel Posts: 3155 Medals: 196
I'm the King!
|
|
«
Reply #25 on:
2011-05-13 00: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
JGO Strike Force Posts: 827 Medals: 25
|
|
«
Reply #26 on:
2011-05-13 01: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
JGO Kernel Posts: 3155 Medals: 196
I'm the King!
|
|
«
Reply #27 on:
2011-05-13 02:04:17 » |
|
ROFL!! Please make it stop!! Bahahahahahaha!! I'm dying here! lolol
|
|
|
|
Eli Delventhal
« League of Dukes » JGO Kernel Posts: 3573 Medals: 44
Game Engineer
|
|
«
Reply #28 on:
2011-05-13 17:15:42 » |
|
In both cases you're trying to make things faster when really you don't need to.
|
See my work:OTC Software<br /> Currently Working On:Secret project... I edit JGO in production, because I simply don't waste time writing bugs
|
|
|
|
