[lkml]   [1998]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

     \ /
      Last update: 2005-03-22 13:42    [W:0.018 / U:14.268 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site