g++ 4.3, troubles with C++ indexing idioms

[Richard Guenther]

On 7/21/07, tbp <tbptbp@gmail.com> wrote:
> On 7/19/07, Richard Guenther <richard.guenther@gmail.com> 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.