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