woe! i didnt know double is faster than float
are you 100% sure about that? (btw, we''re talking about PII or more advanced CPUs)
- pouya
--------------
The trick to flight is to throw yourself at the ground and miss!!!
64bit floats?
I''m sorry period3, but I must disaggree:
> At any rate, it''s not going to be any slower then a float
Maybe I''m wrong but:
Doubles use twice as much memory than floats. If you use more memory, your cache will need twice as much loads, slowing your program down!
> At any rate, it''s not going to be any slower then a float
Maybe I''m wrong but:
Doubles use twice as much memory than floats. If you use more memory, your cache will need twice as much loads, slowing your program down!
i think his right about the speed of a double being faster than a float, every time i use a float my compiler complains that ive used a float instead of a double (and its generating a lot of warnings because of this 300 warnings)
~prevail by daring to fail~
~prevail by daring to fail~
floating point numbers are processed at 80-bits. both 32-bit and 64-bit floats are converted internally on an Intel with the FPU 80x87 chips. so the only difference would be the size of memory storage. unless you are going to use SIMD.
To the vast majority of mankind, nothing is more agreeable than to escape the need for mental exertion... To most people, nothing is more troublesome than the effort of thinking.
quote:
i think his right about the speed of a double being faster than a float, every time i use a float my compiler complains that ive used a float instead of a double (and its generating a lot of warnings because of this 300 warnings)
~prevail by daring to fail~
The compiler will probably give these warnings, because you have not used type casting for functions like sin/cos.
These functions (and a lot more standard functions like these) return doubles, so need type conversions.
The code generated by a C compiler will probably call an extra function, that''ll do the sin/cos orso for you.
In this case doubles are probably faster, but then again - calling these functions is even slower!
May 30, 2000 01:22 PM
Speaking outside of any C compiler issues that I don''t know about, there''s no reason for floats to be slower on the x86 architecture, and a few for them to be faster :
for example, on the Athlon processor, the static latencies of the FADD and FMUL instructions are 4, regardless of if you''re using floats or doubles. So the actual computation of numbers once you have them in your cache is the same. But :
1) Using 64bit floats means that more memory is consumed (irrelevant for many people, but if you have multi-megabyte arrays of floats, it can matter!)
2) Using 64bit floats means that your data cache is filled twice as fast. This is pretty significant : the overall effect is that of halving your available cache. This assumes a worst-case where you are working on enough numbers through to saturate your L1/L2 cache. In actual practice, for small numbers of calculations the impact is nil, but there are likely cases where it can bite you.
3) I know of very few games that actually NEED double-precision. And using doubles prohibits any chance at using SIMD (either 3dnow or SSE), which is probably by far the biggest concern to a 3d-engine programmer.
Basically, for normal use, either type will do whatever you want and don''t worry about it. If writing performance-critical code that needs to use SIMD, then floats are your only choice.
for example, on the Athlon processor, the static latencies of the FADD and FMUL instructions are 4, regardless of if you''re using floats or doubles. So the actual computation of numbers once you have them in your cache is the same. But :
1) Using 64bit floats means that more memory is consumed (irrelevant for many people, but if you have multi-megabyte arrays of floats, it can matter!)
2) Using 64bit floats means that your data cache is filled twice as fast. This is pretty significant : the overall effect is that of halving your available cache. This assumes a worst-case where you are working on enough numbers through to saturate your L1/L2 cache. In actual practice, for small numbers of calculations the impact is nil, but there are likely cases where it can bite you.
3) I know of very few games that actually NEED double-precision. And using doubles prohibits any chance at using SIMD (either 3dnow or SSE), which is probably by far the biggest concern to a 3d-engine programmer.
Basically, for normal use, either type will do whatever you want and don''t worry about it. If writing performance-critical code that needs to use SIMD, then floats are your only choice.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement