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

tbp tbptbp@gmail.com
Sat Jul 21 13:33:00 GMT 2007


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sf.cc
Type: text/x-c++src
Size: 8393 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20070721/170fdc72/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile
Type: application/octet-stream
Size: 560 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20070721/170fdc72/attachment.obj>


More information about the Gcc mailing list