Re: [Boost-users] R: R: [multi-array] Performance? Difference from GIL or uBLAS?

From: John C. Femiani (john.femiani_at_[hidden])
Date: 2008-08-09 09:55:33

Andrea Denzler wrote:
> Yes, iterators if available make our code clean and elegant and without
> overhead. We use iterators even on STL::vector. They are great.
>
> The minimum overhead you have with indexes is to calculate the address 
>    (char *)array + i*sizeof(row) + j*sizeof(item)
> And to double the increment and loop check since you have two variables
>    ++i, i<h   +    ++j, j<w
>
> But if the underlying structure is not a plain array but a class you may
> have also boundary checks on the indexes. All this together can cost several
> CPU cycles. 
>   
I used BOOST_DISABLE_ASSERTS, that was supposed to remove boundary checks.
> Also with a iterator/pointer you may use only a register (not a memory
> location) improving even more the speed.
>   
But does that happen when the iterator is implemented in using a base* 
and and index, along with 3 or four other pointers to stride arrays and 
extents?
> It depends on the cost of the inner code, if it is just a simple arithmetic
> calculation (1 cpu cycle) then I expect something like 10 times slower.
>   
Admittedly, the inner op is trivial, but so are MANY operations you 
would perform on an array. I.e. adding, multiplying, forming linear 
combinations, etc.

> All the GIL examples I saw use iterators and what I liked is that
> complicated image calculations can be stacked. If I have to flip the an
> image and convert it to B/W then traditionally I would do that in two steps,
> with Gil you do that in one step only, with nearly double performance.
>   
Are there performance measurements for GIL?

GIL uses Locators, which I love.  GIL seems to be stuck on arrays that 
are an 'image' of 'pixels', which is not always the case for me.  
Ideally I would be able to construct an array of any type.

I was looking into multi_array hoping there would be some analogy to GIL 
/ Locators, but multi_array seems to be mimicking aspects of the syntax 
used in Fortran, Matlab, or Python.  That's great from a high level 
point of view, but I am a bit afraid because I don't understand the 
performance implications.

I think that in the spirit of 'zero overhead', there should be some 
boost requirement that certain libraries include performance 
measurements / graphs as part of their docs or build process.  For 
things like multi_array or uBLAS or GIL,  I think efficiency is 
important (not just asymptotic). 

For example, I would feel more comfortable if I could see something 
like: http://www.oonumerics.org/blitz/benchmarks/

(The only reason I don't wanna use BLITZ is that the last release was 2005)

--John