Messages in this thread | | | Date | Mon, 27 Apr 1998 00:11:37 -0400 (EDT) | From | "Richard B. Johnson" <> | Subject | Re: faster strcpy() |
| |
On Sun, 26 Apr 1998, David S. Miller wrote:
> Date: Sun, 26 Apr 1998 23:45:49 -0400 (EDT) > From: "Richard B. Johnson" <root@chaos.analogic.com> > > It would be interesting to determine if it's due to a cache that > isn't a cache at all. On three machines here, all pentiums, strange > is slower. > > I don't know if it has been mentioned in this thread yet, but there > are issues on the Pentiums concerning no-allocate-on-write L1 caches. > > Later, > David S. Miller > davem@dm.cobaltmicro.com > Yes. It is true. However, the strcpy() in the glibc runtime library __is__ a "strlen()" immediately followed by a memcpy(), copying longwords first, then trailing bytes. If we have machines out there that function faster with a CALL to strlen(), followed by another CALL to memcpy(), this seems to point out a cache stall, not some underlying defect in the runtime library.
One could verify this by turning off their caches (if possible), and then checking the results. If the result reverses their observations, then they know what benchmark to try the next time they upgrade their motherboards!
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
| |