Boost logo

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:

> > 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

> or not, similarly to tail recursion in functional languages. This is

> URVO (unnamed return value optimization), which depends on the code

> analysis capabilities of a optimizer. (Well, some compilers used to turn

> 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

> 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

(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

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

without any move library, but not as much of a reduction as I

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

Or is there anything else that people are aware of which could hinder the

performance of Boost::Move?


Boost list run by bdawes at, gregod at, cpdaniel at, john at