Re: generic strncpy - off-by-one error

[Timothy Miller]

Peter Kjellerstedt wrote:

> For loops       2.867568    5.620561    8.128734   28.286289  
> Multi byte fill 2.868031    5.670782    6.312027   11.336015  
>
> And here are the numbers for my P4:
>
> For loops       3.060262    5.927378    8.796814   30.659818  
> Multi byte fill 3.126607    5.898459    7.096685   13.135379  
>
> So there is no doubt that the multi byte version is a clear
> winner (which was expected, I suppose).

Cool!  Hey, is this just an exercise, or are we actually going to use 
this?  I would be very happy to have something I contributed to put into 
the kernel.  :)

> Here is the code that I used:
>
> char *strncpy(char *dest, const char *src, size_t count)
> {
> 	char *tmp = dest;
>
> 	while (count && *src) {
> 		*tmp++ = *src++;
> 		count--;
> 	}
>
> 	if (count) {

Good idea... bad to do so many checks if count is zero.  On the other 
hand, if count is rarely zero, then it's a loss.  Maybe benchmark with 
and without?

> 		size_t count2;
>
> 		while (count & (sizeof(long) - 1)) {
> 			*tmp++ = '\0';
> 			count--;
> 		}
>
> 		count2 = count / sizeof(long);

I know that a good compiler should migrate code to help the CPU 
pipeline, but how about moving this "count2 = " line up to before the 
first fill loop.  See if that helps any.  Always good to precompute well 
in advance.

> 		while (count2) {
> 			*((long *)tmp)++ = '\0';
> 			count2--;
> 		}
>
> 		count &= (sizeof(long) - 1);

And move this to before the middle fill loop.

> 		while (count) {
> 			*tmp++ = '\0';
> 			count--;
> 		}
> 	}
>
> 	return dest;
> }
>
> //Peter


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/