From: terje.mathisen@nospicedham.tmsw.no   
      
   aen@nospicedham.spamtrap.com wrote:   
   > On Mon, 18 Feb 2019 16:34:57 +0100, Terje Mathisen   
   >  wrote:   
   >>> ... The test was: mov rcx,4294967295 L0: bt  [rbx],rcx dec rcx   
   >>> jnz L0   
   >>>   
   > The cycle count for that was: 33393694911 / 4294967296 = 7,78 cycles   
   >   
   >>> ...   
   >> ... Please try two more tests:   
   >>   
   >> a) Starting at 2 and incrementing until wraparound, i.e. the same   
   >> JNZ L0 as the last instruction. Count the number of primes found   
   >> like this:   
   >>   
   >> xor eax,eax mov ecx,2 L0:  bt  [rbx],rcx adc eax,0 inc rcx jnz L0   
   >> ;; EAX has prime count for verification   
   >>   
   > I did of course inc ecx, but the above gives me: 33699932204 cycles /   
   > 4294967296 = 7,84 cycles, and eax = 203280221   
      
   OK.   
      
   >   
   >> b) Do the same with the compressed 2:1 (odd) table   
   >>   
   >> mov eax,1 ; Counting 2 as a prime mov ecx,1 ; 3 SHR 1 L0:  bt   
   >> [rbx],rcx adc eax,0 inc rcx jns L0	; Stops at 2^31   
   >>   
   > Here I get: 16860994234 cycles / 2147483648 = 7,85 cycles and eax =   
   > 105097566   
      
   You should still divide by 2^32, i.e. you are testing all values but   
   simply skipping half the work, so the average time/number is halved.   
      
   I don't see how you get a different count though! Did you actually   
   recalculate the table with odd values only?   
   >   
   > And I don't quite get what's wrong with 8 cycles compared to how   
   > long a single divide takes!   
   >   
   You never divide when doing constant division, instead you use a   
   reciprocal multiplication.   
      
   Terje   
      
   --   
   -    
   "almost all programming can be viewed as an exercise in caching"   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)