[Zlib-devel] [PING] Improve longest_match performance

John Reiser jreiser at bitwagon.com
Tue Jul 24 19:54:29 EDT 2012


On 07/24/2012 03:37 PM, Jan Seiffert wrote:
> John Reiser schrieb:
>> On 07/24/2012, Andreas Krebbel wrote:
>>
>>> any comments regarding this one?
>>>
>>> http://mail.madler.net/pipermail/zlib-devel_madler.net/2012-June/002907.html
>>
>> These changes in the width of variables which contribute to indexing
>> of arrays:
>> -----
>> +    uLong cur_match = pcur_match; /* extend to pointer width */
>>
>> +    uLong wmask = s->w_mask;
>> -----
>> should use 'ptrdiff_t' instead.  It ought to take only a minor increase
>> in intelligence for the compiler to do such a widening automatically,
>> because all uses are associated with array indexing, and a machine with
>> 64-bit addresses often charges a high price for indexing by a 32-bit quantity.
>>
> 
> But it can also be the other way round, that was the reason for his regression
> on Core2.
> And he wants an unsigned type (there is no negative indexing going on), because
> the sign extension is killing s/390. ptrdiff_t is a signed type.

Using ptrdiff_t for cur_match and wmask does work [assuming no compiler errors.]
The only appearances of 'wmask' are:
    uInt wmask = s->w_mask;
    } while ((cur_match = prev[cur_match & wmask]) > limit)

We know that pcur_match < 32K because index 32768 is outside the window.
Also 0 <= .w_mask <= 0x7FFF.  Therefore _both_ operands of the AND have
bit 15 [and above] clear, so the result of the AND is non-negative at
any width >=16, regardless of signed or unsigned.

> as already mentioned in and ff:
> http://mail.madler.net/pipermail/zlib-devel_madler.net/2012-July/002931.html

Please give a specific citation and quote a line or two.  I checked 002931.html,
and also 002933 through 002937.  I could find no discussion of signed vs. unsigned.
The only appearance of "signed" is in 002931:
-----
  and use that. But i see that the glibc <stdint.h> defines uint_fast32_t to
  unsigned long on 64Bit x86, so it would be no win. Maybe
-----
which discusses width only (not signedness), and 002934:
-----
  Because i wasn't sure. zlib is designed and written to cater to old/small
-----
which is not relevant; and text copied from those two posts.

-- 





More information about the Zlib-devel mailing list