I'm kick-starting the development effort to reimplement Phoenix on top of Proto. There's already been some discussion off-list among the interested parties, but there was general agreement to move the discussion here to do our work out in the open and possibly involve more people. To that end, I have ... ... created a Wiki page for coordinating our efforts: https://svn.boost.org/trac/boost/wiki/BoostPhoenix3 ... created a branch at branches/phoenix_v3. Anybody interested in helping out or just following along should do the following from BOOST_ROOT (trunk): cd boost svn co https://svn.boost.org/svn/boost/branches/phoenix_v3/boost/phoenix cd ../libs svn co https://svn.boost.org/svn/boost/branches/phoenix_v3/libs/phoenix There is nothing in boost/phoenix right now but stub headers, and libs/phoenix is simply copied from trunk/libs/spirit/phoenix. On the Wiki I put uploaded a miniphoenix.cpp file that demonstrates some ideas I have about what Phoenix-on-Proto might look like. Feedback is welcome. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
I'm kick-starting the development effort to reimplement Phoenix on top of Proto. There's already been some discussion off-list among the interested parties, but there was general agreement to move the discussion here to do our work out in the open and possibly involve more people. Very interesting. You mention modifying MPL/PROTO/FUSION in the process, what extends of changes do you expect ?
Anyway, count me in for testing and stuff. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
Joel Falcou wrote:
Eric Niebler wrote:
I'm kick-starting the development effort to reimplement Phoenix on top of Proto. There's already been some discussion off-list among the interested parties, but there was general agreement to move the discussion here to do our work out in the open and possibly involve more people.
Very interesting. You mention modifying MPL/PROTO/FUSION in the process, what extends of changes do you expect ?
On the wiki (https://svn.boost.org/trac/boost/wiki/BoostPhoenix3), I list two outstanding issues that may require changes to Proto. Mostly, I imagine that some changes and extensions to Proto might help to knock compile times down.
Anyway, count me in for testing and stuff.
OK, thanks. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Hi, Wouldn't it be a good idea to define a roadmap ? Your impl. seems to be okay so in what order should we bring Phoenix features in ? PS : I've edited the wiki page with a link to this discussion. -- Alp Mestan
Alp Mestan wrote:
Hi,
Wouldn't it be a good idea to define a roadmap ?
I'm hoping that some casual conversation by some well-intentioned folks will suffice.
Your impl. seems to be okay so in what order should we bring Phoenix features in ?
That's a mock-up, and should be viewed as a first step in exploring the design space. It should be viewed with suspicion: how many templates does it cause to be instantiated? Can that be reduced? How do we handle by-value variable capture, and how does that affect the compile times? Etc., etc.
PS : I've edited the wiki page with a link to this discussion.
Thanks. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Fri, May 29, 2009 at 6:34 PM, Eric Niebler <eric@boostpro.com> wrote:
That's a mock-up, and should be viewed as a first step in exploring the design space. It should be viewed with suspicion: how many templates does it cause to be instantiated? Can that be reduced? How do we handle by-value variable capture, and how does that affect the compile times? Etc., etc.
Well, would it be possible for anyone who has a link to Steven's template profiler to edit the wiki page in order to add this link ? Thanks. It should be of a great help for us, at least for reducing (if possible/needed) templates instanciations etc. -- Alp Mestan
Alp Mestan wrote:
Well, would it be possible for anyone who has a link to Steven's template profiler to edit the wiki page in order to add this link ? Thanks. It should be of a great help for us, at least for reducing (if possible/needed) templates instanciations etc.
Added to the Wiki: Steven Watanabe's template profiler is checked into the Boost sandbox and can be checked out here: https://svn.boost.org/svn/boost/sandbox/tools/profile_templates. It is also in the Boost Vault and can be downloaded from here: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=profile_templates.zip&directory=Tools& -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
Added to the Wiki:
Steven Watanabe's template profiler is checked into the Boost sandbox and can be checked out here: https://svn.boost.org/svn/boost/sandbox/tools/profile_templates. It is also in the Boost Vault and can be downloaded from here: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=profile_templates.zip&directory=Tools&
Also added to the wiki are the result of a template profile run over miniphoenix.cpp. The results should interest Aleksey: Total instantiations: 2983 Location count cum. ----------------------------------------------------------- C:\boost\org\trunk\boost/mpl/if.hpp(56) 59 59 C:\boost\org\trunk\boost/mpl/if.hpp(44) 48 107 <snip> The top two templates instantiated in this program are mpl::if_ and mpl::if_c, respectively. The sad thing is that most of the instantiations of mpl::if_c are totally unnecessary. mpl::if_ happens to be implemented in terms of mpl::if_c so that any instantiation of mpl::if_ causes an additional instantiation of mpl::if_c. If anything can be done to eliminate this unnecessary instantiation, it'll speed up most template metaprograms across the board. For my part, I always take care in Proto to use mpl::if_c instead of mpl::if_ for just this reason, but other libraries used by Proto don't take this measure. Isn't profiling interesting? -- Eric Niebler BoostPro Computing http://www.boostpro.com
AMDG Eric Niebler wrote:
Also added to the wiki are the result of a template profile run over miniphoenix.cpp. The results should interest Aleksey:
Total instantiations: 2983
Location count cum. ----------------------------------------------------------- C:\boost\org\trunk\boost/mpl/if.hpp(56) 59 59 C:\boost\org\trunk\boost/mpl/if.hpp(44) 48 107 <snip>
The top two templates instantiated in this program are mpl::if_ and mpl::if_c, respectively. The sad thing is that most of the instantiations of mpl::if_c are totally unnecessary. mpl::if_ happens to be implemented in terms of mpl::if_c so that any instantiation of mpl::if_ causes an additional instantiation of mpl::if_c.
If anything can be done to eliminate this unnecessary instantiation, it'll speed up most template metaprograms across the board.
Something like this should work: template<class Cond, class If, class Else, class Tester = boost::mpl::true_> struct if_ { typedef Else type; }; template<class Cond, class If, class Else> struct if_<Cond, If, Else, boost::mpl::bool_<Cond::value> > { typedef If type; }; but it may be less portable.
For my part, I always take care in Proto to use mpl::if_c instead of mpl::if_ for just this reason, but other libraries used by Proto don't take this measure.
eval_if is even worse in libraries that use it heavily. eval_if -> if_ -> if_c.
Isn't profiling interesting?
In Christ, Steven Watanabe
Steven Watanabe wrote:
Something like this should work:
template<class Cond, class If, class Else, class Tester = boost::mpl::true_> struct if_ { typedef Else type; };
template<class Cond, class If, class Else> struct if_<Cond, If, Else, boost::mpl::bool_<Cond::value> > { typedef If type; };
but it may be less portable. What about testing it ? Maybe we can even take advantage of the running Bug Spree week ? I have more than 300 invocation of enable_if and maybe 100 use of if_ in my main library and I'll give my left hand for getting those faster.
________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
Eric Niebler wrote:
Also added to the wiki are the result of a template profile run over miniphoenix.cpp. The results should interest Aleksey:
Total instantiations: 2983
Location count cum. ----------------------------------------------------------- C:\boost\org\trunk\boost/mpl/if.hpp(56) 59 59 C:\boost\org\trunk\boost/mpl/if.hpp(44) 48 107 <snip>
The top two templates instantiated in this program are mpl::if_ and mpl::if_c, respectively. The sad thing is that most of the instantiations of mpl::if_c are totally unnecessary. mpl::if_ happens to be implemented in terms of mpl::if_c so that any instantiation of mpl::if_ causes an additional instantiation of mpl::if_c.
If anything can be done to eliminate this unnecessary instantiation, it'll speed up most template metaprograms across the board. For my part, I always take care in Proto to use mpl::if_c instead of mpl::if_ for just this reason, but other libraries used by Proto don't take this measure.
That's good to know. It justifies to get back to Spirit and change all if_<> to be if_c<>. I'll probably go ahead and do that asap.
Isn't profiling interesting?
Indeed. It's always pointing to things nobody expected to be a problem... Regards Hartmut
Eric Niebler wrote:
The top two templates instantiated in this program are mpl::if_ and mpl::if_c, respectively. The sad thing is that most of the instantiations of mpl::if_c are totally unnecessary. mpl::if_ happens to be implemented in terms of mpl::if_c so that any instantiation of mpl::if_ causes an additional instantiation of mpl::if_c.
From more profiling, I see that another main offender of needless template instantiations is mpl::sequence_tag, implemented as follows: template< typename BOOST_MPL_AUX_NA_PARAM(Sequence) > struct sequence_tag : aux::sequence_tag_impl< ::boost::mpl::aux::has_tag<Sequence>::value , ::boost::mpl::aux::has_begin<Sequence>::value >::template result2_<Sequence> { }; This metafunction is invoked from *everywhere*, and each instantiation of sequence_tag causes additional instantiations to: has_tag, has_begin, sequence_tag_impl, and sequence_tag_impl::result2_. Yech. Here's a different implementation that cuts that reduces it from 5 instantiations to 2. Figuring out which compilers accept this is left as an exercise to the reader. ;-) namespace aux { typedef char sequence_tag_impl_has_tag; typedef char (&sequence_tag_impl_has_begin)[2]; typedef char (&sequence_tag_impl_has_neither)[3]; template< typename Sequence > sequence_tag_impl_has_tag test_sequence_tag_impl(Sequence *, typename Sequence::tag *, typename Sequence::begin *); template< typename Sequence > sequence_tag_impl_has_tag test_sequence_tag_impl(Sequence *, typename Sequence::tag *, ...); template< typename Sequence > sequence_tag_impl_has_begin test_sequence_tag_impl(Sequence *, typename Sequence::begin *, ...); template< typename Sequence > sequence_tag_impl_has_neither test_sequence_tag_impl(Sequence *, ...); template< typename Sequence, std::size_t SequenceType > struct sequence_tag_impl { typedef non_sequence_tag type; }; template< typename Sequence > struct sequence_tag_impl< Sequence, sizeof(sequence_tag_impl_has_tag) > { typedef typename Sequence::tag type; }; template< typename Sequence > struct sequence_tag_impl< Sequence, sizeof(sequence_tag_impl_has_begin) > { typedef nested_begin_end_tag type; }; } // namespace aux template< typename BOOST_MPL_AUX_NA_PARAM(Sequence) > struct sequence_tag : aux::sequence_tag_impl< Sequence , sizeof(::boost::mpl::aux::test_sequence_tag_impl<Sequence>(0,0,0)) > { }; -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
I'm kick-starting the development effort to reimplement Phoenix on top of Proto. There's already been some discussion off-list among the interested parties, but there was general agreement to move the discussion here to do our work out in the open and possibly involve more people. To that end, I have ...
... created a Wiki page for coordinating our efforts: https://svn.boost.org/trac/boost/wiki/BoostPhoenix3
... created a branch at branches/phoenix_v3. Anybody interested in helping out or just following along should do the following from BOOST_ROOT (trunk):
cd boost svn co https://svn.boost.org/svn/boost/branches/phoenix_v3/boost/phoenix cd ../libs svn co https://svn.boost.org/svn/boost/branches/phoenix_v3/libs/phoenix
There is nothing in boost/phoenix right now but stub headers, and libs/phoenix is simply copied from trunk/libs/spirit/phoenix.
On the Wiki I put uploaded a miniphoenix.cpp file that demonstrates some ideas I have about what Phoenix-on-Proto might look like. Feedback is welcome.
First of all, thanks for kick-starting the development, Eric! I looked at the prototype and it looks good. Reading the replies to this post, I'd not worry about compile time too much at this point but at least have a keen eye on it. I'd want to concentrate more on the extension mechanism and its interface. To Alp and the folks who came in later, let me explain... Quite distinguishable in libraries that I wrote (Spirit, Phoenix and Fusion), is that there are two APIs: 1) The user API and 2) the extension API. The user API is what the user normally sees. The extension API, is typically for advanced users. I as library writer am a prime client of the extension API. The entire library itself is built from that extension API. This is essentially the core/kernel of the library. Making this extension interface as simple and clear as possible, makes it is easier for other people to contribute code. It also makes it a joy to port. Ideally, if the proto port uses the same extension API as Phoenix-2, then all the modules above the core could, in theory, remain as-is. Alas, this is not possible due to a couple of reasons, but still, the extension mechanism made Eric's task easier (I would say) when he did the initial port to proto. Everything funnels through this extension API. Port it and everything else follows. At this point, I'd say that the design of the extension API is of most crucial significance. I'll have some feedback on this as soon as I learn more about the initial prototype. Those who have seen or used my other libraries' extension interfaces (Dan, Hartmut, etc.) please feel free to chime in. More to come... Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Joel de Guzman wrote:
First of all, thanks for kick-starting the development, Eric!
Thanks for writing Phoenix in the first place!
I looked at the prototype and it looks good. Reading the replies to this post, I'd not worry about compile time too much at this point but at least have a keen eye on it. I'd want to concentrate more on the extension mechanism and its interface. <snip>
I think we have to make compile-time performance a priority -- and it may influence the extensibility API. If we bill this as Lambda-2 and it causes noticeable compile lag over Lambda-1, folks will be rightly disappointed. Frankly, I wish I had the template profiler before I settled on Proto's extensibility API because I might have done things differently.
At this point, I'd say that the design of the extension API is of most crucial significance. I'll have some feedback on this as soon as I learn more about the initial prototype. Those who have seen or used my other libraries' extension interfaces (Dan, Hartmut, etc.) please feel free to chime in.
Yes, please. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
Joel de Guzman wrote:
First of all, thanks for kick-starting the development, Eric!
Thanks for writing Phoenix in the first place!
I looked at the prototype and it looks good. Reading the replies to this post, I'd not worry about compile time too much at this point but at least have a keen eye on it. I'd want to concentrate more on the extension mechanism and its interface. <snip>
I think we have to make compile-time performance a priority -- and it may influence the extensibility API. If we bill this as Lambda-2 and it causes noticeable compile lag over Lambda-1, folks will be rightly disappointed.
Ok, that makes sense. Let's hope we don't have a clash of priorities though. I, for one, would value elegance of the API over compile time performance. To me, it's pretty much a given that we can never equal Lambda nor Phoenix-2's CT performance: there will be a noticeable CT lag. I wish I am wrong.
Frankly, I wish I had the template profiler before I settled on Proto's extensibility API because I might have done things differently.
At this point, I'd say that the design of the extension API is of most crucial significance. I'll have some feedback on this as soon as I learn more about the initial prototype. Those who have seen or used my other libraries' extension interfaces (Dan, Hartmut, etc.) please feel free to chime in.
Yes, please.
Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
participants (6)
-
Alp Mestan -
Eric Niebler -
Hartmut Kaiser -
Joel de Guzman -
Joel Falcou -
Steven Watanabe