Messages in this thread | | | Date | Sun, 26 Apr 1998 18:39:28 -0700 (PDT) | From | Dean Gaudet <> | Subject | Re: 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
| |