Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (553)
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  
  About doubles and floats  (Read 2239 times)
0 Members and 1 Guest are viewing this topic.
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Posted 2007-04-20 07:27:39 »

hi

As I once said, I cannot post to the mailing list. So I'll post here again.

As far as I know doulbes are way slower than floats. I haven't run any tests personally. But that's the reson, why Xith3D chose to use floats, but not doubles as Java3D does. That's the reason, why LWJGL uses floats, but no doubles. That's the reason, why jME uses floats, but no doubles. And OpenGL takes floats, so we don't have to convert anything before passing it to OpenGL. And it would be great, if one would not need to constantly convert all values coming from JOODE when passed to Xith, which passes them to OpenGL.

On the other hand, if you say, that doubles are faster by far, then we need to rethink everything. Do you have any tests? Maybe the difference comes into account on 64 bit machines, which I would understand. I have an Athlon64 CPU, but I don't run a 64 bit Linux. So I could run your tests in 32 bit mode and approve your results.

Marvin
Offline SluX

Junior Member





« Reply #1 - Posted 2007-04-20 07:50:09 »

Err...data type cant be slower or faster....Smiley- it all comes down to number of cycles needed for a 32bit or 64bit processor to process the data.

I guess for the OpenGl, the choice was made cos graphics hardware deals with floats....

And as for those other types of applications-well it should be connected to machine's native word size(float=4 bytes and double 8 bytes).

"Intelligence is the most beautiful gift and the greatest temptation which one life can receive from the gods."Me Cheesy
Play strategic football
Offline bienator

Senior Member




OutOfCoffeeException


« Reply #2 - Posted 2007-04-20 08:31:48 »

I also can't imagine why a simple switch to doubles can improve performance. But in theory, physics engines could reach faster the restitution state of objects with higher precision.  The size of your 3D World is also a important factor because of the "floating point"...

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline zero

Junior Member





« Reply #3 - Posted 2007-04-20 14:23:02 »

AFAIK a pentium's floating point engine is 80 bits. That means both floats (32bit) and doubles (64bit) are extebded before computation.
(SMID is probably different, but SUN's current JVMs don't  use this anyway)

So the pure computation performance should be equal on both, but the size can matter: More single-sized floating-point values fit into the registers, so accessing many at once could load to additional (slow) load and save instructions, when dealing with double precision.

However, I'd recommand double precision for physics, because of the less rounding errors (and bienator's argument considering restitution Smiley )

With (OpenGL) Graphics I'd go for floats, especially for dynamic geometry/textures to reduce the BUS traffic.
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #4 - Posted 2007-04-21 09:08:01 »

However, I'd recommand double precision for physics, because of the less rounding errors (and bienator's argument considering restitution Smiley )

With (OpenGL) Graphics I'd go for floats, especially for dynamic geometry/textures to reduce the BUS traffic.

Well, I don't know, how important the conversion between the graphics- end physics engine's values is. A physics engine can't live without tghe use of some graphics engine. And if the graphics engine works with floats and the physics engine works with doubles, any values pushed around between them must be converted. I don't know, how important this is, since I have no idea, how big the amount of transferred values is comapred to the amount of "internal" values.

Another point is, that in the future there might be physics hardware (already awailable) similar to a graphics card. Such a physics board is connected to through a similar API like OpenGL. So it will be the same for physics: everything must go over the BUS. In this case floats would be faster.

As my old physics teacher always said: "Precision is not very important. Having the third or fourth decimal place correct is absolutely sufficient. The precision imporvement is so minimal, if you do more precise calculations, is is absolutely not worth it." Well, I guess, floats are at least sufficient for now, maybe even better because of the above arguments, and will be more beneficial in the future, when we all use physics hardware.

Marvin
Offline PeterB

Junior Member





« Reply #5 - Posted 2007-04-21 09:17:02 »

I did some tests in Java on a Pentium 4 2.4Ghz processor two years ago to test out the speed of the four basic arithmetic operations.
Here are my results:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
Floating Point vs Double Precision.
Iterations: 999,999,999
CPU: Pentium 4 (2.4GHz)

                 Dividing is significantly slower than multiplying.
                 All other operations are basically same speed with either
                 type. So we can use double type for most ops and get better
                 precision at the same speed.

                 Divide    Float    Double
                           ======== ========
                           10391 ms 16297 ms
                            9890 ms 16344 ms
                            9906 ms 16266 ms
                 Multiply  Float    Double
                           ======== ========
                            4938 ms  4922 ms
                            4781 ms  4914 ms
                            4781 ms  4766 ms
                 Add       Float    Double
                           ======== ========
                            4828 ms  4594 ms
                            4594 ms  4594ms
                            4610 ms  4609 ms
                 Subtract  Float    Double
                           ======== ========
                            4578 ms  4609 ms
                            4563 ms  4766 ms
                            4610 ms  4640 ms

Vault101 / Mace The Game
There are 10 kinds of people in the world. Those who understand binary and those who don't.
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #6 - Posted 2007-04-22 10:52:13 »

Ahhh well thats good news then. JOODE does not need to change. I was worried by what DzzD was saying in
1  
http://www.java-gaming.org/forums/index.php?topic=16296.msg130074;boardseen#new
.

JOODE does not utilize the full precision of floats, so using doubles for precision is not helptful. I thought I heard somewhere that floats were  slower than doubles, but that seems not to be the case (but of course I would have benchmarked first).

Thanks everyone for insightful comments.

PeterB do you still have that benchmark code?

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline irrisor

Junior Member





« Reply #7 - Posted 2007-04-22 20:34:55 »

It does not look like these results could tell anythink, PeterB. Undecided
It seems only the division times give a small hint on the performance, as all other operations are done faster than the loop processing Tongue
A benchmark 'in the field' would be needed.
Online Riven
« League of Dukes »

JGO Overlord


Medals: 783
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #8 - Posted 2007-04-22 20:44:26 »

Uh... have you seen the benchmark? What makes you think he is not doing a LOT of operations every iteration?

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

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #9 - Posted 2007-04-23 09:43:54 »

OK. I created an approximate atan function that works using only doubles. Here are the results
Client VM:-
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
precision = 10.0
atan(float)  is 22.451109
atan(double) is 23.886486
precision = 1.0
atan(float)  is 19.967203
atan(double) is 23.155668
precision = 0.1
atan(float)  is 45.209797
atan(double) is 53.017002
precision = 0.010000001
atan(float)  is 63.526928
atan(double) is 72.83537
precision = 0.0010
atan(float)  is 108.56205
atan(double) is 129.24625
precision = 1.00000005E-4
atan(float)  is 199.41187
atan(double) is 248.4359
precision = 1.0000001E-5
atan(float)  is 313.6351
atan(double) is 437.66364


Server VM:-
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
precision = 10.0
atan(float)  is 25.275627
atan(double) is 27.491901
precision = 1.0
atan(float)  is 22.598331
atan(double) is 21.808147
precision = 0.1
atan(float)  is 35.468964
atan(double) is 37.633972
precision = 0.010000001
atan(float)  is 61.88908
atan(double) is 70.5596
precision = 0.0010
atan(float)  is 99.14026
atan(double) is 113.27753
precision = 1.00000005E-4
atan(float)  is 163.93849
atan(double) is 214.60402
precision = 1.0000001E-5
atan(float)  is 255.63081
atan(double) is 362.96353


atan is a costly function in JOODE, so this is my field test. Horay for floats!

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
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.

TehJavaDev (16 views)
2014-08-28 18:26:30

CopyableCougar4 (25 views)
2014-08-22 19:31:30

atombrot (38 views)
2014-08-19 09:29:53

Tekkerue (34 views)
2014-08-16 06:45:27

Tekkerue (32 views)
2014-08-16 06:22:17

Tekkerue (20 views)
2014-08-16 06:20:21

Tekkerue (31 views)
2014-08-16 06:12:11

Rayexar (66 views)
2014-08-11 02:49:23

BurntPizza (44 views)
2014-08-09 21:09:32

BurntPizza (34 views)
2014-08-08 02:01:56
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

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!