On 7/21/07, tbp <[EMAIL PROTECTED]> wrote:
On 7/19/07, Richard Guenther <[EMAIL PROTECTED]> wrote: > Of course, if any then the array indexing variant is fixed. It would be nice > to see a complete testcase with a pessimization, maybe you can file > a bugreport about this? There's many issues for all alternatives and i'm not qualified to pinpoint them further. I've taken http://ompf.org/ray/sphereflake/ which is used as a benchmark already here http://www.suse.de/~gcctest/c++bench/raytracer/, because it's small, self contained and has such a basic 3 component class that's used all over. It doesn't use any kind of array access operator, but it's good enough to show the price one has to pay before even thinking of providing some. It has been adjusted to use floats and access members through accessors (to allow for a straighter comparison of all cases).variation 0 is the reference, a mere struct { float x,y,z; ...};, performs as good as the original, but wouldn't allow for any 'valid' indexing. variation 1 is struct { float f[3]; ... } variations 2,3,4,5 try to use some union # /usr/local/gcc-4.3-20070720/bin/g++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/usr/local/gcc-4.3-20070720 --enable-languages=c,c++ --enable-threads=posix --disable-checking --disable-nls --disable-shared --disable-win32-registry --with-system-zlib --disable-multilib --verbose --with-gcc=gcc-4.2 --with-gnu-ld --with-gnu-as --enable-checking=none --disable-bootstrap Thread model: posix gcc version 4.3.0 20070720 (experimental) # make bench [snip] sf.v0 real 0m3.963s user 0m3.812s sys 0m0.152s sf.v1 real 0m3.972s user 0m3.864s sys 0m0.104s sf.v2 real 0m10.384s user 0m10.261s sys 0m0.120s sf.v3 real 0m10.390s user 0m10.289s sys 0m0.104s sf.v4 real 0m10.388s user 0m10.265s sys 0m0.124s sf.v5 real 0m10.399s user 0m10.281s sys 0m0.116s There's some inlining difference between union variations and the first two, but they clearly stand in their own league anyway. So we can only seriously consider the first two. Variation #0 would ask for invalid c++ (pointer arithmetic abuse, not an option anymore) or forbidding array access operator and going to set/get + memcpy, but pretty optimal. Variation #1 (straight array) is quite annoying in C++ (no initializer list, need to reformulate all access etc...) and already show some slight pessimization, but it's not easy to track. Apparently g++ got a bit better lately in this regard, or it's only blatant on larger data or more complex cases. I hope this shows how problematic it is for the end user.
For performance small arrays should be the same as individual members (I can see the annoying fact that initialization is a headache - this has annoyed me as well). For larger arrays (>4 members), aliasing will make a difference possibly, making the array variant slower. Any union variant is expected to be slower for aliasing reasons (we do not do field-sensitive aliasing for unions). In the end I would still recommend to go with array variants. Richard.
