Re: [Gnu-arch-users] hackerlab str_ functions performance

[Yann Droneaud]

Andrew Suffield <address@hidden> writes:

> On Fri, Sep 03, 2004 at 01:00:40PM +0200, Yann Droneaud wrote:
>> Jani Monoses <address@hidden> writes:
>> 
>> > Hello
>> >
>> > hackerlab's str_cmp, str_length and str_cpy are among the top CPU users 
>> > when
>> > running changes and inventory at least, totalling 40% of tla cpu time.
>> >    
>> >        %
>> > 14664    20.3263  str_cmp
>> > 9685     13.4247  str_length
>> > 9178     12.7220  is_simple_anchored_regexp
>> > 5442      7.5434  rx_dfa_advance_to_final
>> > 5265      7.2980  str_cpy
>> >
>> > a similar topic was raised a while ago related to mem_set0.
>> > This crude patch changes them to calling glibc's routines and yields about 
>> > a
>> > 15-20% speedup(not much) 
>> >
>> 
>> compete against inline and assembler optimised functions is quite hard :/
>
> The glibc routines are written in C, although they are
> inlined. They're really quite evil, and beat the crap out of a generic
> assembly routine. They're designed so that the compiler can select an
> appropriate strategy based on its knowledge of the data and the target
> processor.
>

Just checkout :
/usr/include/bits/string.h

There are some assembler function here at least on i386 (for other
architecture i'm not sure). 

For other inlining see:
/usr/include/bits/string2.h

The inlining help to deal with constant string/expression.

-- 
Yann Droneaud (aka Meuh) <address@hidden>
http://meuh.org/ | http://sherkan.tuxfamily.net/~meuh/
Une vache perdue sur Internet | A cow lost in the Internet
1024D/BEA43321   5D91 B5B0 5137 B8FE 6882  FE19 CAA0 6F05 BEA4 3321