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.