0

In the book "Black art of 3D game programming", the author talks about an optimization related to int/floating point constants.

Referring to a 2d matrix of floats:

// multiple statements like this
a[0][1] = a[0][2] = a[0][3] = 0;

he writes:

As I was trying to optimize the 3D engine and performing code profiling, I found that simple floating point assignments were slow [...] the compiler uses the floating point processor to convert the 0’s into temporary reals and then assigns them to the array elements, which is slow. A better way to do this would be to simply fill the array memory with 0’s.

There is an existing answer to this topic here:

It is not an optimization. Turning off optimization won't make the compiler include the int-to-float conversion in the executable code, unless it's a very poor-quality implementation.

however, the answer refers to modern compilers.

Was this an atypical optimization for compilers in the 90s? AFAIK the author uses the Watcom compiler, and I find it odd that such widespread compiler didn't implement this optimization.

Marcus
  • 5,104
  • 2
  • 28
  • 24
  • 3
    GCC 1.27 for x86 from 1988 doesn't use any floating-point operation with optimizations enabled, see https://godbolt.org/z/jGeErn6oh. – user17732522 Dec 18 '22 at 16:32
  • 1
    @user17732522: And it's not just a special case of `0` either; an integer literal like `5` turns into a non-zero immediate for similar code-gen. But if you do `int x = 5;` / `a[0][1] = x;`, it fails at constant-propagation, using `fildl` from a `.long 5` in .rodata. https://godbolt.org/z/7W53dbTrj. (And it doesn't know about `-ffast-math` or `-fno-rounding-math`, in case it's avoiding it because it's worried the conversion might not be exact. In this case it is; `5.0` is exactly representable so the FP rounding mode makes no difference.) Modern compilers of course have no problem with that. – Peter Cordes Dec 18 '22 at 21:29

0 Answers0