Hi gurus,
I am wondering what is better for the cpu/gpu/heap between the following:
My gut tells me that using the double version is more work for the gpu while throwing them to floats is more work for the cpu, but that’s just based on the knowledge that gpu’s uses floats.
Kind regards,
Mike
The GPU converts doubles to floats, so sending doubles to the GPU is pure waste of time.
It depends on which double version you use.
Using glVertex3d or glVertexPointer (with or without VBOs) is indeed a waste of time, all double values are converted to floats, by the driver. So it’s always more work for the CPU, the GPU only works with floats.
By using the functions found in ARB/EXT_vertex_attrib_64bit or GL41 you can properly submit 64bit data to the GPU, but that obviously requires high-end hardware (DX11 level).
Why do you need doubles anyway?
Okay, so if it is the driver that converts it, does it matter if I leave it up to the driver to “cast” it or if I do it in java?
I thought that double’s are more reliable and will keep the exact number, while floats can return incorrect numbers when doing multiplications/division? If that isn’t the case, then I’ll move over from doubles to floats.
Kind regards,
Mike
Doubles have a wider dynamic range (more exponent bits) and a higher precision (more mantissa bits). From the perspective of the abstract concept of Reals in mathematics, neither is more nor less correct than the other. Which is “better” to use is hard to describe without going into numerical analysis and an exact understanding of how they work. It is a common misconception that using doubles somehow magically makes results better…this is simply not the case. I’m sure this is about as clear as mud.
Oh, if that is the case then I’ll move over my doubles, where don’t require more than 6-7 positions of accuracy, to floats. Will save some casting 
Mike
Be careful, this sounds like premature optimization?
Also, I believe I once read that java converts floats to doubles internally for computation, unless specifically told not to. (Could someone confirm this?)
If this is indeed the case, you are better off using higher precision for game logic, and casting only once, when sending it to the GPU…
Almost right.
The CPU calculates the operations on both floasts and doubles in 80 bits, and convert them back to 32bits (floats) and 64 bits (double).
This might be premature optimization but sending doubles is pretty much unneeded. For 99% of projects, a float does the job, and then smart use of local coordinate systems means that the other 1% can still use floats. And when you use floats, you halve the amount of data you send to the graphics card. It’s not so much the CPU time spent in processing doubles/floats but in transferring them. Even if the driver will cast the double to a float, because this is Java, we transfer the doubles across the JNI bridge and that adds up.
Some CPUs actually work faster on doubles. I’d expect this is true in some modern x86 chips, but the only place I’ve heard this definitively is that you are recommended by MS to use doubles over floats on the 360 as it’s faster (and probably true for the PPE in the Cell processor too, which is the core that does all the non-specialist work in the PS3).
You’d be hard pressed to find a big performance difference between float and double on x86. But if you can find a situation where the difference between floats and doubles naturally gives you a big difference in performance (emphasis here on it happening naturally within your program, not through benchmarks), then the algorithm is run so often that it would be better to think up a pure integer alternative.
You’ll probably also find it difficult to find situations in a game where floats are not accurate enough. The main situation I personally run into with doubles vs float is when your mixing very large with very small numbers togethor. In a simplified sense, floats store a number and a location of the decimal point in relation to that number. As a result a very large number will not store small numbers such as decimal values; even adding 1 onto a very large float results in no change to that number. As doubles use more bits for greater accuracy you can mix a larger range of large and small numbers (and so be less likely to run into this issue). However again you’d be hard pressed to find a situation where this actually happens naturally in a game.
So in short, don’t worry about it!
But if you HAVE to pick one based on performance, then pick floats. I once wrote a 32 bit random class which used integers and floats. I then ported it to use longs and doubles. The 64-bit version was MUCH slower, but this was shown using artificial benchmarks which did not represent real world usage (polling for millions of random values in a row, which is rarely performed on each frame).
Otherwise pick whatever the majority of your libraries use. If they mostly take/return floats, then use floats. If they mostly return/take doubles, then pick doubles.
Thanks to all who answered, it was very insightful and I wrote everything myself so I have the luxury to choose I’ll use floats then for things that needs to be sent to opengl, sounds reasonable.
And regarding premature optimization, oh yes! I’m doing the dumbest thing anyone can do as a first java program/game, an mmo, and instead of spending time with features I’m polishing the engine as much as I can. It sucks being a perfectionist when working alone on a big project
Kind regards,
Mike
Don’t worry about it, I’ve been working on a graphics engine for at least 5 years now at the expense of finishing a game. At this point, I’ve realized that I find it as much fun to make an engine as it is to make a game. Just do what you enjoy and that’s what counts.
I’m pretty sure that this has been changed and that HotSpot now sets the cpuflags (This is an intel-a-like specific issue, BTW) to limit computations to 64-bits. Additionally newer versions use the scalar versions of SSE instructions, which will be limited to precision of the specified type. This means that a specific computation will not be bit exact from hardware-to-hardware, nor even from HotSpot version-to-version on the same box. Floating point is fun!
FreeLookCameraInputManager.installTriggers() should not be private on my view… Sorry for the offtopic.
That is off topic You’re probably right though, and I need to rewrite that whole bit anyway