[uClibc] uclibc for the desktop
Peter Kjellerstedt
peter.kjellerstedt at axis.com
Wed Nov 5 07:44:58 UTC 2003
> -----Original Message-----
> From: uclibc-bounces at uclibc.org
> [mailto:uclibc-bounces at uclibc.org] On Behalf Of Manuel Novoa III
> Sent: Tuesday, November 04, 2003 19:29
> To: Rob Landley
> Cc: uclibc at uclibc.org
> Subject: Re: [uClibc] uclibc for the desktop
[snip]
> Also some wishlist items...
>
> Provide optimized str/mem funcs as a config option.
Does it really need to be a configuration option?
Shouldn't it just be done per architecture? Why use a
slow, generic function if there is a fast architecture
specific version?
On a related note, I actually did some quite extensive
tests with strncpy() earlier this year regarding the
implementation in the kernel. That thread can be found here:
http://marc.theaimsgroup.com/?t=106069767900001&r=1&w=2
To cut to the chase, the final results can be found here:
http://marc.theaimsgroup.com/?l=linux-kernel&m=106106872330688&w=2
(The benchmark table shows the times for copying a 100
byte string into a 1000 byte buffer. For each function
I tested with copying 50, 100, 200 and 1000 bytes.)
As can be seen the strncpy() in uClibc is ok when copying,
but blows chunks when filling...
This was as far as I could take a generic function.
After that the optimizations and tunings would become
architecture (and probably even processor) specific
(in which case we are in a totally different ball park).
> Manuel
//Peter
More information about the uClibc
mailing list