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, Dean Gaudet wrote:

> 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.
You can run it as long as you want.

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

The timer has the resolution of the context-switch rate +/- a few of
these ticks. The accuracy is the accuracy of your bus-clock from which
the timer channel 0 gets its signal.

>
> 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.)
>

The string-length is reduced by 64 at each run through the loop.

> 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.
>
I am using two buffers, one a source and another a destination. They
are deliberately the same buffers for both tests. There is no way that
the execution of one string function could affect the other since
the strings are way too long to fit in a cache.

You can swap the placement of the functions and show that.


> 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
>

Cheers,
Dick Johnson
***** FILE SYSTEM MODIFIED *****
Penguin : Linux version 2.1.92 on an i586 machine (66.15 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.

-
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    [from the cache]
©2003-2011 Jasper Spaans