On Mon, 18 Feb 2019 19:16:04 +0100, Terje Mathisen   
    wrote:   
   >...   
   >>> ... 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   
   >>>   
   I overlooked that line. I used the same 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?   
   >>   
   No, as mentioned above I used the same table, but it should make no   
   difference in the timing.  You're right, that skips half the work.   
      
   >> 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.   
   >   
   I'm still content with 8 cycles, but YMMV.   
   --   
   aen   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)