Subject: Re: [boost] interest in structure of arrays container?
From: Larry Evans (cppljevans_at_[hidden])
Date: 2016-10-19 08:32:22
On 10/19/2016 01:26 AM, Larry Evans wrote:
> 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<T1,T2,...,TN>?
>>> 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.
> 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
Code has been updated to implement most of the "essentials" of
soa_block. You can now call begin<Index> to get the begin
iterator for the Index'th vector.
The code now is on github at:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk