Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (538)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (600)
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  
  Objects vs mapped objects vs floats  (Read 3759 times)
0 Members and 1 Guest are viewing this topic.
Offline bitshit

Junior Devvie




Java games rock!!


« Posted 2007-12-17 11:14:28 »

Been a while since I last did some serious Java coding, but I'm thinking of making a little graphics demo (demo as in demoscene).
As performance will be critical, I was wondering about how to store, access and manipulate my data as efficient as possible. I did a little search in this forum and found some posts on this, but they only confused me more:

In this post, its mentioned having objects for models/poly's and vertices should be the fastest, as using arrays will cause a lot of exception checks to be done:
http://www.java-gaming.org/forums/index.php?topic=11227.0

I did a little benchmark myself and indeed seems to be the case (using objects for model/poly's/vertices was more than twice as fast as using a float[][][]). Ofcourse this would mean a lot of little objects will be created, but this seems to contradict with this post:
http://www.java-gaming.org/forums/index.php?topic=14940.0

Also mapped objects are mentioned in this forum, but I couldnt make out if theyre better than the object approach, as its mentioned somewhere that its a bit slower than using a float[] :
http://www.java-gaming.org/forums/index.php?topic=12886.0
http://www.java-gaming.org/forums/index.php?topic=15662.0

So performance wise the object approach (a class for model, poly[] and vertice[])  would be fastest?


And last: As i'll be doing a lot of vector operations, using SIMD instructions would be very welcome. I read the JVM will use SSE instructions where possible, but not very efficient. I found these threads with idea's of using a little JNI library to handle that:
http://www.java-gaming.org/forums/index.php?topic=12346.15
http://www.java-gaming.org/forums/index.php?topic=17199.msg135213#msg135213

Anyone ever get sopme results from that? Is it feasable?

Thanks!

Martijn
Offline bitshit

Junior Devvie




Java games rock!!


« Reply #1 - Posted 2007-12-20 13:16:09 »

Anyone??

Riven??  Wink
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 840
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #2 - Posted 2007-12-20 14:59:02 »

Sorry, I missed your post.

I'll respond when I'm back from school.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 840
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #3 - Posted 2007-12-21 19:29:03 »

Let me start that the thread:
"Why mapped objects (a.k.a structs) aren't the ultimate (performance) solution"

Should be pretty much ignored, as the author doesn't understand the topic quite well, yet has a very strong opinion.



Basicly this is the deal:
 
As you're pushing for performance, simply ignore the ClientVM.
I'll only discuss what to do on the Hotspot Server VM.

  • stay away from nested arrays
these are references to references to offsets to data (tiny objects, lots of overhead)
in C, a float[][][] will be 1 chunk of RAM, not so in Java


  • stay away from Buffers, for as much as possible
You'll lose 10% to 30% performance on average. but that might be acceptable

  • NEVER use array-backed Buffers, at ANY TIME
Having 1 array-backed FloatBuffer around will cause a drop of direct-FloatBuffer by factor 10

  • as you're manipulating data meant for the graphics-card, don't put your data in tiny objects.
you'll need to copy data from all over the place, into your FloatBuffers



  • float[] performance is predictable, you don't need to fine-tune your sourcecode by trial and error, to find the sweetspot.
    FloatBuffer performance is VERY unpredictable, you'll find yourself optimizing for a very specific JRE version (the one installed), and by tiny changes
    in the ordering of your calculations, you'll 'randomly' see performance drop or raise by a few dozen percent.
    One extreme case: fb.get(i+0) was 40% faster than fb.get(i) for me in a certain case.


  • when using Buffers, never use get() and put(), only get(i) and put(i), even if it makes your code a lot bigger
You'll get a massive performance gain, like factor 2-3x IIRC

  • if the calculations take 'enough' time, do all your math in float[] and copy the result to a direct-FloatBuffer before pushing it to the graphics-card.
otherwise do your calculations on a FloatBuffer, but again, never ever instantiate a float[]-backed one

  • last but not least, don't waste your time on sun.misc.Unsafe - so... there are no mapped-objects (to be faked).



In any non-bottlenecks, use proper OO and tiny objects to keep it all managable.
Don't put any effort in optimizing where it's not structly required, it will only slow you down up to the point you ditch your demo

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

JGO Knight


Medals: 32



« Reply #4 - Posted 2007-12-22 18:59:22 »

  • stay away from Buffers, for as much as possible
You'll lose 10% to 30% performance on average. but that might be acceptable
....
  • float[] performance is predictable, you don't need to fine-tune your sourcecode by trial and error, to find the sweetspot.
    FloatBuffer performance is VERY unpredictable, you'll find yourself optimizing for a very specific JRE version (the one installed), and by tiny changes
    in the ordering of your calculations, you'll 'randomly' see performance drop or raise by a few dozen percent.
    One extreme case: fb.get(i+0) was 40% faster than fb.get(i) for me in a certain case.

Are you saying that float[] actually performs better than FloatBuffers? or am I just reading it wrong.  When you say to stay away from Buffers, do you mean having variables declared with their type as the abstract Buffer, or do you mean to stay away from any Buffer subclass in general?

Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 840
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #5 - Posted 2007-12-22 20:15:10 »

float[] is _almost always_ faster than a direct, native-ordered FloatBuffer.

FloatBuffers are very rarely as fast as float[] (only in a trivial copying-loop).



try to 'stay away from subclasses of Buffer', if you want predictable behaviour and guaranteed performance.

What if a 3rd-party API makes 1 silly nondirect-FloatBuffer? Then you'd be screwed bigtime, and can as well
ditch all your FloatBuffer code that requires performance.

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

Junior Devvie




Java games rock!!


« Reply #6 - Posted 2007-12-24 10:19:56 »

Thanks for your insights Riven!

Let me start that the thread:
"Why mapped objects (a.k.a structs) aren't the ultimate (performance) solution"

Should be pretty much ignored, as the author doesn't understand the topic quite well, yet has a very strong opinion.

But i believe mapped objects have been suggested by others too?

Basicly this is the deal:
 
As you're pushing for performance, simply ignore the ClientVM.
I'll only discuss what to do on the Hotspot Server VM.

This is no problem for my demo, as i can force it to start with the server vm... but will this change in the future? Kinda weird why they dont include these optimalisations in the client vm aswell :/

In any non-bottlenecks, use proper OO and tiny objects to keep it all managable.
Don't put any effort in optimizing where it's not structly required, it will only slow you down up to the point you ditch your demo

[/quote]

Well it more kinda all or nothing.. (cant optimize for a specific part) as i plan to develop this as a general lin for future development, so i have to decide whether to use a  clean OO model (objects for everything). But I guess im sticking to one object per model with a float[] for its polys and vertices. As the models can only consist of triangles i can allocate a big float for every object (float[nr_triangles*3])
Online princec

« JGO Spiffy Duke »


Medals: 429
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #7 - Posted 2007-12-25 18:25:28 »

Not that weird - the optimisations are time consuming and use a bunch more RAM.

All to be fixed in Java 7 with the tiered compiler. Yay!

Cas Smiley

Offline SluX

Junior Devvie





« Reply #8 - Posted 2008-01-08 15:02:34 »

So if i m getting it right, u suggest that :
1  
2  
3  
4  
5  
6  
7  
class Synapse{
   float weights[];
}

class Layer{
   Synapse synapses[];
}


would be faster to work with rather then

1  
2  
3  
class Layer{
  float weights[][];
}


I m talking about neuraln network...i hope that exapmle isnt too confusing... Smiley

"Intelligence is the most beautiful gift and the greatest temptation which one life can receive from the gods."Me Cheesy
Play strategic football
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 840
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #9 - Posted 2008-01-08 19:58:38 »

Nah, it's even a bit slower (in theory)... there is one more reference to lookup.

It's fastest to use 1 float[] with all data in it.


float weight = weightsInSynapses[synapsesInLayer * layerIndex + synapsIndex];

You can optimize this further and further, but it'll get harder very quickly.


Just make it work with proper OO first. And if you replace it, keep the slow code around for reference.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Linuxhippy

Senior Devvie


Medals: 1


Java games rock!


« Reply #10 - Posted 2008-01-15 12:12:24 »

I read a bit in recently fixed bugs/rfe's and it seems that at least for the server-compiler a lot of tuning has been done for ByteBuffer's (in JDK6u4 and JDK7).
Anybody willed to re-run the benchmarks? Wink

lg Clemens
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.

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

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

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

BurntPizza (75 views)
2014-12-08 04:46:31

JscottyBieshaar (37 views)
2014-12-05 12:39:02

SHC (50 views)
2014-12-03 16:27:13

CopyableCougar4 (46 views)
2014-11-29 21:32:03

toopeicgaming1999 (113 views)
2014-11-26 15:22:04

toopeicgaming1999 (100 views)
2014-11-26 15:20:36

toopeicgaming1999 (30 views)
2014-11-26 15:20:08
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

List of Learning Resources
by SilverTiger
2014-07-31 16:29: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!