This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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: __USE_STRING_INLINES not available with g++ compiler ?


On Thu, 15 Sep 2005, Helge Deller murmured woefully:
> I did some optimization testings with our source code and run across
> the __USE_STRING_INLINES define.
> In /usr/include/string.h the other headers with the inline assembler
> code <bits/string.h>, <bits/string2.h> and <bits/string3.h> (on i386)
> are not included if the g++ compiler is used (it's surrounded by #if
> !defined __cplusplus...).
> 
> My main question is: Is there any good reason why the g++ compiler is
> generally excluded from this type of assembler inlining optimization ?

Because making the ISO C string functions into macros breaks the
libstdc++ C forwarding headers, notably <cstring>. All three responsible
parties (string.h, c++/*/bits/*/os_defines.h, and <cstring>) go to some
lengths to disable these optimizations for exaactly that reason.

> FYI, I did some testing with a hand-modified gcc/g++-compilable
> version of <bits/string.h> on i686 (with the old gcc2.95
> compiler). Everything compiled and worked well, and I gained around
> 3%-4% speed improvement in an internal SAP SD-Benchmark
> (http://www.sap.com/benchmark/) run.

GCC 2.95 did not optimize many (any?) string operations. More recent
versions of GCC expand increasingly many string operations inline, and
unlike glibc's rather nasty macros it can do scheduling and other
optimizations on these expansions. (glibc's macros are better than
nothing, but the job is better done in GCC, and as GCC gains the ability
to optimize more string operations, more and more of the string inlines
in glibc are restricted to apply to older compilers only.)

Also, GCC 2.95 can't schedule for the i686 properly, so stalls due to
bad scheduling decisions and incorrect alignment are probably dominating
your benchmark (especially if the strings aren't large: and if they are
large, I/O of the strings to and from memory will dominate your timings
no matter which string-function implementation you use).

> So, if there are no objections against using this optimization with
> g++ as well, would the glibc team accept a patch ?

You'd need to talk to the GCC team too: libstdc++ is not part of glibc.
But unless you can come up with a radically new way to implement the
C forwarding headers, I'm betting the answer will be `no'.

-- 
`One cannot, after all, be expected to read every single word
 of a book whose author one wishes to insult.' --- Richard Dawkins


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