Re: Thinking about release

[Andre Renaud <andre@bluewatersys.com>]

Hi Rich,
> I think the first step should be benchmarking on real machines.
> Somebody tried the asm that was posted and claimed it was no faster
> than musl's C code; I don't know the specific hardware they were using
> and I don't even recall right off who made the claim or where it was
> reported, but I think before we start writing or importing code we
> need to have a good idea how the current C code compares in
> performance to other "optimized" implementations.

In the interests of furthering this discussion (and because I'd like
to start using musl as the basis for some of our projects, but the
current speed degradation is noticeable , I've created some patches
that enable memcmp, memcpy & memmove ARM optimisations. I've ignored
the str* functions, as these are generally not used on the same bulk
data as the mem* functions, and as such the performance issue is less
noticeable.

Using a fairly rudimentary test application, I've benchmarked it as
having the following speed improvements (this is all on an actual ARM
board - 400MHz arm926ejs):
memcpy: 160%
memmove: 162%
memcmp: 272%
These numbers bring musl in line with glibc (at least on ARMv5).
memcmp in particular seems to be faster (90MB/s vs 75MB/s on my
platform).
I haven't looked at using the __hwcap feature at this stage to swap
between these implementation and neon optimised versions. I assume
this can come later.

From a code size point of view (this is all with -O3), memcpy goes
from 1996 to 1680 bytes, memmove goes from 2592 to 2088 bytes, and
memcmp goes from 1040 to 1452, for a total increase of 224 bytes.

The code is from NetBSD and Android (essentially unmodified), and it
is all BSD 2-clause licensed.

The git tree is available here:
https://github.com/AndreRenaud/musl/commit/713023e7320cf45b116d1c29b6155ece28904e69

Does anyone have any comments on the suitability of this code, or what
kind of more rigorous testing could be applied?

Regards,
Andre