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

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.125 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site