Re: [boost] [metal] Feature Complete - Request for Feedback

Subject: Re: [boost] [metal] Feature Complete - Request for Feedback
From: Bruno Dutra (brunocodutra_at_[hidden])
Date: 2017-02-22 19:22:35

On Wed, Feb 22, 2017 at 12:20 PM, Niall Douglas via Boost <
boost_at_[hidden]> wrote:

> >> * Metal is much lighter conceptually than Hana and in fact relies
> >> on only a couple of very simple concepts that are precisely defined
> >> early in the documentation, which are sufficient to formally
> >> describe every construct that the library provides [1] * being
> >> fined tuned for heterogeneous programming more than anything else,
> >> Hana happens to also support type level computations, while Metal
> >> is specifically designed for that end and is thus able to provide
> >> better tools in my opinion.
> >
> > I'm not really sure I fully understand your comparison to Hana.
> >
> > It sounds like you're saying that "Metal is smaller and simpler than
> > Hana", in that Metal (1) has simpler/fewer concepts and (2) has a
> > more restricted focus. It seems that Metal probably does something
> > Hana does not, but I'm not sure what it is from this overview.
>
> My best understanding is that Hana is much more like Phoenix and just
> happens to also be able to do TMP. One of the things which annoys me
> about some of those who write "lightweight metaprogramming frameworks
> performance superior to Hana" with all sorts of wild unjustified claims
> is that they are usually comparing their TMP framework to Hana being
> used in a mode Hana was not intended by Louis to be its main use case.
> So of course a custom, specially written single purpose framework is
> going to beat a general purpose framework. So what.
>
> Bruno's Metal doesn't make extravagant claims based on unfair
> comparisons of apples to oranges, and is to be presented for peer review
> here. I therefore strongly support it over other lightweight template
> metaprogramming frameworks. I definitely think there is a space in Boost
> between full fat Hana being used in subset mode and a more specialised,
> single purpose TMP framework with significantly better time and space
> complexities. I've only skimmed the surface of Metal, but what I've seen
> so far looks impressive.
>

Thanks a lot for your feedback Niall!

We happen to share a very similar view of Hana. It's a fantastic tool for
the processing of heterogeneous data sets that, because of its generality,
also happens to do pure type metaprogramming, but that is far from it's
core use case. Indeed, I just discussed on a previous email the fact that
Hana can't be used effectively to control overload resolution of function
calls, which is something to be expected from a pure TMP library, but not
necessarily from a general heterogeneous library. In fact it is much
trickier to provide strong SFINAE guarantees in the latter case and not at
all a surprise that Louis decided not to provide them.

> When you propose Metal, I think it will be important to justify why
> > Metal is useful in Boost even though Boost already has Hana. For
> > example, is there something Metal does better (where "better" could
> > be smaller code, faster code, faster compile, etc)? I think "simpler
> > API" by itself is not quite enough, but I'm sure you have other
> > reasons. It would be good to have a section of your proposal to show
> > concrete examples.
>
> Hana's really, really fast at its primary intended use case. Louis put a
> ton of effort before starting Hana into benchmarking implementation
> techniques, and it shows.
>
> Hana being used for TMP isn't performance competitive, though it's way
> better than MPL or any of the previous gen libraries. Metal isn't the
> fastest of the new generation libraries from what I've been told, but
> it's competitive to them.
>
> That's my best understanding of the situation anyway, corrections are
> welcome.
>

In the beginning, Metal used to be way slower than its contenders and
somehow this unfortunate reputation stuck, but it is far from accurate
nowadays. I'm unaware of other benchmarks, but as one can see on metaben.ch,
Metal is actually the fastest on GCC, among Meta, Brigand and Hana, and
only slightly slower than Brigand on Clang, its fastest contender. Still,
even on Clang, Metal happens to be about an order of magnitude (!) faster
than Brigand on some core algorithms that are probably most used, namely
fold_left, fold_right, reverse and at.