[boost] RE: Math constants - efficiency

From: Daniel Frey (d.frey_at_[hidden])
Date: 2003-06-23 13:44:21

On Mon, 23 Jun 2003 19:54:36 +0200, Paul A. Bristow wrote:

> These are interesting results, but my enthusiasm is severely reduced by
> the fact that MSVC 7.1 (Standard) chokes terminally on both versions
> :-((
> 
> Compiling...
> Frey_bench_mark_gcc.cpp
> Frey_bench_mark_gcc.cpp(82) : warning C4305: 'return' : truncation from
> 'double' to 'float'
> Frey_bench_mark_gcc.cpp(108) : fatal error C1001: INTERNAL COMPILER
> ERROR
>         (compiler file 'msc1.cpp', line 2701)
>          Please choose the Technical Support command on the Visual C++
>          Help menu, or open the Technical Support help file for more
>          information

??? Line 108 is the static_cast< double >( pi ) for me. How can it compile
the three lines before but choke on 108? I think I will still have to wait
for the day MS has no surprise for us a bit longer... :)

But the GCC 2.95.x ICEd on the F<U>()() so the workaround for the MSVC may
be trivial and acceptable, too.

> (I note the warnings C4305: 'return' : truncation from 'double' to
> 'float', but these can be removed by making the value explicitly 3.14F
> and L - which I believe is 'strictly' necessary. Otherwise the compiler
> might conclude it should do a truncation, which would clearly defeat
> what we are trying to do.  However this is a trivial nit).

I know and in this toy code I don't really care :))

> Looking at your results, and the timing, and going back to the Kenniston
> code produced by the previous tests - which Ed Bray can no doubt update
> for us from his recent MSVC 7.1 test, I suspect that the differences are
> probably due to failure to load the constant directly into a floating
> point register, rather than pushing the constant onto the stack, taking
> two instructions, and using a reference to it, needing yet more
> instructions, and failure to optimise away (inlining) the template
> function call.

I actually tried to read the assembler output, but it looks weird to me. I
can't read x86 assembler - only 6502 and 680x0 :)) If you like, I can send
the GCC and Intel assembler output to you. Drop me a private mail if you
are interested.

> I hope this will produce a bit more sympathy for my attempts to provide
> a variety of solutions for a variety of compilers. If the result is such
> a big performance hit on widely used compilers, it is just too early for
> such an advanced solution.

Hm, I'm not sure I agree. Whatever will be standardizes shouldn't prevent
good code, but it's not responsible for bad compilers. But there should -
as I already said - be only one interface.

I do agree that the GCC-folks should have a look at it. Are some of them
listening here? (Gaby?)

Regards, Daniel