Re: [boost] interest in structure of arrays container?

On 10/18/2016 10:24 PM, Michael Marcin wrote:

On 10/18/2016 10:55 AM, Andreas Schäfer wrote:

...

On 10:29 Tue 18 Oct , Larry Evans wrote:

...

The purpose of item:

* sizeof...(Ts) allocations could be a single large block

is to just require 1 heap allocation instead of N, where N is the number of vectors in soa?

One benefit of this would be that transferring such a container to another address space (think MPI or CUDA) would become much simple.

It also reduces the size of your handle structure (the structure the holds the pointer to the data). Otherwise every additionally member adds ~24 bytes for a simple tuple< vector<Ts>... > or sizeof(T*) bytes at a minimum for separately allocated blocks.

It also can reduce the size of an iterator to a view of the data or remove an indirection from it depending on implementation.

It has a nice benefit that the size of the handle + body (alloc'd data block) for a soa_vector would be identical to that of a normal AoS vector containing the same data.

If a solution ticked all the other boxes and dropped this one, I'd be fine with that. There's quite a bit of complexity involved with calculating the offsets with a dynamic capacity and potentially arbitrary alignment requirements on internal subarrays.

[snip] Michael, the attached is an outline of how to do it. As noted in the comments, a lot of member functions still need implementation; however, the offset calculations I think are correct. HTH. -regards, Larry