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 10:11:58

>From: "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]>

>To: boost_at_[hidden]

>Subject: Re: [boost] [Boost.Move] [Boost.Container] Compiling with

> older versions of Boost and Performance

>Message-ID: <4F09F0C3.4080306_at_[hidden]>

>Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Ø Le 08/01/12 12:25, Thomas Jordan a ?crit :

Ø >> Message: 3

Ø >> Date: Sat, 07 Jan 2012 15:58:20 +0100

Ø >> From: "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]>

Ø <snip>

Ø >> Le 07/01/12 12:10, Thomas Jordan a ?crit :

Ø >>> Hi,

Ø >>> I am interested in experimenting with v1.48 Boost.Move and

Ø >>> Boost.Container. However, I am otherwise constrained to using Boost

Ø >>> libraries v1.33.1 with

Ø >>> a Sun C++ v5.10 compiler. I couldn't seem any 'Boost library

Ø >>> dependencies' listed in the Move/Container documentation, but a

Ø >>> quick look through the header files suggests

Ø >>> that it is mainly MPL and Type Traits. So...

Ø >>> First question: would it be feasible for me to combine the headers

Ø >>> for these two libraries with the v1.33.1 libraries and get it to

Ø >>> work (albeit maybe with a little customisation), or would it be a

Ø >>> big job/non-starter?

Ø >>> Second question - I don't see any performance analysis published for

Ø >>> Boost.Move. I know that move semantics is about more than improved

Ø >>> performance, but am interested in that side of things, especially as

Ø >>> the above compiler appears suboptimal in terms of copy elision and

Ø >>> RVO. I am wondering for example whether are there any

Ø >>> (compiler-specific) factors which could mitigate against the

Ø >>> performance benefits of doing a move vs a copy of a vector, using

Ø >>> these libraries, for example.

Ø >>>

Ø >>

Ø >> Hi,

Ø >>

Ø >> unfortunately Boost.Move and Boost.Container are not working up to now

Ø >> on Sun c++ even on trunk (1.49). See

Ø >>

Ø >>

Ø >> Best,

Ø >> Vicente


Ø >Thanks for pointing me to that. In general is there anything more

Ø >detailed than pass/fail available to look at?

Ø >Is the assumption that something with so many fails it not fixable one

Ø >the library side, and is not worth investigating?

Ø >

Ø >

Ø Lastly there were some issues reporting the failure on the Sandia

Ø testers. Sun compiler miss a lot of useful features for many Boost

Ø libraries.

Ø I think the best you can do is to install the version 1.48 (or the

Ø trunk), run the tests yourself, look for the first failures in

Ø Boost.Move and try to understand what is going wrong. Report the

Ø failures here and try to solve them with the help of Ion and the Boost

Ø comunity.


Ø Vicente

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?


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