Re: Q: Fast computation of parity

From: Mok-Kong Shen (mok-kong.shen_at_t-online.de)
Date: 12/31/03 

Date: Wed, 31 Dec 2003 20:30:52 +0100

"Michael J. Fromberger" wrote:
>
[snip]
> # On G4:
> % ./pars
> Lookup: 2
> XOR: 1
>
> # On PIII:
> % ./pars
> Lookup: 450000
> XOR: 460000

This once again shows that the relative efficiency of
algorithms/codes could be fairly hardware dependent.
(A similar phenomenon was noted in AES benchmarking
in a thread not long ago. In particular, cycle counts
could be very misleading under circumstances.)

M. K. Shen

Relevant Pages

  • Re: Algorithm to compare two binary numbers
    ... which processors might have such an instruction) and the compiler is ... > 10,000,000 XOR operations, and need to count the bits of every XOR result, ... > either by lookup table or by a real-time counting function. ... and ended with a CPU time of between 0.8 and 2 seconds for all of it ...
    (comp.programming)
  • Re: Q: Fast computation of parity
    ... So I'd think the lookup would be faster... ... x86 doesn't have enough general-purpose registers, so I suspect the XOR ... into] takes longer than one such sequence plus an access to the cache. ...
    (sci.crypt)
  • Re: Q: Fast computation of parity
    ... > Xor: 11888907 ... Lookup: 50 ... This is consistent with my expectations for a register-rich RISC ...
    (sci.crypt)
  • Re: Q: Fast computation of parity
    ... I had to increase the number of tests again to get the resolution ... > Lookup: 2 ... > XOR: 1 ... Tom ...
    (sci.crypt)