Re: [lmi] New clang errors fixes

[Vadim Zeitlin]

On Wed, 27 Sep 2017 00:04:32 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-09-26 21:10, Vadim Zeitlin wrote:
GC> > On Tue, 26 Sep 2017 17:02:58 +0000 Greg Chicares <address@hidden> wrote:
GC> 
GC> [...bourne_cast.hpp rejected by clang...]
GC> 
GC> > GC> If it can't be static and it can't be constexpr, then is this:
GC> > GC> +    From const limit = std::ldexp(From(1), to_traits::digits);
GC> > GC> the best we can do to express the intention and help the compiler 
optimize?
GC> > 
GC> >  I don't know if it's the best, but I wonder if this is really noticeably
GC> > worse than the best. I might be forgetting this as well, but have you
GC> > already run the benchmarks for this variant and did it show that it's
GC> > really worth it to optimize this call to ldexp() away?
GC> 
GC> Benchmarks using i686-w64-mingw32-gcc version 6.3.0 :

 Thanks for running this!

[...]
GC> Purging everything except the floating-to-integral conversions, because
GC> nothing else should be affected:
GC> 
GC>     constexpr From limit = std::ldexp(From(1), to_traits::digits);
GC>   static_cast<U>(D): 2.513e-003 s mean;       2435 us least of 100 runs
GC>    bourn_cast<U>(D): 1.346e-002 s mean;      12893 us least of  75 runs
GC>    bourn_cast<S>(D): 6.764e-003 s mean;       6703 us least of 100 runs
GC> 
GC>     From const limit = std::ldexp(From(1), to_traits::digits);
GC>   static_cast<U>(D): 2.561e-003 s mean;       2427 us least of 100 runs
GC>    bourn_cast<U>(D): 1.393e-002 s mean;      12913 us least of  72 runs
GC>    bourn_cast<S>(D): 6.502e-003 s mean;       6284 us least of 100 runs
GC> 
GC>     Iterative constexpr ldexp() replacement:
GC>   static_cast<U>(D): 2.561e-003 s mean;       2427 us least of 100 runs
GC>    bourn_cast<U>(D): 1.393e-002 s mean;      12913 us least of  72 runs
GC>    bourn_cast<S>(D): 6.502e-003 s mean;       6284 us least of 100 runs
GC> 
GC> The only significant difference seems to be in the last timing in each
GC> group, where HEAD appears to be on the order of ten percent slower than
GC> the others. I'd guess that's transient noise.

 So, seeing that there is no advantage whatsoever in using "constexpr" from
performance point of view, why do we still need lmi::ldexp()? Wouldn't the
simplest, and hence the best, change be to just replace "constexpr" with
"const" and keep using std::ldexp()? I feel like I'm missing something here
because I just don't understand how did the benchmark results above lead to
the subsequent commits... Of course, having lmi::ldexp() is not a big deal,
but if it isn't justified by any performance considerations, wouldn't it be
preferable to avoid introducing it?

VZ