RE: [boost] Math constants - efficiency

From: Paul A. Bristow (boost_at_[hidden])
Date: 2003-06-23 12:54:36

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

I am not saying that your code is wrong, but this is clearly too 'advanced' a
solution
to be considered immediately even for Boost.

(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).

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.

(At bottom is the lousy instruction set and shortage of registers of course -
but the processors go like stink!  When you look at this sort of code, you see
why FORTRAN is still popular. gcc should probably look into how seriously the
benchmark is lying?)

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.

Paul

Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB  UK
[phone]   Mobile [phone]
Mobile mailto:pabristow_at_[hidden]
mailto:pbristow_at_[hidden]

| -----Original Message-----
| From: boost-bounces_at_[hidden]
| [mailto:boost-bounces_at_[hidden]]On Behalf Of Daniel Frey
| Sent: Sunday, June 22, 2003 12:57 PM
| To: boost_at_[hidden]
| Subject: [boost] Math constants
|
|
| I had a small time-out and will now try to catch up with the
| discussion. Before commenting on other postings, I'll show the result
| of a small benchmark. The code is attached, maybe you want to verify
| and post the results for your compiler(s), too :)
|
| MACRO:
|
| Intel C++ 7.1:   0.37
| GCC 2.95.3:      2.12
| GCC 3.3:         2.15
|
| VARIABLE:
|
| Intel C++ 7.1:   0.37
| GCC 2.95.3:      0.62
| GCC 3.3:         0.61
|
| FUNCTION:
|
| Intel C++ 7.1:   0.37
| GCC 2.95.3:      0.62
| GCC 3.3:         0.61
|
| TEMPLATE:
|
| Intel C++ 7.1:   0.37
| GCC 2.95.3:      1.36
| GCC 3.3:         1.35
|
| As you can see, good compilers like the Intel are not suffering from
| any presentation scheme, the GCC (althought not a bad compiler) has
| some problems. Even the best versions are still much slower than the
| Intel's compiler code. The template does have some performance
| penalties, but remember it is just a benchmark. In real code, I expect
| the difference to be smaller, but this will depend on the use
| scenario. The most direct approach (MACRO) is even worse than the
| template-approach. Conclusion: The code I suggest (TEMPLATE) is not
| bad in itself, nothing prevents a compiler from generating a good
| result from it. This doesn't mean that all compilers do so.
|
| Before commenting on the benchmarks, please also look at the code
| attached and note that I am well aware of the fact that all benchmarks
| are lying :o)
|
| As a result, we might want to evaluate if users that really need
| speed use fast compilers and if those compilers suffer from the
| code. If someone uses the GCC and complains about speed, one might
| suggest to change the compiler anyway.
|
|