Subject: Re: [boost] Interest in multi-dimensional array class templates.
From: Larry Evans (cppljevans_at_[hidden])
Date: 2011-06-23 15:06:52
On 06/23/11 09:09, Larry Evans wrote:
> On 06/23/11 08:08, Frank Mori Hess wrote:
>> On Wednesday, June 22, 2011, Brian Smith wrote:
>>>> There is also Boost.MultiArray, has the overlap with that library been
>>>> addressed already?
>>> In terms of the way in which the two libraries create and manipulate
>>> storage there's no overlap. Ultimately they serve the same purpose,
>>> however, Boost.MultiArray doesn't provide statically allocated arrays
>> I'm not sure that's true. I've never tried it, but multi_array_ref
>> "provides the MultiArray interface over any contiguous block of elements" so
>> it seems like you could create one of those which uses statically allocated
>>> and generally provides poorer performance.
>> Is that assertion based on actual testing (with NDEBUG defined), or is there
>> some by-design reason your performance would be better?
> IIUC, Brian's templates provide something akin to:
> < typename T
> , std::size_t... Lengths
> struct array
> corresponding to multi_array's:
> < typename T
> , std::size_t NumDims
> struct multi_array
> where T serves the same purpose as multi_array's T and
> sizeof...(Lengths) = multi_array's NumDims and the Lengths,
> instead of being passed to the CTOR, as in multiarray and
> being runtime values, are specified as compile-time constants.
I should have been more explicit about why that *might* result
in a speedup. Because Lengths... are compile time constants,
the strides and the num_elements could be calculated at
compile time. Since num_elements is a compile time constant,
no dynamic allocation would be needed; hence array construction
would be faster IOW, the data could be
a member variable like:
T array<T, Lengths>::data[NumElements];
where NumElements is the compile time constant calculated from
Lengths.... Likewise, there could be a strides_t such as
that shown here:
< typename T
, std::size_t... Lengths
, std::size_t... Strides
Where Strides... is calculated, using mpl::fold or some such.
Thus, since array indexing uses the strides to get at the
indexed T, and since, in this case, the strides are compile-time
constants, I'm guessing that array indexing would be faster.
Does that sound right?