Re: [Boost-users] metafunction invocation performance
The solution to this one is provided by Joaquin, in his reply below: I tried compiling your code with MSVC++ 8.0 and it is indeed incredibly slow. After playing a little with the code I realized that MPL views are the culprit here: for some reason it is much faster to fold on a vector-based computation rather than a view: template<typename Sequence1,typename Sequence2> struct sequence_product : boost::mpl::fold< Sequence1, boost::mpl::vector0<>, boost::mpl::copy< boost::mpl::transform< Sequence2, pair_with<boost::mpl::_2> >, boost::mpl::back_inserter<boost::mpl::_1> > > {}; This transformation on sequence_product and seq_seqpair_product alone improved the performance tremendously. Additionally I've tried a small optimization: in seq_seqpair_product it is preumable better to fold on Sequence rather than SequencePair, since on average the first is expected to be shorter. Truth be said, I haven't detected any improvement with this, anyway.
Shouldn't there be a dot-product or cross-product of mpl sequences as a general algorithm? and not just 2 sequences but N.
I guess it is the O(n^2) behavior that deterred the author from including the algorithm (much as STL usually does not contain quadratic algorithms). It might be a worthy addition, nonetheless Joaquin --------- Interesting why a joint_view slower than the alternative. This result confirmed then on MSVC8 , gcc4.1, Intel10... regards, /Hicham
On Jul 4, 2008, at 7:36 AM, Hicham Mouline wrote:
The solution to this one is provided by Joaquin, in his reply below:
I tried compiling your code with MSVC++ 8.0 and it is indeed incredibly slow. After playing a little with the code I realized that MPL views are the culprit here: for some reason it is much faster to fold on a vector-based computation rather than a view:
I learned an interesting and somewhat depressing fact from Doug Gregor recently. Most compilers don't use a canonical representation of types. That is, in most compilers, int* and add_pointer<int>::type occupy separate pieces of storage, and the complier jumps through some complicated hoops when it needs to evaluate them for sameness. Of course that also means that vector<int*> and vector<add_pointer<int>::type> are represented separately, etc. That can totally skewer the gains of memoization, among other things.f Apparently recent versions of GCC have canonical type representation, and so does Clang (for what that's worth -- no C++ yet), but I betcha MS doesn't, and that would help explain why views cost more. -- David Abrahams BoostPro Computing http://boostpro.com
participants (2)
-
David Abrahams
-
Hicham Mouline