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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost