Offline, some of us have been trying various
templated small vector classes.  It's been interesting
to discover that template specialization didn't
improve performance with Visual C++ 6.x.  Just writing
the thing in a reasonably obvious way (see my previous
"valmatrix" discussion) produced inner loops as good
as they're going to get.  All that could have been
done at compile time was done, the array indexing
was reduced to pointer arithmetic by the compiler,
and in the end, a one-instruction inner loop was
generated.

    This was with an explicit subscript calculation,
expressed as below, with "isize, "jsize", and "colmajor"
as constants.

    size_t pos(size_t i, size_t j) const// subscript calculation
    { return( colmajor ? (i * jsize + j) : (j * isize + i)); }

    valmatrix(const valmatrix& val)
    { for (size_t i=0; i<isize; i++)
 { for (size_t j=0; j<jsize; j++)
  { (*this)(i,j) = val(i,j);}
 }
    }

Some would expect awful code from those constructs.
Not today.  Even that was properly strength-reduced
during loop optimization.

    The abstraction penalty is declining.  Stepanov
benchmark numbers are converging on 1.0 for the
major compilers. This has implications for library
designers.

    I thus see what may be unnecessary enthusiasm for
optimizing at the template level.  Compilers are
getting quite good. For the standards track, the lesson is
that adding language features at the template level, or
even using them in widely used libraries, in the name of
"optimization", may be counterproductive.  If the
compiler can do it at compile time, today it probably will.

    John Nagle
    Animats

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]