[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