|
Boost : |
Subject: Re: [boost] [Boost.Move] [Boost.Container] Compiling with older versions of Boost and Performance
From: THOMAS JORDAN (thomasjordan2_at_[hidden])
Date: 2012-01-10 15:37:10
Thomas Klimpel wrote:
>THOMAS JORDAN wrote:
> > Thanks, yes that would be the sensible way to proceed.
> > My other question was, though -
> > Does Boost::Move library rely on compiler optimisations of
> > copy-elision/return value optimisation, as is the case with the Adobe
> > Source Library (ASL) Move library, for example. The reason I ask is
> > that I suspect the compiler I want to target is not very good at
> > said optimisations. Or are there any other known factors which
> > could
> > mitigate
> > against its effectiveness for a. n. other compiler?
> Note the RVO (return value optimization) is a feature that is either
working
> or not, similarly to tail recursion in functional languages. This is
unlike
> URVO (unnamed return value optimization), which depends on the code
> analysis capabilities of a optimizer. (Well, some compilers used to turn
off
> RVO in debug mode, but this should no longer be the case.)
> Writing tests to check whether RVO is implemented is easy. I guess you
> have a pretty good chance that even your compiler supports RVO (so I
> guess the ASL Move library would work). But this doesn't mean that it
will
> be easy to get Boost.Move working with your compiler.
Actually, just to clarify, I ran some tests which indicate the compiler
(Sun C++ 5.10) does
RVO on temporaries, but does not do NRVO and also does not seem to do
copy-elision
(as often as it might, at least). Now the ASL Move library does definitely
depend on copy
elision to provide any performance benefit, as is stated in its
documentation. I tried that library
and saw no gain - exactly the same call sequence took place. That seems to
make sense
I have pulled in the Boost::Move library - actually I only just
pulled/hacked in
the bare minimum, i.e., the macros and the ::boost::rv class and little
else, as
I am not so concerned about the C++0x/C++03/platform portability to begin
with,
just the performance. I got it compiling and running just before I knocked
off for
the day. It looks like there may be a couple fewer copies than with ASL or
than
without any move library, but not as much of a reduction as I
wanted/expected,
though I need to analyse it again more thoroughly tomorrow.
It looks from the design of the boost::rv classes and associated overloads,
and the
conversion operators generated like the macros, that unlike ASL,
Boost::Move doesn't
rely on RVO/NRVO/copy elision in order to perform. Is that a reasonable
assumption?
Or is there anything else that people are aware of which could hinder the
optimal
performance of Boost::Move?
Regards,
T.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk