joern at wohnheim.fh-wedel.de
Sun Jul 6 03:01:45 EST 2003
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
*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...
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/
More information about the Linuxppc-dev