memmove broken

[Jörn Engel]

On Sat, 5 July 2003 23:01:15 +1000, Paul Mackerras wrote:
> >
> > Not a limiting factor, but it should be noticable.  What is more
> > important - in my eyes - is that we can replace magic with obvious
> > code.
>
> You are proposing to replace simple, working code with considerably
> more complex code.  You need to be able to point to a specific real
> situation where your change makes a significant difference if you want
> to get it accepted.

Agreed.  And even then, I don't want to submit it before 2.7.

> If the behaviour of the copy loop is non-obvious then the thing to do
> is to add a comment rather than make it more complicated.

This may be highly subjective, but I consider the existing code to be
more complicated.

*q++ = *r++; c--;
*q++ = *r++; c--;

Those two lines are found three times in the current code.  Why?  Loop
unrolling, nothing but an optimization, and not a very good one, if
you look at current cpus.

> The behaviour is defined as long as source and destination don't
> overlap.  You get no guarantees from having source < destination.  It
> could quite legitimately copy backwards in all situations, or work
> exactly the same as memmove.

Also agreed.  It is hard to imagine a sane implementation that doesn't
give these guarantees, but that doesn't mean much.

> Well no, I think it still isn't right.  What if the length is large
> but dst - src == 2 (e.g. if you compress "abababababab") or 3 (e.g. if
> you compress "abcabcabcabcabc")?  Or 4 or 5 or ...?  You will end up
> with an awfully large number of special cases.

That would really make my approach more complicated.  Back to the
drawing board then...

Jörn

--
Fancy algorithms are slow when n is small, and n is usually small.
Fancy algorithms have big constants. Until you know that n is
frequently going to be big, don't get fancy.
-- Rob Pike

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/