Re: [boost] [MPL] A Proposal

Subject: Re: [boost] [MPL] A Proposal
From: Bruno Dutra (brunocodutra_at_[hidden])
Date: 2016-03-02 22:13:28

2016-03-02 16:06 GMT-03:00 Joel FALCOU <joel.falcou_at_[hidden]>:

> 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