Fix float/double mismatches in source

[hollasch]

Lots of places where we're using double constants for use in float calculations, mixing up our widths when passing parameters, and such. We need to ensure that our code compiles without any warnings about mixing precision.

Ideally, it would be good to determine what the impact of float vs. double. Personally, I prefer double precision, as it's the native precision for math, and C++ constants, and is frequently faster on platforms that perform intrinsic computation in double-precision (and thus induce a performance hit when transforming from and to single-precision.

[trevordblack]

A possible solution here is to replace all decimal precision types with a "real" type that is typedef'd to doubles or floats

…

On Sat, Aug 17, 2019, 11:19 Steve Hollasch ***@***.***> wrote: Lots of places where we're using double constants for use in float calculations, mixing up our widths when passing parameters, and such. We need to ensure that our code compiles without any warnings about mixing precision. Ideally, it would be good to determine what the impact of float vs. double. Personally, I prefer double precision, as it's the native precision for math, and C++ constants, and is frequently faster on platforms that perform intrinsic computation in double-precision (and thus induce a performance hit when transforming from and to single-precision. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/RayTracing/InOneWeekend/issues/67?email_source=notifications&email_token=ACNZVKHLGQVU7I527F673U3QFA6MHA5CNFSM4IMQC6HKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HFZNAVQ>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACNZVKCGXMBHY3NHCUYKWFDQFA6MHANCNFSM4IMQC6HA> .

[trevordblack]

I don't believe that my comment above is warranted. We should pick a precision type and stick with it.

I went ahead and created a benchmark.
On my own
Intel® Core™ i7-9750H CPU @ 2.60GHz × 12
running in Ubuntu 18.04.3 LTS
Compiled with Clang6.0.0 ubuntu
I found:
double: 442 seconds
float: 456 seconds
The difference is noise.

If more data is warranted,
$ git pull
$ git checkout origin/tdb/real_type_exp
$ cd src
$ mkdir build
$ cd build
$ cmake ..
$ make
$ time ./Real_Type_Double > double.ppm && time ./Real_Type_Float > float.ppm

To Be Clear
This is not a production branch.
Once a decision of floats vs doubles is made, I can go through and replace Reals with the selection.

[hollasch]

I also had the idea of using real = double or using real = float. However, your benchmark bears out my experience, that float is not a performance optimization, and indeed, working entirely in double values often yields a (tiny) performance benefit. Old habits die hard, though.

I say we convert the entire code base to use simple double-precision floats.

Anybody else care to comment?

[ronaldfw]

If double is not slower than float (single precision) here, I'd vote for just using double everywhere. With float you could get performance benefits when implementing certain parts with SIMD (SSE, AVX) but I don't think we should go there (and I don't know if there are even places where that would work well in any of the code here).

[hollasch]

I think we're starting to lean toward double at this point. The only reason to use single-precision is that GPUs typically work with floats, but we're not in that domain. Converting to float is fine for storage purposes, but we're not doing that either.

[trevordblack]

From all of this discussion, what I've arrived at is that the only significant difference between floats and doubles for this domain is that floats are much more likely to have shadow acne.

This is arguably a benefit because it would much more clearly illucidate the problem.

Other than that, I'm not seeing any real argument that isn't aesthetic. My vote is for doubles.

[hollasch]

I suspect that adopting double precision may not change the frequency of surface acne. Does it matter if your intersection point is 1e-10 inside the surface versus 1e-100 inside? Should be a simple test to verify, but agree with Trevor that it shouldn't really affect the decision.

Sounds like we're agreed on using double.

[vchizhov]

I am for using float rather than double. The main argument towards using double that I managed to gather from here was self intersection.
However self-intersection occurs even with double precision. And thus should be handled in a different manner, see #137.
On the other hand using float allows for a straightforward extension of the code through SIMD, as well as a minor scalar code speed up.

[hollasch]

No, see my comment just above yours. Self intersection is not one of the arguments. Instead,

• double is frequently faster, since it can avoid conversion overhead. This is not an argument in favor, however, since ultimate performance is not a goal of this book.
• Most math libraries are double-precision in arguments and return value.
• Floating point literals are double-precision.

[vchizhov]

As far as the comment above mine goes, double vs float affects self intersection. It is not so much about whether it's 0.1 or 0.01 on the inside, but rather whether it ends up on the inside in the first place due to round-off error.

What conversion are we talking about? And why would double computations be faster? This is untrue for many machines, compilers, and compilation options. And even less true for SIMD.

The math libraries that I know of usually provide both single and double precision versions of the functions, notably so does stl.

1.0f is a floating-point literal. The f is a type specifier. So I am unsure whether the argument is that f is undesirable?

[hollasch]

See timing results above. This is not conclusive, but generally true that float can induce conversion costs to and from double (or higher) internal precision for computation. It doesn't matter, though, since the difference is tiny and irrelevant for our purposes. SIMD is a non-issue — it is outside of the scope of this book, and as I wrote above, high performance is not a goal.

The code should be most broadly useful, and I know of no platforms that provide only single-precision math libraries, while I know some that provide only double.

Regarding constants, yes, I was talking about the C-centric annoyance of having to suffix all numbers with f, both internal and imported. double can accept both single and double-precision values, float will give you warnings.

Readers are strongly encouraged to write the raytracing code themselves. The code included in the book is for illustration, and meant to be broadly understood by programmers regardless of their preferred languages. Using double is a tiny improvement in that regard.

[vchizhov]

I thought that the benchmark conclusion was that the "speed up" was due to noise. One also doesn't need to convert between float and double if they keep computations in float.

Using double and the code being broadly useful clashes with SIMD and GPU ports, while allowing for no warnings double only libraries integration. Ideally a typedef should be used if the code is to be broadly useful, but that's beyond the point.

The f is a valid argument - I've had to change 1.0 to 1.0f when porting from glsl.

I still think it's wasteful using double, where float is valid, but this is mostly optimization speaking, and I can see where you're coming from with double.

[hollasch]

Conversion happens in the FPU. Scalar floating point is computed at 64 or 80-bit precision on most architectures. Regardless

• We are not basing this decision on performance
• SIMD and GPU ports are not a goal
• Readers are encouraged to write their own raytracing code

[hollasch]

Fixed in #222 (development branch)