Replacement for atodw and atodw_ex test pieces.

[Rockoon]

Rockoon,

If all of the data is in the correct form (IE does not need to be parsed from other test) its easy enough to tokenise it in one pass.

I am arguing about your "correct form" idea. This idea that the input is "correct form" only when its nicely null terminated is wrong.

I'm thinking along the lines of working with large CSV files (comma separated values) and other large textual data sets (why else would performance be a concern?)

Sure, its easy enough to tokenize it in one extra pass. Its still an extra pass, and one thats particularly memory bandwidth sensitive.

[Antariy]

Hi!

Guys, with yours disputes you forgot to test this "http://www.masm32.com/board/index.php?action=dlattach;topic=14522.0;id=7946" (link to archive). New Axa2l, true unrolled.

This is interesting algo, and very interesting, how it works on different machines.



Alex

[Antariy]

Rockoon, Dave (aka KeepingRealBusy) write one good proc, for conversion hex2dword. In it he use look-up table, with values of converted char if this char is hex, and special "signal" value, if char is not hex. So, code make conversion and checking in one pass - I think, this is same good solution. As you thinks?
For slightly changed version of Dave's proc you may goto "http://www.masm32.com/board/index.php?topic=14540.msg117994#msg117994". In archive - krbhtodw - his proc.



Alex

[hutch--]

Rockoon,

I agree that if your target is a large CSV file then you need to handle the data conversion in a different manner. I would be looking at a one pass tokeniser that did the conversion on the fly but I would make the comment that an algo that is both a file parser and a conversion utility would need to be timed against a 2 pass system where you tokenise it as fast as you can then convert it sequentially.

The single pass version has advantages in memory bandwidth but it would be a slower algo because of the amount of work it would have to do. Timing both would tel you the difference. I would imagine that in a one pass parser/converter that the conversion algo would have to be short and have a faster attack time than unrolled linear conversions and code cache issues would come into play.

[Antariy]

And, Rockoon, one note more. If compare getting char not with zero, but with 30h, and go to end if value is smallest than this code, then big part of punctuation chars will be processed correctly - as end of string with number.



Alex

[Antariy]

Hi, Hutch!

Test, please, archive in post by 4 (edited) post above.



Alex

[hutch--]

 :bg

Alex,

I will get there but I am a bit tired of writing test pieces, I only have a million other things to do.

[Antariy]

Hutch, I understand you.
But you may run already compiled test from archive. This is take ~30secs. This is your old test-bed. I only replace in source my proc, and compile source. So, you no need to writing test pieces.
Only time of working this algo on newest CPUs interesting to me, no "racing" with other's algos.



Alex
P.S. Sorry me, if I'm pester to you!

[hutch--]

Alex,

This is the result from BM10. Timed on the Core2 3 gig Quad I work on.

Code Select Expand


188 atou
203 atodL
250 Axa2l
218 atodJJ
204 atou_ex
234 atou_rock
187 atou
204 atodL
250 Axa2l
203 atodJJ
218 atou_ex
235 atou_rock
187 atou
203 atodL
250 Axa2l
219 atodJJ
219 atou_ex
234 atou_rock
188 atou
203 atodL
250 Axa2l
203 atodJJ
172 atou_ex
234 atou_rock


187 ms average atou
203 ms average atodL
210 ms average atodJJ
203 ms average atou_ex
250 ms average Axa2l
234 ms average atou_rock
Press any key to continue ...


[Antariy]

Thanks, Hutch!

So, results no so bad, as I expect :) On my CPU this proc works not well. Because it hard to prediction of CPU - path of execution is depended from data, and this is very not well in speedy programming, contrary to OOP paradigms. This proc implement something like virtual-methods :), and this methods work not fastly.

But, this algo is for fun - it interesting enought, and show some good info about designing. So, it is no bad :)



Alex

[mineiro]

Code Select Expand


align 16
mineiro proc String:DWORD

  ; ------------------------------------------------
  ; Convert decimal string into UNSIGNED DWORD value
  ; ------------------------------------------------

xor eax,eax
mov edx,[esp+4] ;coment this you dont use calling convention
movzx ecx,byte ptr [edx]
test ecx,ecx
je @fora
movzx eax,byte ptr [edx+1]
test eax,eax
je @ssub30
lea ecx, [ecx+ecx*4-30h*5]
lea ecx, [eax+ecx*2-30h]
movzx eax, byte ptr [edx+2]
test eax,eax
je @F
lea ecx,[ecx+ecx*4]
lea ecx, [eax+ecx*2-30h]
movzx eax, byte ptr [edx+3]
test eax,eax
je @F
lea ecx,[ecx+ecx*4]
lea ecx, [eax+ecx*2-30h]
movzx eax, byte ptr [edx+4]
test eax,eax
je @F
lea ecx,[ecx+ecx*4]
lea ecx, [eax+ecx*2-30h]
movzx eax, byte ptr [edx+5]
test eax,eax
je @F
lea ecx,[ecx+ecx*4]
lea ecx, [eax+ecx*2-30h]
movzx eax, byte ptr [edx+6]
test eax,eax
je @F
lea ecx,[ecx+ecx*4]
lea ecx, [eax+ecx*2-30h]
movzx eax, byte ptr [edx+7]
test eax,eax
je @F
lea ecx,[ecx+ecx*4]
lea ecx, [eax+ecx*2-30h]
movzx eax, byte ptr [edx+8]
test eax,eax
je @F
lea ecx,[ecx+ecx*4]
lea ecx, [eax+ecx*2-30h]
movzx eax, byte ptr [edx+9]
test eax,eax
je @F
lea ecx,[ecx+ecx*4]
lea ecx, [eax+ecx*2-30h]
cmp byte ptr [edx+10],0
je @F
mov eax,0
mov ecx,0
jmp @fora
@@:
mov eax,ecx
mov ecx,1
@fora:
ret 4
@ssub30:
mov eax,ecx
xor eax,30h
ret 4
mineiro   endp


[mineiro]

In some procedures in these test return wrong values in ecx or eax.

Code Select Expand


.data
align dalg
itm1 db "4294967295",0 ;eax==0ffffffffh ecx!=0
align dalg
itm2 db "42949672952",0 ;eax==0 ecx=0
align dalg
itm3 db "0",0 ;eax==0 ecx!=0
align dalg
itm4 db "0000",0 ;eax==0 ecx!=0

regards