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
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