Re: [boost] [Boost.Move] [Boost.Container] Compiling with older versions of Boost and Performance

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.