Boost logo

Boost :

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
>> storage.
>>> 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:
> template
> < typename T
> , std::size_t... Lengths
> >
> struct array
> ;
> corresponding to multi_array's:
> template
> < 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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at