lkml.org 
[lkml]   [1998]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: faster strcpy()
On Sun, 26 Apr 1998, Richard B. Johnson wrote:

> The 'C' library is glibc-2.0.5. Case closed.

Just to be devil's advocate:

You're using a dual cpu box, which are notoriously bad at confusing timing
trials like this due to context switches crossing CPUs -- you need to run
for a long enough period to smooth these out.

Your trial is for 1s each, which isn't statistically relevant, given that
the timer has 1s accuracy.

You're using string lengths that are vastly larger than what is commonly
found. (No I can't cite a reference for this -- but you should be able to
prove it to yourself easily by instrumenting libc strlen and strcpy.)

You're using a single buffer, which has vastly different L1
characteristics than multiple buffers; and different characteristics from
what real-world apps would see because they have other things polluting
the L1. I bring up this point mostly because the strlen/memcpy version is
probably better on the pentium because of the L1 cache design, this is
less likely to be an issue on the pentium pro.

A much better benchmark would be to run some real world applications which
use strcpy()... of course it's somewhat moot because strcpy()s are being
replaced with strncpy() to be safe. And strncpy() is a waste in general
because it requires the dest to be \0 filled to its length. But I do
notice that strcpy() seems to be used a fair amount in the spec95 integer
benchmarks, so maybe they'd be good enough to show a difference between
the approaches.

Dean


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.147 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site