picongpu
picongpu copied to clipboard
ComputationalRadiationPhysics
Replace Boost::MPL
According to this reddit post the C++11 library Brigand is the hot new sh*t to replace the quite inactive and in C++11 times inefficient + C++98 verbose Boost MPL library.
We should take a look and evaluate it it's worth switching to a more modern and active dependency. This could also have a very positive impact on compile time.
An alternative for the future can also be Boost::HANA, but compiler support seems quite demanding as of today.
ccing @psychocoderHPC @theZiz
This is by far not the only option! Currently there are multiple libraries proposed to be included into boost and even more coming. There are:
- meta (boost review request)
- mp11
- brigand
- kvasir
- and even more
(the links may not be correct) See e.g. here for a comparison or many threads on the boost developer mailing list.
Wonderful, thanks! And anything in sight already? Looks all very recent. Please keep us posted!
alpaka does also have some meta programming tools within "alpaka/meta/" which are similar to mp11. alpaka does not rely on MPL anymore. The design of the type computations allows any variadic template to be used as type list. However, most of the time, std::tuple is used. Furthermore alpaka specializes the MPL templates for std::tuple so that those type lists can be used within native MPL commands (e.g. type parametrized boost tests).
I would not switch to one solution, which looks promising at the moment but may be not maintained anymore later. Instead I would abstract the functionality we need first using MPL as backend but with the easy option to change for faster solutions later. As far as I read at reddit, the MPL is not dead, but done. However as it highly depends on the preprocessor, it's slow, which can't be fixed without loosing C++03 compability.
I would not switch to one solution, which looks promising at the moment but may be not maintained anymore later.
Yes sure, no one is about to rush here until a well maintained third-party lib is found and evaluated.
Instead I would abstract the functionality we need first using MPL as backend [...]
No, I would not write yet an other wrapper around a simple list based meta-programming library. We can just wait what boost decides for and then evaluate their C++11 meta-programming lib if it fits our needs. Everything else is a waste of time that will end in building adapters for everything.
As far as I read at reddit, the MPL is not dead, but done.
yep. feature-complete but verbose (since C++03 compat.). C++03 style should be removed from our project wherever we can not only to be clean and less verbose but also to be faster in most cases (work-arounds and fallbacks do consume compile time and especially maintenance time, too).
@BenjaminW3 @psychocoderHPC digging out this thread, do you know which of the ones above will make it in boost? :)
From activity, popularity and compilation times, brigand and kvasir seem to be the most attractive to me from checking the projects again: http://metaben.ch/
And the winner is - none of yours: mp11. It should be part of the next boost release. It is very similar to the alpaka metaprogramming tools. When we could raise the boost version that high, I will definitely use it.
Interesting, thanks! Does it work well with NVCC 7.5+?
I just started to love kvasir::mpl :'(, they really care about compile time :)
All right, if you are eager to test mp11 in the current boost develop branch even before the release we would be very interested about the results. If it works for alpaka and all its backends we should definitely put it as the MPL replacement in PIConGPU as well!
It is in the official boost repos now since 1.66.0. Any idea why there are now 3 TMP libs in boost? I mean they included Boost.Hana as the successor to Boost.MPL (I think) but now they also have Boost.mp11.
Seems like the same mess as with the lambdas in Boost.Bind, Boost.Lambda, Boost.Phoenix, Boost.Phoenix2, Boost.Proto, Boost.Phoenix3,...
It is in the official boost repos now since 1.66.0.
Good to know!
Boost hana is not a successor of MPL but does the connection from CT to RT as unified superset of MPL+Fusion: http://www.boost.org/doc/libs/1_63_0/libs/hana/doc/html/index.html Out of the three (or more) proposed MPL successors only one was included, mp11.
yes, lambdas is a mess in boost (but a bit off-topic for this thread) :)
I think this work should be prioretized based on the timetrace I took in #3808.
Based on my (now) experience with Boost and the author(s) I'd recommend MP11. Peter (the guy developing/maintaining it) is quite knowledgeable and MP11 seems to be a very decent lib. Especially if you use Boost anyway. Over and out ;)
Based on my (now) experience with Boost and the author(s) I'd recommend MP11. Peter (the guy developing/maintaining it) is quite knowledgeable and MP11 seems to be a very decent lib. Especially if you use Boost anyway.
Same experience here. Peter Dimov is always helpful when you open issues and the lib is already available because we have Boost in many projects anyway. And if that ever becomes a problem, Boost.Mp11 can be used standalone outside Boost as well. This is also why LLAMA uses Boost.Mp11.
PIConGPU is heavily relying on compile-time lambda functions. Those are used in param files and internally. As I know @sbastrakov sid in the past where he started to change from boost::mpl to boost::mp11 that lamda functions do not exist mp11.
boost mpl lambda functions: https://www.boost.org/doc/libs/1_65_1/libs/mpl/doc/refmanual/lambda.html
I wonder how much of this meta lambda functionality you need. boost::mp11 has higher order meta functions as well via template template parameters or so-called quoted metafunctions. Maybe such meta function lambdas could also be built on top of mp11 in a short amount of code. Could you point me at a typical use of such lambdas?
From what i remember, our most common pattern is as here. Have a struct taking particle species as a template parameter (in this example defined above in the same file, often it would be somewhere deep inside PIConGPU), and then applying it for the given species typelist. Meaning, instantiating an object for each relevant species and calling its operator(). The substitution of real species type instead of placeholder is here as far as i can see. To be honest, this appears not that difficult. So probably there was something more that posed an issue back then
In addition to what @sbastrakov wrote: The point of the lambda functions is that it is not defined which template parameter should be substituted with an explicit type. Additionally to substitute a template parameter apply can be defined within your struct even if this struct has no template parameter, this opens you the way to transform a type in case boost::mpl::apply is called.
The example functor is not depending on a species, if a species is applied it returns the identity of the functor type. https://github.com/ComputationalRadiationPhysics/picongpu/blob/58b957bfb0d5795bd49aa0a0d7372376ba5344c1/include/picongpu/particles/manipulators/generic/FreeRng.hpp#L81-L85
This is the first real issue I tried to do with PIConGPU but it is still not implemented. Hopefully someone else will have more luck with it
Well, it was almost completed by me in #3834 and #3983. It failed a few CI tests, but the rest was good. Let's see whether I can finish that up at some point.