Messages in this thread | | | Date | Mon, 27 Apr 1998 01:12:08 -0400 (EDT) | From | "Richard B. Johnson" <> | Subject | Re: faster strcpy() |
| |
On Mon, 27 Apr 1998, Michael O'Reilly wrote:
> > Weird. What exactly are you trying to say? The original point was > that a byte-by-byte strcpy() was slower than a strlen() followed by a > word-by-word memcpy().
No. The original conjecture was that defining a macro for strcpy() that used strlen + memcpy() was faster than the regular strcpy().
The benchmark shows these two implementations. That's all. Somebody else, who apparently had no idea about what was being discussed, offered some 'C' code with '*dst++ = *src++' stuff which, hopefully, would never be encorporated into a 'C' runtime library. Don't worry, it isn't.
The current implementation uses some assembly to obtain the length, immediately followed by a long-word copy with any extra bytes at the end. It is basically a strlen() followed by a memcpy().
Some have observed that if this is broken up into seperate calls to strlen() and memcpy(), as the benchmark does in one test, the machine runs faster.
This is not true for any of my Pentiums, however, I find that it is true on my '486/66 at home. If I disable the cache, the problem goes away (although the performance is absymal). This seems to show that there is a problem with caching on some machines, including one of mine.
It is possible that this could be 'fixed', not by defining a macro, but adding a single instruction, that does nothing harmful, to the runtime library code. For instance, one might copy a register to itself or insert a nop. I will experiment, not that I have found a 'broken' machine.
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
| |