I've noticed in this class we tend to use float as opposed to double. Is this true in general in the graphics community? I assume this is for speed, at the cost of precision errors?
jkalapos
I'm not entirely sure if this is the exact motivation but using floats could be better for vectorized computations as you can operate in parallel on twice as many floats as doubles. If this is true then I guess the almost 2x speedup advantage would be worth the loss in greater precision
keenan
@kc1 Ah, this is just a matter of terminology: the term "floating point" is generally used to mean any floating point representation, of any precision. So, both 32-bit and 64-bit values are referred to as "floating point."
In general I would strongly advocate using doubles (64-bit) and NOT floats (32-bit) for writing any/all graphics code. There are two reasons for this:
Premature optimization is the root of all evil. Performing accurate floating point calculations can already be quite tricky, and there's no reason to shoot yourself in the foot by using 32-bit floats for the initial implementation. Get it right, then make it fast. I.e., write everything in 64-bit first, then only when you're completely sure everything is working, consider switching to 32-bit. Or better yet: don't! The price you pay for peace of mind is small (or nonexistent, depending on the application).
On modern 64-bit processors, 32-bit float may not actually be any faster---and may even be slower. Google the string "double faster than float" and you will find all sorts of interesting discussion about performance trade offs. But generally the answer is: it's a wash. The main exception (and an important one) is when you're bound by bandwidth rather than compute, and this can happen quite often in graphics. But even in this case, you still may be able to do your intermediate calculations in double precision, even if the data is shipped around in single precision. (See again #1: this kind of optimization is all premature if you haven't yet written a 100% correct implementation.)
keenan
@jkalapos The improvement in performance is never worth it if the answer is wrong. ;-)
mzeitlin
Do algorithms exist to approximate which collision is the real one if there is enough imprecision that there would be multiple "collisions" like on the line above (for example, maybe taking the center point between the farthest calculated collisions would help)?
kc1
I was referring to float as in C++ in-built type to disambiguate. It looks like the skeleton code we are given for Scotty3D uses floats in some cases, and doubles in others. DrawSVG used almost explicitly float's. You answer this in point #2, where we may be concerned with bandwidth and ship values as floats, while doing intermediate calculations in double precision. This is an interesting point
keenan
@mzeitlin Take a look at the reference at the bottom of the slide (just type it into Google and you'll find it); this should give you a sense of the challenge of providing robust geometric tests.
keenan
@kc1 Ah, ok. I don't know who did that. :-). Though for our assignments in class, it doesn't make a big difference.
I've noticed in this class we tend to use float as opposed to double. Is this true in general in the graphics community? I assume this is for speed, at the cost of precision errors?
I'm not entirely sure if this is the exact motivation but using floats could be better for vectorized computations as you can operate in parallel on twice as many floats as doubles. If this is true then I guess the almost 2x speedup advantage would be worth the loss in greater precision
@kc1 Ah, this is just a matter of terminology: the term "floating point" is generally used to mean any floating point representation, of any precision. So, both 32-bit and 64-bit values are referred to as "floating point."
In general I would strongly advocate using doubles (64-bit) and NOT floats (32-bit) for writing any/all graphics code. There are two reasons for this:
Premature optimization is the root of all evil. Performing accurate floating point calculations can already be quite tricky, and there's no reason to shoot yourself in the foot by using 32-bit floats for the initial implementation. Get it right, then make it fast. I.e., write everything in 64-bit first, then only when you're completely sure everything is working, consider switching to 32-bit. Or better yet: don't! The price you pay for peace of mind is small (or nonexistent, depending on the application).
On modern 64-bit processors, 32-bit float may not actually be any faster---and may even be slower. Google the string "double faster than float" and you will find all sorts of interesting discussion about performance trade offs. But generally the answer is: it's a wash. The main exception (and an important one) is when you're bound by bandwidth rather than compute, and this can happen quite often in graphics. But even in this case, you still may be able to do your intermediate calculations in double precision, even if the data is shipped around in single precision. (See again #1: this kind of optimization is all premature if you haven't yet written a 100% correct implementation.)
@jkalapos The improvement in performance is never worth it if the answer is wrong. ;-)
Do algorithms exist to approximate which collision is the real one if there is enough imprecision that there would be multiple "collisions" like on the line above (for example, maybe taking the center point between the farthest calculated collisions would help)?
I was referring to float as in C++ in-built type to disambiguate. It looks like the skeleton code we are given for Scotty3D uses floats in some cases, and doubles in others. DrawSVG used almost explicitly float's. You answer this in point #2, where we may be concerned with bandwidth and ship values as floats, while doing intermediate calculations in double precision. This is an interesting point
@mzeitlin Take a look at the reference at the bottom of the slide (just type it into Google and you'll find it); this should give you a sense of the challenge of providing robust geometric tests.
@kc1 Ah, ok. I don't know who did that. :-). Though for our assignments in class, it doesn't make a big difference.