Template argument vs. CTAD based mapping definition

[bernhardmgruber]

Mappings in LLAMA need lots of compile time parameters. Like the following mapping definition:

using ArrayDomain = llama::ArrayDomain<2>;
const auto arrayDomain = ArrayDomain{rows, cols};
llama::mapping::AoS<ArrayDomain, Particle>{arrayDomain};
llama::mapping::SoA<ArrayDomain, Particle>{arrayDomain};
llama::mapping::SoA<ArrayDomain, Particle, true>{arrayDomain};
llama::mapping::AoSoA<ArrayDomain, Particle, AoSoALanes>{arrayDomain};
llama::mapping::Split<
        ArrayDomain,
        Particle,
        llama::DatumCoord<2>,
        llama::mapping::PreconfiguredAoSoA<8>::type,
        llama::mapping::PreconfiguredSplit<
            llama::DatumCoord<1>,
            llama::mapping::One,
            llama::mapping::PreconfiguredSplit<
                llama::DatumCoord<0>,
                llama::mapping::PackedAoS,
                llama::mapping::SingleBlobSoA,
                true>::type,
            true>::type,
        true>{arrayDomain}; // WTF?

This interface is based on template arguments. Notice there is a repetition of the array domain information, which is passed as template argument and as a ctor argument. This is redundant and could be eliminated if C++ could deduce the template argument ArrayDomain from the value arrayDomain. This feature is called CTAD (constructor template argument deduction). However, CTAD can only deduce all or nothing. So in order to use CTAD, we could have an interface like this:

llama::mapping::AoS{arrayDomain, Particle{}}; // empty instance of the Particle type list so CTAD can deduce
llama::mapping::SoA{arrayDomain, Particle{}}; // -||-
llama::mapping::SoA{arrayDomain, Particle{}, std::true_type{}}; // cannot deduce bool template parameters, need a type
llama::mapping::AoSoA{arrayDomain, Particle{}, std::integral_constant<std::size_t, AoSoALanes>{}} // really ugly
llama::mapping::Split{...}; // not implemented

This is the CTAD interface. It looks better for simpler mapping definitions and worse for more complex mapping definitions. The CTAD interface might also be more confusing for less experienced programmers.

Currently, LLAMA supports a mix of both. I would like to know which interface other people would prefer. Please add your comments!

[sbastrakov]

I think there is a missing option of using a factory function. As then you can deduce some stuff and not get affected by CTAD. It may be that you don't like this style of interfaces, but it's at least an option (that we go for a lot in alpaka and PIConGPU, but again doesn't mean it's good for llama).

[sbastrakov]

Aside from the factory approach, which I personally like, the other two look both reasonable tbh. The Split is so long as it seems to express some complicated logic (like a whole function written as a single return statement). So I would say it probably would benefit from a simplification into several smaller types or functions regardless of the chosen style.

[j-stephan]

Split in its current form needs to die in a fire. That is some evil write-only code.

With regard to the rest: I really like CTAD, but it isn't easily applicable to the more complicated cases. To keep the API consistent I therefore vote for factories everywhere. This doesn't look to bad IMO:

auto AoS = llama::make_mapping<Particle, llama::tag::AoS>(arrayDomain);
auto SoA = llama::make_mapping<Particle, llama::tag::SoA>(arrayDomain);
auto SoASingleBlob = llama::make_mapping<Particle, llama::tag::SoA, false>(arrayDomain); // I believe this or a similar interface should be possible
auto AoSoA = llama::make_mapping<Particle, llama::tag::AoSoA, AoSoALanes>(arrayDomain);

The CTAD interface might also be more confusing for less experienced programmers.

I don't think this is a factor we should consider for LLAMA; if you've arrived at a point where you actually need LLAMA (and also understand why), you're already pretty experienced. I wouldn't exactly recommend this for people who just finished the C++ Primer ;-)