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

Ø  >> http://www.boost.org/development/tests/trunk/developer/container.html.

Ø  >>

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

Ø  HTH,

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

Regards,
T.