* Amit Shah (amit.s...@redhat.com) wrote:
> On (Wed) 10 Dec 2014 [11:55:49], ChenLiang wrote:
> > On 2014/12/10 11:18, Amit Shah wrote:
> >
> > > On (Mon) 24 Nov 2014 [19:55:50], arei.gong...@huawei.com wrote:
> > >> From: ChenLiang <chenlian...@huawei.com>
> > >>
> > >> The logic of old code is correct. But Checking byte by byte will
> > >> consume time after an concurrency scene.
> > >>
> > >> Signed-off-by: ChenLiang <chenlian...@huawei.com>
> > >> Signed-off-by: Gonglei <arei.gong...@huawei.com>
> > >> ---
> > >> xbzrle.c | 28 ++++++++++++++++++----------
> > >> 1 file changed, 18 insertions(+), 10 deletions(-)
> > >>
> > >> diff --git a/xbzrle.c b/xbzrle.c
> > >> index d27a140..0477367 100644
> > >> --- a/xbzrle.c
> > >> +++ b/xbzrle.c
> > >> @@ -50,16 +50,24 @@ int xbzrle_encode_buffer(uint8_t *old_buf, uint8_t
> > >> *new_buf, int slen,
> > >>
> > >> /* word at a time for speed */
> > >> if (!res) {
> > >> - while (i < slen &&
> > >> - (*(long *)(old_buf + i)) == (*(long *)(new_buf +
> > >> i))) {
> > >> - i += sizeof(long);
> > >> - zrun_len += sizeof(long);
> > >> - }
> > >> -
> > >> - /* go over the rest */
> > >> - while (i < slen && old_buf[i] == new_buf[i]) {
> > >> - zrun_len++;
> > >> - i++;
> > >> + while (i < slen) {
> > >> + if ((*(long *)(old_buf + i)) == (*(long *)(new_buf +
> > >> i))) {
> > >> + i += sizeof(long);
> > >> + zrun_len += sizeof(long);
> > >> + } else {
> > >> + /* go over the rest */
> > >> + for (j = 0; j < sizeof(long); j++) {
> > >> + if (old_buf[i] == new_buf[i]) {
> > >> + i++;
> > >> + zrun_len++;
> > >
> > > I don't see how this is different from the code it's replacing. The
> > > check and increments are all the same. Difficult to see why there'll
> > > be a speed benefit. Can you please explain? Do you have any
> > > performance numbers for before/after?
> > >
> > > Thanks,
> > >
> > > Amit
> > >
> > > .
> > >
> >
> > Hi Amit:
> >
> > + for (j = 0; j < sizeof(long); j++) {
> > + if (old_buf[i] == new_buf[i]) {
> > + i++;
> > + zrun_len++;
> > + } else {
> > + break;
> > + }
> > + }
> > + if (j != sizeof(long)) {
> > + break;
> > + }
> >
> > The branch of *j != sizeof(long)* may not be hit after an concurrency scene.
> > so we can continue doing "(*(long *)(old_buf + i)) == (*(long *)(new_buf +
> > i))".
> > On the another side the old code does "old_buf[i] == new_buf[i]".
>
> Frankly, I still don't see it.
>
> Earlier:
>
> while..
> match words
> while..
> match bytes
>
> Now:
>
> while..
> match words
> if word mismatch
> match bytes
>
> to me, essentially looks the same.
>
> I'll propose to drop this patch till we have a proper justification.
Watch for the next patch; - patch 5 makes new_buf be the live, volatile memory,
when that happens you could end up falling into the 'match bytes' and getting
a whole word matching again because it had changed while you were processing it,
and that's the change this loop does, it would flip back to processing
whole words at a time again instead of getting stuck in the byte loop.
(It would be rare I guess)
Dave
>
>
> Amit
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
