On Wed, Feb 22, 2017 at 12:20 PM, Niall Douglas via Boost < boost@lists.boost.org> 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.