AoS will be aligned and SoA will be multiblob by default #312
Conversation
f5c1af6 to
5cca014
Compare
5cca014 to
0e4581f
Compare
| @@ -162,7 +162,7 @@ struct UpdateKernel | |||
| if constexpr (MappingSM == AoS) | |||
| return llama::mapping::AoS{arrayDims, Particle{}}; | |||
| if constexpr (MappingSM == SoA) | |||
| return llama::mapping::SoA{arrayDims, Particle{}}; | |||
| return llama::mapping::SoA<decltype(arrayDims), Particle, false>{arrayDims}; | |||
There was a problem hiding this comment.
It feels weird that we require the <> for SoA and AoSoA, but not for AoS.
There was a problem hiding this comment.
The story is more complicated. The angle bracket interface is actually the default, AoS<decltype(arrayDims), Particle>{arrayDims} is what you would write normally. Notice that the arrayDims are repeated twice, with is not great. Ideally, we could deduce the type of arrayDims for AoS. This is possible using Constructor Template Argument Deduction (CTAD). However, then we need to be able to deduce all template parameters of AoS. So I added an unused argument for the record dim to AoS, so you can write: AoS{arrayDims, Particle{}};, allowing the template arguments for both array and record dimensions to be deduced. However, that feature immediately fails in case we want to have more complicated constructurs.
The longer discussion is here: #167. Feel free to leave a comment here!
This PR changes the defaults for
AoSandSoAto align better with user expectations:AoS will use alignment and padding by default. This is how native structs in C++ behave.
SoA will use multible blobs by default. This is how SoA is usually implemented. It is sometimes also more efficient.