From: John C. Femiani (john.femiani_at_[hidden])
Date: 2008-08-08 04:03:14
Andrea Denzler wrote:
>
> Working with indexes is defintively easier and more confortable. And
> probably in many situation the overhead is not worth to be optimized
> at all.
>
> I only was surprised when you said there is a performance gain using
> indexes.
>
>
>
> But I hardly would write something like this (from your array.cpp example)
>
>
>
> for (int i = 0 ; i < h ; ++i)
>
> for (int j = 0 ; j < w ; ++j) {
>
> array[i][j] = uni() ;
>
> }
>
>
>
> You are loosing performance unless the compiler is so intelligent to
> avoid the multiplication at each step. When performance is really an
> issue then I first re-think the algorithm, after I check the produced
> assembler listing to see what the compiler did. In the example above
> at each step you have to calculate this address:
>
> array + i*rowsize + j
>
>
>
> If you are lucky the compiler can produce code that does this in one
> instruction set, if not you will get an overhead. Again if h and w are
> low values you will not notice it.
>
>
>
> This example is of course much faster, and yes, it is not elegant nor
> clear.
>
> int *p=array*,**pend=&array[h][w];
>
> while (p < pend)
>
> *p++ = uni() ;
>
The standard algorithms use iterators; An array implementation that
translates iterators to indexes and expects the indexes to be converted
back into pointers is questionable to me. Especially when my trivial
test code showed the multi-array implementation was 10-20 times slower.
This slow down is way more than I expected.
The multi_array implementation is extremely scary to me because it does
not seem to be low overhead at all.
-- John