rawmemchr
Eric Blake
ebb9@byu.net
Thu May 22 12:50:00 GMT 2008
Eric Blake <ebb9 <at> byu.net> writes:
> Here's my test program:
>
> int *ptr = (int *) str;
> while (!DETECTNULL (*ptr) && !DETECTCHAR (*ptr, mask))
> ptr++;
> /* Found the end of string or word containing c. */
> str = (const char *) str;
FYI. That was supposed to be
str = (const char *) ptr;
That one-character flaw in my test app C code resulted in searching the string
twice (once fast and discarding the progress, then again bytewise). With the
test app fixed, I get these even more impressive numbers to demonstrate the
benefits of my optimization:
> $ time ./foo 1000000 1 0 1000 2 1
>
> real 0m1.594s
> user 0m1.608s
> sys 0m0.015s
>
> # C is 3x slower than the current assembly on aligned ptr
>
> $ time ./foo 1000000 1 0 1000 0 1
>
> real 0m0.922s
> user 0m0.921s
> sys 0m0.030s
>
> # But my special casing of strchr(ptr,0) shows > 40% improvement!
$ time ./foo 1000000 1 0 1000 2 1
real 0m0.656s
user 0m0.671s
sys 0m0.015s
Only 17% worse, not 3x worse, than the pre-patched assembly version on aligned
searches.
$ time ./foo 1000000 1 0 1000 0 1
real 0m0.312s
user 0m0.327s
sys 0m0.015s
Better than pre-patch assembly on searching for 0, comparable to patched
assembly.
>
> $ time ./foo 1000000 1 1 1000 2 1
>
> real 0m1.594s
> user 0m1.608s
> sys 0m0.015s
>
> $ time ./foo 1000000 1 1 1000 0 1
>
> real 0m0.921s
> user 0m0.936s
> sys 0m0.015s
>
> # the C code does not slow down for unaligned str
> # And my C code for strchr(unaligned,0) BEATS the current assembly!
>
$ time ./foo 1000000 1 1 1000 2 1
real 0m0.656s
user 0m0.671s
sys 0m0.015s
# Better than pre-patched assembly on unaligned data, and only 17% slower than
patched assembly
$ time ./foo 1000000 1 3 1000 0 1
real 0m0.328s
user 0m0.343s
sys 0m0.000s
# Better than even pre-patched assembly on aligned data, and comparable to
patched assembly
You have to admit it's pretty cool that the buggy version of the test app doing
twice the necessary work on strchr(unaligned,0) was outperforming the pre-patch
assembly.
--
Eric Blake
More information about the Newlib
mailing list