ASM Community

You are wrong,
to produce the same value data just need to be aligned by mb.
Look at last post you'll see results from file 1 mb.
And values are the same.

eax = Nico      : code:C9AD7C71, 321 ms for 10 loops on 2MB of data

eax = BitRAKE   : code:C0B67C80, 701 ms for 10 loops on 2MB of data

eax = Thomas2   : code:C9AD7C71, 300 ms for 10 loops on 2MB of data

eax = Thomas3   : code:C9AD7C71, 200 ms for 10 loops on 2MB of data

eax = Svin2     : code:C9AD7C71, 190 ms for 10 loops on 2MB of data

:)

something like this:

_b2:

    next:

        mov     al, [esi]

        _proceed:

        add     ecx, eax

        add     edx, ecx

        jo      _of_edx

        inc     esi

        dec     edi

    jnz     next

    jmp     _done



_of_edx:

sub edx, ecx

sub ecx, eax

<<<mod edx and ecx >>>

jmp _proceed

This requires an extra jcc and when unrolled 4 extra jumps so it's probably slower, but maybe we can get something out of it..

Thomas

Thomas, you'll have less dependancies on your inner loop if you stagger the calculations like I do above - it will work on your unrolled version, too.

---------------------------------------------------------------------

eax = Thomas2   : code:3980E24D, 1602 ms for 100 loops on 2MB of data

eax = Thomas3   : code:3980E24D, 791 ms for 100 loops on 2MB of data

eax = Nico      : code:3980E24D, 1452 ms for 100 loops on 2MB of data

eax = BitRAKE   : code:3980E24D, 1733 ms for 100 loops on 2MB of data

eax = BitRAKE2  : code:3980E24D, 771 ms for 100 loops on 2MB of data



sub		edx, ecx ;**bitRAKE2

next:

	movzx	eax, BYTE PTR [esi+0]

	add		edx, ecx

	add		ecx, eax

	

	movzx	eax, BYTE PTR [esi+1]

	add		edx, ecx

	add		ecx, eax

	

	movzx	eax, BYTE PTR [esi+2]

	add		edx, ecx

	add		ecx, eax



	movzx	eax, BYTE PTR [esi+3]

	add		esi, 4

	add		edx, ecx

	add		ecx, eax

	dec		edi

jnz		next

add		edx, ecx ;**bitRAKE2

Replace the code in Thomas3 with the code above. Not a big improvement on Athlons, but maybe more on other processors?

Sure,
It's practically your code, for me was more important just prove that my "mul\div" method is reliable.
Only xor eax,eax was needed after devision (that simple :)
It doesn't increase speed though, cause the code is rarely taken
and with mul insead of div it is longer (in size) it's offten out of code chache so effect in opposite may be negative.
With multiple tests it was clear that Thomas3 and Svin2 were compiting in speed and you can not be sure wich one was faster
(code cache affectation).
I had a little look at the rest of Thomas3 and found that code may be reorganaized to remove some dependences, this gave effect for sure.
Anyway I would call it Thomas3andSvin :) 'Cause my part was
just a little and auxilary.

Svin2 proc  uses edi esi ebx  adler:DWORD, buf:DWORD, len:DWORD



    mov     ecx, adler

    mov     esi, buf

    mov     edx, ecx

    and     ecx, 0ffffh     ; ecx = s1

    xor     eax, eax

    shr     edx, 16         ; edx = s2

    mov     ebx, 80078071h

    shr     len, 2

_l1:

  

    cmp     len, 0

    jz      _done



    mov     edi, 963

    cmp     len, edi

    ja      _b2

    mov     edi, len

_b2:

    sub     len, edi



    next:

        mov     al, [esi+0]

        add     ecx, eax

        mov     al, [esi+1]

        add     edx, ecx



        add     ecx, eax

        mov     al, [esi+2]

        add     edx, ecx



        add     ecx, eax

        mov     al, [esi+3]

        add     edx, ecx

    

        add     ecx, eax

	add	esi,4

        add     edx,ecx

	dec	edi



    jnz     next



	 mov edi,edx ;devident

	 mov eax,edx

	 mov edx,ebx ;= 80078071h

	 mul ebx

	 mov eax,edx

	 mov edx,65521

	 shr eax,15

	 mul edx

	 sub edi,eax



	 mov eax,ecx

	 mov edx,ebx

	 mul ebx

	 mov eax,edx

	 mov edx,65521

	 shr eax,15

	 mul edx

	 sub ecx,eax

	 mov edx,edi

	 xor eax,eax

    jmp _l1

_done:

    

    mov     eax, edx

    shl     eax, 16

    add     eax, ecx



    ret

Svin2 endp

Thomas, my test shows 5552 bytes can be processed
in the worst case without overflowing 32-bits.

	or ecx,-1

	mov eax,BASE-1

	mov edx,BASE-1

@@:	inc ecx

	add eax,255

	add edx,eax

	jnc @B

; ECX is max bytes before overflow in worse case: 5552

Or, am I missing something?

I've tested all versions, with a 100x loop, and made one new version based on Thomas3AndSvin, with bitRAKEs suggestion about the instruction order.

eax = 004031C0

------------------------------------------------------------------

eax = Nico                        : [9639F0C4], 1332 ms [100x2MB],  150.15 MB/s

eax = BitRAKE                     : [9639F0C4], 1722 ms [100x2MB],  116.14 MB/s

eax = BitRAKE2                    : [9639F0C4], 1692 ms [100x2MB],  118.20 MB/s

eax = Thomas2                     : [9639F0C4], 1453 ms [100x2MB],  137.64 MB/s

eax = Thomas3                     : [9639F0C4],  801 ms [100x2MB],  249.68 MB/s

eax = Svin2                       : [8B1CBB09],  741 ms [100x2MB],  269.90 MB/s

eax = Nico2                       : [9639F0C4], 1091 ms [100x2MB],  183.31 MB/s

eax = Thomas3AndSvin              : [9639F0C4],  781 ms [100x2MB],  256.08 MB/s

eax = Thomas3AndSvinAndBitRAKE    : [9639F0C4],  772 ms [100x2MB],  259.06 MB/s

eax = BitRAKE3                    : [9639F0C4],  230 ms [100x2MB],  869.56 MB/s

It's obvious that bitRAKE beats the rest with his athlon version, but the other (latest) ones are reasonably fast as well.. Could anyone test this on a pentium?

Thomas

jademtech, download the attachment in this post above:
http://www.asmcommunity.net/board/showthread.php?s=&postid=31317.msg31317

...copy a 2MB+ file to the same directory, rename it to file.dat and execute file2obj.bat to create the object file. Then make.bat

Edit: Replace the test.asm file with the new one above before building.

bitRAKE3 requires a P4/Athlon, iirc.
Comment that one out, and build again.

Edit: No, that isn't correct - the prefetch instructions should be seen as NOP's. Wish, I wasn't at work - I'd build a copy for you...

Well, it's Friday and I wouldn't have the job if I couldn't do both at once. You have to comment out the TESTPROC line at the end with the bitRAKE3 in it.