Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 28 Jul 2013 04:09:47 -0400
From: Rich Felker <>
Subject: Re: Thinking about release

On Wed, Jul 24, 2013 at 04:40:16PM +1200, Andre Renaud wrote:
> > I think the C version would be acceptable if we get the bugs fixed and
> > test it well, but I'd also like to still keep the asm under
> > consideration. There are lots of cases not covered by the C version,
> > like misaligned copies (important for strings, not for much else). Do
> > you think these cases are important?
> At the moment the mis-aligned copies perform terribly (18MB/s vs glibc
> @ 100MB/s). However the existing C implementation in musl is no
> different, so we're not degrading the current system.
> We're essentially missing the non-congruent copying stuff from the asm
> code. I'll have a look at this and see if I can write a similar C
> version.

Sorry this hasn't been moving forward more quickly. I've been
experimenting with various memcpys on ARM, and I've found:

1. Pure C code that performs comparably (only in the aligned case, so
   far) to the bionic asm and your inline-asm C version.

2. The prefetch stuff in your inline asm and the bionic version is
   apparently making it slower. With that removed from your C
   (basically, my inline asm version) it's 10% faster on the machine
   I'm running it on.

So I feel like we still have a ways to go figuring out the right
solution. I know, from one standpoint, it would be nice to have
_something_ right now, but I don't want to commit one version only to
decide next week it's wrong and throw it all out. Hopefully in the
mean time people who are trying to use musl seriously on arm and
running into performance problems can drop in the bionic asm or
another implementation.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.