Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (534)
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  
  Immutable Vectors and Performance  (Read 6860 times)
0 Members and 1 Guest are viewing this topic.
Offline ShannonSmith
« Posted 2011-05-05 19: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.

Offline delt0r

JGO Knight


Medals: 26
Exp: 18 years


Computers can do that?


« Reply #1 - Posted 2011-05-06 15: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
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #2 - Posted 2011-05-06 18: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.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #3 - Posted 2011-05-06 18: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 Wink so take my advice for what it is...

Cas Smiley

Offline gimbal

JGO Knight


Medals: 25



« Reply #4 - Posted 2011-05-09 11:20:45 »

And often, heinously, reusing the same static final instance over and over again (as you can see from my horrible, horrible source code).

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.
Online princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #5 - Posted 2011-05-09 12:06:49 »

Increasingly I am considering using two threads for games now, so this pattern may come to an end.

Cas Smiley

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #6 - Posted 2011-05-09 17:27:48 »

Increasingly I am considering using two threads for games now, so this pattern may come to an end.

Cas Smiley
Just have public static final booleans too to act as locks! Yay!

See my work:
OTC Software
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 743
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #7 - Posted 2011-05-09 20: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
Offline delt0r

JGO Knight


Medals: 26
Exp: 18 years


Computers can do that?


« Reply #8 - Posted 2011-05-09 20: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;
    //do stuff with v
   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
Offline pitbuller
« Reply #9 - Posted 2011-05-09 20:41:17 »

Did you mean?
if (!lock)
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 743
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #10 - Posted 2011-05-09 20:50:35 »

In defense of delt0r, it doesn't really matter Smiley

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #11 - Posted 2011-05-09 20: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.

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

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #12 - Posted 2011-05-09 20: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
Offline delt0r

JGO Knight


Medals: 26
Exp: 18 years


Computers can do that?


« Reply #13 - Posted 2011-05-09 20:58:10 »

yes, I meant
1  
if(!lock)
. 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
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 743
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #14 - Posted 2011-05-09 21: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
Offline delt0r

JGO Knight


Medals: 26
Exp: 18 years


Computers can do that?


« Reply #15 - Posted 2011-05-09 23: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
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #16 - Posted 2011-05-09 23: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
Offline lhkbob

JGO Knight


Medals: 32



« Reply #17 - Posted 2011-05-10 01: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

Offline delt0r

JGO Knight


Medals: 26
Exp: 18 years


Computers can do that?


« Reply #18 - Posted 2011-05-10 08:23:22 »

Space turtles are overrated.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline ra4king

JGO Kernel


Medals: 337
Projects: 2
Exp: 5 years


I'm the King!


« Reply #19 - Posted 2011-05-11 05:48:33 »

Uhmmmm.......lolwut???

Offline pitbuller
« Reply #20 - Posted 2011-05-11 09:14:21 »

I like turtles.
Offline ra4king

JGO Kernel


Medals: 337
Projects: 2
Exp: 5 years


I'm the King!


« Reply #21 - Posted 2011-05-11 17:46:48 »

I like turtles.
^^ The summary of this entire thread Cheesy

Online Roquen
« Reply #22 - Posted 2011-05-11 19:41:39 »

Quote
"Premature optimization is the root of all evil".

This is "totally" a misquote.  It should read: "Premature coding is the root of all evil".
Offline ra4king

JGO Kernel


Medals: 337
Projects: 2
Exp: 5 years


I'm the King!


« Reply #23 - Posted 2011-05-11 20:47:40 »

Premature coding? Coding when you're not ready to? Tongue

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #24 - Posted 2011-05-13 02:19:57 »

Quote
"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
Offline ra4king

JGO Kernel


Medals: 337
Projects: 2
Exp: 5 years


I'm the King!


« Reply #25 - Posted 2011-05-13 06:05:51 »

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

Online Roquen
« Reply #26 - Posted 2011-05-13 07:55:42 »

Quote
Quote
Quote
"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!".
Offline ra4king

JGO Kernel


Medals: 337
Projects: 2
Exp: 5 years


I'm the King!


« Reply #27 - Posted 2011-05-13 08:04:17 »

ROFL!! Please make it stop!! Bahahahahahaha!! I'm dying here! lolol

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #28 - Posted 2011-05-13 23:15:42 »

In both cases you're trying to make things faster when really you don't need to.

See my work:
OTC Software
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.

pw (35 views)
2014-07-24 01:59:36

Riven (34 views)
2014-07-23 21:16:32

Riven (22 views)
2014-07-23 21:07:15

Riven (26 views)
2014-07-23 20:56:16

ctomni231 (56 views)
2014-07-18 06:55:21

Zero Volt (48 views)
2014-07-17 23:47:54

danieldean (39 views)
2014-07-17 23:41:23

MustardPeter (43 views)
2014-07-16 23:30:00

Cero (59 views)
2014-07-16 00:42:17

Riven (56 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!