Messages in this thread | | | Date | Mon, 27 Apr 1998 02:13:36 -0700 (PDT) | From | Dean Gaudet <> | Subject | Re: faster strcpy() |
| |
On Sun, 26 Apr 1998, Richard B. Johnson wrote:
> On Sun, 26 Apr 1998, Dean Gaudet wrote:
> > 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.
Like I said, I can't cite a reference, but I'm sure if you instrument your libraries you'll discover that 90% of all strings are less than 64 bytes in length. i.e. your benchmark bears no resemblence to real usage. I've done the instrumentation before, when I worked at a compiler company and tuned string implementations, which is why I'm mumbling about it.
> > 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.
Sure, on a non-mmx pentium you're close to filling the L1; but on anything more recent you won't fill the L1. Regardless, the important thing is to cause enough L1 churn to behave like a real system does with real applications.
But I've sort of lost track of what two implementations you were comparing :)
Dean
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |