From: Noah Stein (noah_at_[hidden])
Date: 2008-03-26 00:49:25
> Hartmut Kaiser wrote:
> > To be honest I've done some experiments, also with a polygon with a
> > compile-time number of vertices. Called it the template <size_t D> gon
> > so a gon<3> for a triangle, etc. It disappointed me a bit because the
> > compile-time area calculation routine which I drafted turned out to be
> > slower than the runtime version...
> Do you mean the version generated using a compile time area calculation
> turns out to be slower at runtime than the native runtime version? I don't
> understand how this might be possible. What are you trying to achieve at
> compile time?
In the post, the compile-time version unrolls the loop during compilation;
it doesn't compute a result based on values specified in the source that are
defined at compilation. Thus, the compile-time function could have a higher
cost. It will almost certainly have a higher cost in a debug build since
many compilers do not inline in that situation. I'd have to think recursive
function calls are going to be much more expensive than a simple for loop.
In release, it really depends on how well a compiler inlines. I haven't done
extensive testing on any current compiler, but I know MSVC 6.0 optimized
very well when __forceinline was used judiciously, but was quite a bit more
hit-or-miss when relying on its inlining decisions.
No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.0/1342 - Release Date: 3/25/2008
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk