This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]