This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v3] faster strlen on x64
On Wed, Feb 06, 2013 at 01:05:09PM -0500, Carlos O'Donell wrote:
> On 02/06/2013 12:19 PM, OndÅej BÃlka wrote:
> > On Wed, Feb 06, 2013 at 11:18:06AM -0500, Carlos O'Donell wrote:
> >> On 02/05/2013 06:44 PM, OndÅej BÃlka wrote:
> >>> My implementation takes profiling information (see http://kam.mff.cuni.cz/~ondra/benchmark_string/profile/result.html for my workload.)
> >>> into account. Important property there is that most strings are at most
> >>> 80 bytes large.
> >>
> >> I think this information is really important.
> >>
> >> How did you profile this?
> >>
> > I use two tools that do profiling. I generated these statistics with
> > https://github.com/neleai/benchmark_string directory profile.
> > It is in hacky state with several problems, it has relatively big
> > constant overhead when writing results. I do not use it to collect
> > timing information. Also malloc profiling is not entirely stable.
>
> Have you considered using systemtap static probes for some of this
> work?
>
Yes, but as I try to use it as single tool for all profiling it does not
fit all use cases that I plan.
> The goal would be to capture string length usage across all of the
> applications in a system and then ensure that our string functions
> worked well across average work loads.
Strlen is easy case where length can be read from output. Systemtap
cannot easily find it for strcmp or strchr that returnd NULL and most
other functions. (except with inline assembly hack)
My solution is writ simple reimplementation which is easy but lot of c
code which would mean embedded c with systemtap.
Next is that systemtap does not allow arbitrary user to profile his
binaries yet.
To measure performance of implementations I need to supply them.
As they are assembly files simplest way looked to use LD_PRELOAD / /etc/ld.so.preload
(dlopen has problem that we need to handle dlopen>strlen>dlopen
recursion.)
And if I already do LD_PRELOAD/ /etc/ld.so.preload then additional
systemtap looked unnecessary.