Boost logo

Boost :

From: Andy Sawyer (boost_at_[hidden])
Date: 1999-12-02 11:56:02


On 02 December 1999 12:55, John Maddock wrote:

AMS> Of course, it's possible to generate (or at least write by hand) _much_
> faster code for an Intel CPU than this, in this specific case (using
> REP STOSx ), [...]

JM> Exactly, I really wish that Wintel standard library ports included
> specialisations for
> std::copy/fill/fill_n/unitialized_copy/unitialised_fill
> etc etc,

 There is, of course, nothing to stop library vendors from doing just that
(apart from the explicit instantiation issue, that is...)
 And of course, after "#include <algorithm>", a compiler is entitled to
"spot" the name std::fill (or whatever) and generate magic code which
bears no relation to the template definition (apart from the results!).
Although I don't think there are many compilers that do this just yet :-)

JM> some of these could be much much more efficiently dealt with in
> assembly for built in types - and it wouldn't actually require many
> assembly functions either. Still I can dream I guess :-)

 I'll guess it's true of many architectures, not just Intel (and certainly
not just Wintel :-) - although it's been a long time (way too long :-) since
I did any _serious_ assembly level work on another architecture.
 Of course, there are some compilers which have the ability to 'inline'
certain
standard "C" library functions (things like memcpy, memset etc. - which of
course are, in many cases, analogous to std::uninitialized_copy and
std::uninitialised_fill. ) - but in at least one case (anyone who knows me
will know who I mean, anyone who doesn't will probably guess :-), the
function call version is generally faster than [or at least as fast as]
the inline expansion, and almost always smaller. (Although the speed gain is
obviously data dependant.) In the case of a project I was working on
recently,
turning _off_ such expansions gave around a 20% speed improvement in what
was
already fairly heavily [speed]optimized code.

Regards,
 Andy

--
Andy Sawyer, Technical Director, Sufficiently Advanced Technology Ltd.
mailto:andys_at_[hidden]        ICQ:14417938        http://www.morebhp.com
Mobile: (+44)7970 299892 [Voice/SMS] (+44)7970 523053 [Fax]
"Any technology distinguishable from magic is insufficiently advanced"

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk