build variant output directory
Hello, I was just wondering if there is some way of defining a variant's build output directory. The current build output directory nesting is just to deep for my project. Since I only have one debug variant and one release variant having a simple build output directory like: bin/debug bin/release would completely suffice. But instead boost build insists on storing everything in directories based on the selected feature set: bin\msvc-8.0\debug\threading-multi bin\msvc-8.0\release\debug-symbols-on\threading-multi Also notice the additional debug-symbols-on in the release build path since I selected to enable debug symbols for release builds. Regards, Sebastian
Sebastian Hauer wrote:
Hello, I was just wondering if there is some way of defining a variant's build output directory. The current build output directory nesting is just to deep for my project. Since I only have one debug variant and one release variant having a simple build output directory like:
bin/debug bin/release
would completely suffice. But instead boost build insists on storing everything in directories based on the selected feature set:
bin\msvc-8.0\debug\threading-multi bin\msvc-8.0\release\debug-symbols-on\threading-multi
Also notice the additional debug-symbols-on in the release build path since I selected to enable debug symbols for release builds.
hi sebastian, i usually do a: bjam [...] stage every lib/dll is then copied into %BOOST_ROOT%/stage/lib. short enough? :) -- regards, dave
Hello Dave, I meant to send this email to the boost-build list but accidentally sent it to boost-users, thanks for the reply anyway. Regards, Sebastian
I did some boost::mpl programming intended for high performance mathematical calculation. The class had some template parameter which was supposed to be a boost::mpl::vector containing boolean elements. Operations between two instances (with different template vector classes) should result in a new type with all the vector elements being the result of an or operation. I relied on that the boost::mpl::for_each function should be inlined. I also relied on that references to the vector elements from an if-statement should result in removed code -- means any if(vector-element) .. else .. should result in code which does not check for this vector element anymore, since it is constant for every type. What I ended up with were function calls. First the execute methods inside the for_each.hpp were not inlined. I added some __forceinline (or matching attribute for gcc) into the boost::mpl::for_each code: diff -wr boost_1_35_0/boost/mpl/for_each.hpp boost_1_35_0.saved/boost_1_35_0/boost/mpl/for_each.hpp 41,42c41 < __attribute__ ((__always_inline__)) < inline static void execute( ---
static void execute(
61,62c60 < __attribute__ ((__always_inline__)) < inline static void execute( ---
static void execute(
92d89 < __attribute__ ((__always_inline__)) 107d103 < __attribute__ ((__always_inline__)) The next problem was that there was some treatment of some value (which I don't understand) which was not inlined: diff -wr boost_1_35_0/boost/utility/value_init.hpp boost_1_35_0.saved/boost_1_35_0/boost/utility/value_init.hpp 55,56d54 < __attribute__ ((__always_inline__)) < inline 75,76d72 < __attribute__ ((__always_inline__)) < inline 82,83d77 < __attribute__ ((__always_inline__)) < inline 92,93d85 < __attribute__ ((__always_inline__)) < inline 99,100d90 < __attribute__ ((__always_inline__)) < inline 106,107d95 < __attribute__ ((__always_inline__)) < inline 115,116d102 < __attribute__ ((__always_inline__)) < inline 122,123d107 < __attribute__ ((__always_inline__)) < inline I don't understand what is being achieved with this value_init stuff. We are dealing with const bool values, which do not need to reside on the stack again. Somehow these value initializations made it into the optimized assembler code and where not removed -- they are also not referenced in the assembler code -- loading 0 or 1 byte literals into stack variables, which were not referenced later. Finally I ended up with slower code than before. It should result in faster code, since some unnecessary operations are now removed. The idea of these type conversions and checked constructors and assignment operators is very appealing. Thanks for the mpl library. I hope you consider my experience in making this code faster and so more widely applicable. Peter Foelsche
On Thursday 02 October 2008 20:54:10 peter_foelsche@agilent.com wrote:
I don't understand what is being achieved with this value_init stuff. We are dealing with const bool values, which do not need to reside on the stack again. Somehow these value initializations made it into the optimized assembler code and where not removed -- they are also not referenced in the assembler code -- loading 0 or 1 byte literals into stack variables, which were not referenced later.
Could you please redo your diffs in unified format (diff -u on *NIX) and send them to the list again? Regards, Ravi
Could you please redo your diffs in unified format (diff -u on *NIX) and send them to the list again?
Regards, Ravi
I only added some attribute so that all the functions called by for_each are inlined. My changes work only with g++. Other compiler use other attributes to force inlining. Peter -wru /users/pfoelsch/boost_1_35_0.saved/boost_1_35_0/boost/mpl/for_each.hpp ./mpl/for_each.hpp --- /users/pfoelsch/boost_1_35_0.saved/boost_1_35_0/boost/mpl/for_each.hpp 2004-09-03 18:33:47.000000000 -0700 +++ ./mpl/for_each.hpp 2008-10-03 13:35:07.649710000 -0700 @@ -38,7 +38,8 @@ , typename TransformFunc , typename F > - static void execute( +__attribute__ ((__always_inline__)) + inline static void execute( Iterator* , LastIterator* , TransformFunc* @@ -57,7 +58,8 @@ , typename TransformFunc , typename F > - static void execute( +__attribute__ ((__always_inline__)) + inline static void execute( Iterator* , LastIterator* , TransformFunc* @@ -69,8 +71,8 @@ // dwa 2002/9/10 -- make sure not to invoke undefined behavior // when we pass arg. - value_initialized<arg> x; - aux::unwrap(f, 0)(boost::get(x)); + //value_initialized<arg> x; + aux::unwrap(f, 0)(arg()); typedef typename mpl::next<Iterator>::type iter; for_each_impl<boost::is_same<iter,LastIterator>::value> @@ -87,6 +89,7 @@ , typename TransformOp , typename F > +__attribute__ ((__always_inline__)) inline void for_each(F f, Sequence* = 0, TransformOp* = 0) { @@ -101,6 +104,7 @@ typename Sequence , typename F > +__attribute__ ((__always_inline__)) inline void for_each(F f, Sequence* = 0) {
<peter_foelsche <at> agilent.com> writes:
I relied on that the boost::mpl::for_each function should be inlined. [ ... ] I don't understand what is being achieved with this value_init stuff.
Hi Peter, my project suffers from this problem too. This might be related to recent rewrite of value_initialized. This issue is not critical to my project so I haven't looked closely at the value_initialized code. I wonder if there is a reason not to use use a simpler implementation for empty types (boost::is_empty<T>::value == true)? -- Alex
I changed my class using a boost::mpl::set instead of a boolean array. Now there is a great speed improvement. This stuff is great. I love automatic type generation. Again -- this speed improvement relies on my posted changes regarding the inlining of everything called from boost::mpl::for_each(). Peter -----Original Message----- From: FOELSCHE,PETER (A-SantaClara,ex1) Sent: Thursday, October 02, 2008 17:54 To: 'boost-users@lists.boost.org' Subject: [Boost-users] my experience with boost::mpl programming I did some boost::mpl programming intended for high performance mathematical calculation. The class had some template parameter which was supposed to be a boost::mpl::vector containing boolean elements. Operations between two instances (with different template vector classes) should result in a new type with all the vector elements being the result of an or operation. I relied on that the boost::mpl::for_each function should be inlined. I also relied on that references to the vector elements from an if-statement should result in removed code -- means any if(vector-element) .. else .. should result in code which does not check for this vector element anymore, since it is constant for every type. What I ended up with were function calls. First the execute methods inside the for_each.hpp were not inlined. I added some __forceinline (or matching attribute for gcc) into the boost::mpl::for_each code: diff -wr boost_1_35_0/boost/mpl/for_each.hpp boost_1_35_0.saved/boost_1_35_0/boost/mpl/for_each.hpp 41,42c41 < __attribute__ ((__always_inline__)) < inline static void execute( ---
static void execute(
61,62c60 < __attribute__ ((__always_inline__)) < inline static void execute( ---
static void execute(
92d89 < __attribute__ ((__always_inline__)) 107d103 < __attribute__ ((__always_inline__)) The next problem was that there was some treatment of some value (which I don't understand) which was not inlined: diff -wr boost_1_35_0/boost/utility/value_init.hpp boost_1_35_0.saved/boost_1_35_0/boost/utility/value_init.hpp 55,56d54 < __attribute__ ((__always_inline__)) < inline 75,76d72 < __attribute__ ((__always_inline__)) < inline 82,83d77 < __attribute__ ((__always_inline__)) < inline 92,93d85 < __attribute__ ((__always_inline__)) < inline 99,100d90 < __attribute__ ((__always_inline__)) < inline 106,107d95 < __attribute__ ((__always_inline__)) < inline 115,116d102 < __attribute__ ((__always_inline__)) < inline 122,123d107 < __attribute__ ((__always_inline__)) < inline I don't understand what is being achieved with this value_init stuff. We are dealing with const bool values, which do not need to reside on the stack again. Somehow these value initializations made it into the optimized assembler code and where not removed -- they are also not referenced in the assembler code -- loading 0 or 1 byte literals into stack variables, which were not referenced later. Finally I ended up with slower code than before. It should result in faster code, since some unnecessary operations are now removed. The idea of these type conversions and checked constructors and assignment operators is very appealing. Thanks for the mpl library. I hope you consider my experience in making this code faster and so more widely applicable. Peter Foelsche
participants (5)
-
Alexander Nasonov -
David Klein -
peter_foelsche＠agilent.com -
Ravi -
Sebastian Hauer