2016-03-02 16:06 GMT-03:00 Joel FALCOU
On 02/03/2016 18:23, Bruno Dutra wrote:
More specifically, if sequences are explicitly folded, iterators are explicitly tracked or any other mandatorily recursive algorithm is used, then I agree with you that using Metal as a backend for Boost.MPL would only bring marginal improvements at most.
However, if mostly algorithms that may be somehow expressed in terms of variadic template expansion are used, such as transform, find, remove, replace, contains, partition, etc., then most surely dramatic improvements would be perceived.
Since you mentioned performance, I would like to clarify that Metal was not designed to be the fastest TMP library out there, nor it is advertised as such, rather I pose that it is just fast enough for mainstream metaprogramming and that’s already a couple of orders of magnitude faster than Boost.MPL in most cases. That means I actively avoided such optimizations as fast tracked recursion and unrolling, which tend to demand additional template specializations, which clutter the code base and thus impair clarity and maintenance. My goals were instead make sure Metal was as easy as possible to maintain and that is why I believe it is a good fit for Boost. I invite you and everyone else to briefly browse through the source code [1], so you can see I did try hard to keep it simple and easy to understand.
Some points there :
- Brigand as library is on the road to be submitted to boost. But now, we need to make it more mature and complete. It's a valid question for us as at least 3 Boost Libraries developers asked us to do so so they can use it inside their library. Boost.Dispatch and Boost.SIMD, libraries I co-write, also use brigand internally.
Should I take it as an invitation for me to withdraw from my proposals? - Boost.MPL idioms from C++2003 are archaic by now. As Edouard pointed
out, rewriting MPL in C++11 is a mere upgrade, a large effort for a meager gain. The road we choose to follow with Brigand was to provide a TMP library with updated idioms and so, an updated interface.
Once again I should stress Metal is _not_ a mere remake of Boost.MPL. Do please take the time to browse through the example I set up on the documentation. [1] Please notice I made two separate yet complimentary proposals here: 1. Make Metal into a new version of Boost.MPL API, i.e. update idioms; 2. Reimplement Boost.MPL based on Metal for backward performance improvements.
- Compile time performances nowadays is probably the ONE issue people raise about complex (or even simple in some cases) template metaprogramming. To make TMP a day-to-day tool for average joe developer in the wild is to ensure that compile times are manageable. So I think focusing on CT-performance must be target #1 for any modern TMP library, hence our design choices in brigand.
Please allow me to disagree, targets #1 and #2 of any library must be correctness and maintainability**. Even though Metal isn't designed to be the fastest out there, please notice it does performs admirably for datasets well into the thousands, which should be far more than enough for an average Joe developer in the wild, who, mind you, won't be building static state machines of 10k nodes every other day. I do understand such use cases exist and must be addressed, but I don't think they fit the concept of everyday metaprogramming. You might argue there's no point in pushing TMP forward now that Boost.Hana is around, if not to reach extreme performance. Well, it's not because Python is around that we stopped pushing C++ forward have we? ** Incidentally, the following is quoted from the Boost Library Requirements [2] Design and Programming Aim first for clarity and correctness; optimization should be only a secondary concern in most Boost libraries. [1]: http://brunocodutra.github.io/metal/#parsing_raw_literals [2]: http://www.boost.org/development/requirements.html Regards, Bruno Dutra