Subject: Re: [boost] [GSoC] [Boost.Hana] Formal review request
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2014-07-29 17:51:06
Nathan Crookston <nathan.crookston <at> gmail.com> writes:
> Hi Louis,
> Regarding performance, I note that you have several graphs in the reference
> section showing (generally) good performance scaling. I think it would be
> useful to add a section to the manual speaking generally about
> performance. One common criticism of metaprogramming is the time it takes
> to compile and link. Addressing it would certainly help someone understand
> more benefits of the library without having to follow the boost list.
I agree that a section on performance could be useful. At least explaining
roughly how performance is measured at compile-time would be a nice to have.
At the same time, I'm inclined to think that people who don't know about this
stuff are not C++ power users and should not have to worry about it anyway,
while those who know don't need it explained to them. Also, one goal of Hana
was to make metaprogramming reasonably efficient so you would not actually
have to care about this stuff anymore.
I'll add a section on performance, or at least how you can maximize
performance with Hana, but I don't know in what level of details I'll go,
because we could probably write a small book on compile-time performance.
> I have a few other suggestions about the documentation that I can send
> along, if you're looking for that at this point.
Definitely; please shoot anything you've got.
> It sounds like you're already planning to do this, but mentioning
> type_list<>, even if it's essentially just list(type<>...) would help show
> that this is a valid replacement for MPL.
I did not mention it anywere because I'd like to see this one go. It's
there for performance reasons only, but it's possible to implement those
optimizations in `list` without introducing a new container. I've started
writing a cheat sheet to translate between MPL and Hana; this should pretty
much give you a mechanical transformation for all algorithms written with
> Do you plan to implement things like MPL's vector_c? I ask because a C++14
> units library could be much nicer than the (already nice) boost units
> library. Using Hana could be nice for compile times.
See integer_list. However, like type_list, I'd like to see this one go. Note
that optimizations for homogeneous sequences are not implemented yet (so
integer_list is not implemented with an internal always-constexpr array).
> My only concern would be the performance on other compilers once they
> implement the necessary features. Is there some assurance that the lambda
> trick would work (i.e. be fast) on g++?
For this, we'll have to run the benchmarks on GCC. The benchmark suite is
hooked up in the CMake-generated build system and the benchmarks will run
on GCC with 2-3 modifications to a Ruby gem I use internally.
> I look forward to playing with this in about a month. I'll definitely post
> a review if and when a review occurs.