Re: __USE_STRING_INLINES not available with g++ compiler ?

[Helge Deller <helge dot deller at sap dot com>]

Hello Nix,

thanks for the good explanation !

Since I don't have any "radically new way to implement the C forwarding headers", I'll better leave it as it is.
My tests with -minline-all-stringops and -mno-align-stringops and gcc 3.x seems to do the job mostly well.

Thanks,
Helge

On Friday 16 September 2005 11:20, Nix wrote:
> 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'.
>