This is too slow

[dedndave]

well - it is in the  registry

[HKEY_CURRENT_USER\Control Panel\International]
"sMonThousandSep"=","

[oex]

:bg

Code Select Expand


CountryThousandsSeperatorCode PROC USES esi

print "Hello"
mov esi, input("What Country Thousands Seperator Code Are You Looking For? ")
print "Whiz Bang Whir"
print "I'm sorry I dont have that Country Thousands Seperator Code"
mov esi, input("Please Enter your Country Thousands Seperator Code ")
print "Your Country Thousands Seperator Code is: "
print esi

ret

CountryThousandsSeperatorCode ENDP


[dedndave]

that'll work - lol

but, i was thinking of a little routine during init that reads the registry value and stores it   :P
then, the conversion routine can grab the stored value, or it can be passed as a parm

[frktons]

that'll work - lol

but, i was thinking of a little routine during init that reads the registry value and stores it   :P
then, the conversion routine can grab the stored value, or it can be passed as a parm

This feature has already been implemented. Do you want to change the actual working one
with some other weird one?  :lol

[frktons]

Having a look at Hutch's example, it looks like the code is using an "already converted
unsigned dword into a string":

Code Select Expand


   fn format_num_string,"1234567890",pbuf


and this is not the task we are trying to accomplish.
The task here is to convert an unsigned dword into an ASCII string with thousand separator.

So the starting point has to be an array of unsigned dword value as stated in the first post.

Frank

[frktons]

Just for fun I tried to implement Hutch's code, and guess what?
He got a good result, considering he is working on a two steps
algo:

Code Select Expand


┌─────────────────────────────────────────────────────────────[19-Nov-2010 at 13:09 GMT]─┐
│OS  : Microsoft Windows 7 Ultimate Edition, 64-bit (build 7600)                         │
│CPU : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz with 2 logical core(s) with SSSE3           │
├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│        Algorithm notes           │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│01 ustrv$ + GetNumberFormat       │    95   │   44.782 │   45.197 │   44.310 │   44.255 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 udw2str + GetNumberFormat      │    65   │   43.805 │   45.017 │   43.724 │   43.839 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│03 wsprintf + GetNumberFormat     │    73   │   51.995 │   51.742 │   50.983 │   50.973 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│04 Clive - IDIV and Stack         │   120   │    3.029 │    3.007 │    3.035 │    3.016 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│05 Clive - reciprocal IMUL        │   157   │    2.004 │    1.987 │    1.954 │    1.989 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│06 Hutch ustr$ + format algo      │   159   │    5.792 │    5.901 │    5.862 │    5.783 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤


Congrats Hutch, if you try harder, you can get even better than that.  :P

Frank

[hutch--]

 :bg

ustr$() is a MSVCRT function call. The "format_num_string" was designed to do just what it says.

[frktons]

:bg

ustr$() is a MSVCRT function call. The "format_num_string" was designed to do just what it says.

I think that combining together the udw2str code and the one you have used to
format the string, you could get results that are 30-40% faster than the combination of
ustrv$ and your formatting algo.  :U

[hutch--]

I think you could combine the numeric conversion and the output formatting with some reasonable gains but the formatting algo is useful in its own right and may end up in a library. Depending on how you do the conversion you can save the length check as you should have the length from the conversion.

[frktons]

I think you could combine the numeric conversion and the output formatting with some reasonable gains but the formatting algo is useful in its own right and may end up in a library. Depending on how you do the conversion you can save the length check as you should have the length from the conversion.

Considering that udw2str uses a magic number:

Code Select Expand

    mov ecx,429496730

and it is .386 compatible, there is probably enough room for optimizing the conversion just using
MMX or XMM registers and SSE2 and upwards opcodes. An entire thousand separated unsigned dword
uses only 14 bytes, including the NULL terminator. And an XMM register can hold up to 16 bytes.

I've to think a lot about this simple task. Maybe the limits are still far from what we got till now.

By the way, the tests started yesterday, there is a lot of time ahead.  :P

[Antariy]

i am sure there is a function you can call to get the right seperator for the user's country/code page   :P

Dave, are you make suggestions before checking them???

GetLocaleInfo returned right separator, and IT GET THIS FROM REGISTRY. So, you can use RegOpenKey and RegQueryValue and RegCloseKey APIs to doing this.

I'm prefer use one (one!) API for the same results :P



Alex

[Antariy]

but, i was thinking of a little routine during init that reads the registry value and stores it   :P
then, the conversion routine can grab the stored value, or it can be passed as a parm

The same - read post above. Of course, make things harder is very interesting, though :P

[frktons]

I'm tempted to try a combination of algos and see what I get.

First: a lookup table with initialized string four bytes long, with group of three digit and the separator.
Divide the number for 1000 and use the remainder as an index for the look-up table to get the
sequence of digits. Pushing the 4 bytes into the stack, and go to next division, checking if the
number is > 999 to perform he division by 1000, or use it directly as table index.

This should be fast enough, I guess, max 3 division of integer numbers, so IDIV. Pushing and popping
4 bytes at a time, and building the final formatted string.

I'll try it next days, as I've got time enough.

Frank

[Antariy]

This should be fast enough, I guess, max 3 division of integer numbers, so IDIV. Pushing and popping
4 bytes at a time, and building the final formatted string.

This will be fast, but will require ~4KB table of numbers.  :eek  :lol

[frktons]

This will be fast, but will require ~4KB table of numbers.  :eek  :lol

I can afford this, and maybe more ....  :P