Re: [boost] About all these metaprogramming libraries

Subject: Re: [boost] About all these metaprogramming libraries
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-03-19 23:42:31

On 19/03/2017 19:57, Louis Dionne via Boost wrote:
> 
>> If Hana is the slow, "full fat" metaprogramming library,
> 
> Hana is not a "slow, full fat" metaprogramming library. Quite far from that.
> It's just that for pure type-level metaprogramming (which by the way is
> quite rarely needed nowadays with deduced return types), we can't possibly
> be as fast as Brigand, Metal or such type-level only solutions that is
> highly optimized for that precise use case.

Surely you forgot to append the condition "we can't possibly be as fast
as ... *with current compilers*"?

>> is there space remaining for exactly one fast, "lightweight"
>> metaprogramming library?
> 
> The problem is that the term metaprogramming is overloaded to mean several
> things. It can either mean pure type-level metaprogramming (MPL world), or
> algorithms on tuples (Fusion world). It HAPPENS that the latter is powerful
> enough to perform the former; this is what Hana allows and then you only
> need one metaprogramming library. However, that is heavier compile-time wise
> and does not scale as well as a library that was crafter with type
> computations only from the start. And if that was your question, I don't
> think you can do what Hana does (i.e. handle Fusion + MPL) while being
> significantly faster. You might be able to be some small constant factor
> faster, but that's it.

Again, Hana is slower than these other libraries because *current
compilers* have been heavily optimised for type based metaprogramming,
and not yet for deduced return type metaprogramming.

But this won't be the situation soon. The Visual Studio team are
actively targeting MSVC at Hana. Knowing them, even after it's compiling
100% clean they'll then go on to make MSVC *fast* with Hana. I don't
doubt the clang guys are also thinking the same thing, that a Hana based
benchmark could be real useful to shining a spotlight on code which is
currently highly suboptimal in their compilers.

(As an aside, a Hana based compiler performance benchmark would be
awesome, you should write one with all that free time you have :) and
put it online with graphs or something)

> By the way, these libraries for pure type-level metaprogramming have the
> same problem, it's just that their constant factors are smaller than Hana's.
> Take any of these libraries and try to process a type list with 200K
> elements while doing something non-trivial. The fundamental problem is that
> we need language-level support for metaprogramming if we want to go
> completely crazy with it, and some of us are working exactly on this right
> now for C++next (or maybe the one after).

So I've got to ask the question: Are we not jumping the gun here with
adding any metaprogramming library to Boost beyond Hana? If we wait a
few years, the performance gap between Hana and any of these other
libraries will probably close very significantly to the point of
inconsequence.

Let me put this another way: do any of the other metaprogramming
libraries add *in pure API or capability terms* anything over Hana?
Because if they add nothing new in terms of a better API, or able to do
extra stuff, there is a *strong* argument that we should just wait and
see what future compilers look like before adding more metaprogramming
libraries.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/