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/