Re: memmove broken

On Sat, 5 July 2003 23:01:15 +1000, Paul Mackerras wrote:

quoted

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/