Subject: Re: [boost] RFC: runtime-flexible arrays
From: Larry Evans (cppljevans_at_[hidden])
Date: 2012-02-16 12:40:46
On 02/16/12 10:20, Joel Falcou wrote:
> Le 16/02/2012 15:21, Mathias Gaunard a écrit :
>> But mixing operations between different storage orders just causes
>> massive amount of problems if you want to vectorize and use the cache
>> efficiently, so we don't support it.
> We dont support it exactly for that. One possible solution was to use
> the majority storage order but it leads to poor performance. I didn't
> find any use case where such mix was required.
Well, there's the case for rotated axes, as requested by:
However, I've not done any performance measures (mostly because
I'm not sure how to do meaningful measurements). What benchmarks are
you using to measure the performance?
One problem I see with the array_dyn rotated axes is that the rotation
is not done on the array itself but on the indices to the array.
Thus, only the offsets are calculated. The offset then needs to be
used as an index to the underlying storage (which is something like
multi_array's data member function). Actually, the calculation is
more like an iterator, but an offset iterator, not an iterator into
the array. I fear that that probably takes too long relative to
The output from the example:
illustrates how the stack of indices change with the iteration.
It has been used to do a matrix product as well as a tridiag solution:
That tridiag method was then used to solve pde's here:
Although it is probably slower if the array us unrotated; if
rotation is needed, as in array_dyn.diff_pde.cpp, then it may
be faster since, using something like nt2 or multi_array would,
AFAICT, require copying the array to a new storage order.
Petros (see the match=multi=array+pdes above) has somehow
solved the problem; however I don't know how. Petros?
OTOH, maybe you have some ideas of how the rotated axes problem
can be solved with nt2 and used to solve the pde examples in
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk