4

I'm currently developing my own math lib to improve my c++ skills. I stumbled over boost's constants header file and I'm asking myself what is the point of using compile-time constants over runtime declared constants?

const float root_two = 1.414213562373095048801688724209698078e+00;
const float root_two = std::sqrt( 2.0f );

Isn't there an error introduced when using the fixed compile-time constant but calculations while running the application with functions? Wouldn't then the error be negleted if you use runtime constants?

Buni
  • 251
  • 2
  • 13
  • 3
    What are runtime constants?? Did you mean `const` access on values that were calculated at runtime? – πάντα ῥεῖ May 21 '14 at 21:19
  • 2
    It saves a micro-Watt. Multiply it by a billion machines and it starts to add up :) – Hans Passant May 21 '14 at 21:23
  • @HansPassant to that point though, "Premature optimization is the root of all evil". in general, if you're not writing a header file that will be used in thousands of different settings (including those without any floating point hardware) then don't worry about it. Floating point values can never be constexpression, so you'll get no boost there. However const integral expressions can be used in instructions (sometimes) so you can get a significant performance boost. – IdeaHat May 21 '14 at 21:26
  • It is also possible that the compiler/cpu doesn't have a super accurate square-root calculator (like for, say, and embedded system or whatever). If you're writing code that you want to work everywhere, than you don't want the square root of two (for example) to be bad. – IdeaHat May 21 '14 at 21:29
  • 1
    @MadScienceDreams that would explain alot, but still, is noone using the 2nd approach? – Buni May 21 '14 at 21:39
  • I'm not sure what you mean by "noone"...plenty of people do. In fact, the rule of thumb should probably be "default to using either a third party supplied value (boost::constants) or your own value unless you are writing embedded code or calculating the value is too slow" – IdeaHat May 21 '14 at 21:45

2 Answers2

2

  1. As HansPassant said, it may save you a micro-Watt. However, note that the compiler will sometimes optimize that away by evaluating the expression during compilation and substituting in the literal value. See this answer to my earlier question about this.

  2. Isn't there an error introduced when using the fixed compile-time constant? If you are using arbitrary-precision data types, perhaps. But it is more efficient to use plain data types like double and these are limited to about 16 decimal digits of precision anyways.

  3. Based on (2), your second initialization would not be more precise than your first one. In fact, if you precomputed the value of the square root with an arbitrary precision calculator, the literal may even be more precise.

Community
  • 1
  • 1
merlin2011
  • 71,677
  • 44
  • 195
  • 329
  • Thank you, didn't knew about #3. But then, why I haven't seen anyone using the 'runtime approach'? (Its even shorter) Maybe I haven't looked at the right places yet. – Buni May 21 '14 at 21:35
  • 1
    @buni you might have misinterpreted 3. I was saying that hard coding the literal constant might be more precise. – merlin2011 May 21 '14 at 21:41
0

A library such as Boost must work in tons of environments. The application that uses the library could have set FPU could be in flush-to-zero mode, giving you 0.0 for denormalized (tiny) results.

Or the application could have been compiled with the -fast-math flag, giving inaccurate results.

Furthermore, a runtime computation of (a + b + c) depends on how the compiler generated code will store intermediate results. It might chose to pop (a + b) from the FPU as a 64-bit double, or it could leave it on the FPU stack as 80 bits. It depends on tons of things, also algebraic rewrites of associativity.

All in all, if you mix different processors, operating systems, compilers and the different applications the library is used inside, you will get a different result for each permutation of the above.

In some (rare) siturations this is not wanted; you can be in need for an exact constant value.

Lasse Reinhold
  • 168
  • 6