Subject: Re: [boost] Interest in multi-dimensional array class templates.
From: Brian Smith (bjs3141_at_[hidden])
Date: 2011-06-23 17:30:07
On 6/23/11, Larry Evans <cppljevans_at_[hidden]> wrote:
> 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"
>>> it seems like you could create one of those which uses statically
>>>> and generally provides poorer performance.
>>> Is that assertion based on actual testing (with NDEBUG defined), or is
>>> 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
> struct array
> < std::size_t
> , 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?
>From the above definition of the array, namely,
< typename T
, std::size_t... Lengths
the generated member type, data say, in the static case, is
T[Lengths1][Lengths2]...[LengthsN], where N is the number of Lengths
supplied. The indexing operator accepting a single std::size_t type, s
say, for data element access returns an internally defined type, i.e.,
a T[Lengths2]...[LengthsN], via data[s], and simply relies on compiler
generated code on any remaining indexes.
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk