Sign in to follow this  
Followers 0
cmallett

Switch To 64-bit Math?

10 posts in this topic

64-bit hardware will probably become standard in PCs in the next few years. Due to problems such as file sizes greater than 2 gig (when expressed in bytes), tickcounts greater than INT_MAX, etc... might it not be worthwhile to switch all the internal workings of AutoIt3 into 64-bit math (I imagine it already uses 64-bits, i.e. doubles, for floating point).

I don't know how much of a performance hit there is.. I'm guessing it's around 4x slower to have double-wide ints, but that's purely a guess. On 64-bit hardware, of course, it's probably faster to use 64 bits for everything (though admittedly it will consume more memory).

Share this post


Link to post
Share on other sites



AutoItV3 is using doubles (64-bit floating-point) for all the math. In future, we may be able to do things with long doubles (80-bit floating-point). long long (64-bit integers) are not needed at this point.

The 64-bit processors will become more prevelant in the future (certainly before May 2038, when 32-bit time_t overflows) but Win95/98 has no support for 64-bit. I wonder how my MS-DOS programs will work on a 64-bit processor? :whistle:


David Nuttall
Nuttall Computer Consulting

An Aquarius born during the Age of Aquarius

AutoIt allows me to re-invent the wheel so much faster.

I'm off to write a wizard, a wonderful wizard of odd...

Share this post


Link to post
Share on other sites

I think it is way too early to be getting too concerned about 64 bit. It is definitly something to be considered for future versions though. Maybe in AutoIt 4 or 5.


George

Question about decompiling code? Read the decompiling FAQ and don't bother posting the question in the forums.

Be sure to read and follow the forum rules. -AKA the AutoIt Reading and Comprehension Skills test.***

The PCRE (Regular Expression) ToolKit for AutoIT - (Updated Oct 20, 2011 ver:3.0.1.13) - Please update your current version before filing any bug reports. The installer now includes both 32 and 64 bit versions. No change in version number.

Visit my Blog .. currently not active but it will soon be resplendent with news and views. Also please remove any links you may have to my website. it is soon to be closed and replaced with something else.

"Old age and treachery will always overcome youth and skill!"

Share this post


Link to post
Share on other sites

64-bit hardware will probably become standard in PCs in the next few years.  Due to problems such as file sizes greater than 2 gig (when expressed in bytes), tickcounts greater than INT_MAX, etc... might it not be worthwhile to switch all the internal workings of AutoIt3 into 64-bit math (I imagine it already uses 64-bits, i.e. doubles, for floating point).

I don't know how much of a performance hit there is.. I'm guessing it's around 4x slower to have double-wide ints, but that's purely a guess.  On 64-bit hardware, of course, it's probably faster to use 64 bits for everything (though admittedly it will consume more memory).

It already uses doubles for everything. The only time 32bit ints are used is for the bit operations (BItOR) and also for the hex format 0x12345678. There is so much "other" overhead around that the difference between ints and doubles wasn't noticable (in fact it is quicker now as less conversion happens within the variant class)

Share this post


Link to post
Share on other sites

That's interesting. I was under the impression that doubles were very slow even compared to __int64 (perhaps 10 to 100 times slower, as a guess). But that might be a left-over impression from yesteryear, when super-powered CPUs with their MMX, SSE, and killer FPUs weren't the norm.

Share this post


Link to post
Share on other sites

I don't think __int64 even exists as anything other than a compiler structure when compiled for 32bit CPUs. (That's the impression I got any way from browsing MSDN)

If the asm I looked at for the pow() etc, functions is anything to go by the FPU handles doubles natively.

But in any case all the parsing, expression parsing, variant conversion, operator precedence blah blah blah take up 99% of the time anyway. I have timetest script that used to take 18seconds under the old "integer" version of autoit, the same script currently takes 2seconds. The switch from int -> double made no impact (actually slightly faster because the variant class doesn't have to work as hard).

In a natively asm compiled exe then who knows there may be a massive performance penalty but it's not really relevant in our case.

Share this post


Link to post
Share on other sites

I did some testing. The following are excerpts from the upcoming AutoHotkey changelog:

Added floating point support ... Integer math (64-bit) is still used whenever floating point numbers aren't involved because testing reveals that scripts with math intensive loops run over 5 times faster with integers vs. floating point (Pentium II and Athlon XP). [Admittedly, the avg. user's real world performance won't be helped much].

Switched from 32-bit to 64-bit integer math. 32-bit is only about 40% faster than 64-bit for scripts running intensive math loops on Pentium IIs and Athlon XPs, so the greater flexibility seems worth the cost. 64-bit also solves following limitations: unsigned tickcounts (%A_TickCount%), DWORDs read from the registry, and file sizes over 2 gigabytes are all reported correctly as positive rather than negative numbers now.

Share this post


Link to post
Share on other sites

If you use unsigned longs, you will not have the negative values being reported.


David Nuttall
Nuttall Computer Consulting

An Aquarius born during the Age of Aquarius

AutoIt allows me to re-invent the wheel so much faster.

I'm off to write a wizard, a wonderful wizard of odd...

Share this post


Link to post
Share on other sites

#9 ·  Posted (edited)

Edit: I misread your post at first. Now I understand what you meant. Since everything in AutoHotkey is stored as strings, they must be converted to numbers on the fly (which amazingly seems much faster than performing some one-step math operations). Therefore, I can't just switch everything to unsigned long because then support for true negatives would be lost when the variable is read back in after having been "written out". And even if I did, it would only double the capacity, which still isn't very future proof for things like file sizes.

Thus, I am using "long long" (aka __int64), which is a signed value.

I think AutoIt3 doesn't see much of a performance boost from this because, as Jon said, there's a lot of other overhead involved with the interpretation of the script during runtime (tokenizing, etc.)

By comparison, AutoHotkey is such a primitive language that scripts can be semi-compiled at load-time, making them almost as fast as a natively compiled 3GL or 4GL program would be.

Edited by cmallett

Share this post


Link to post
Share on other sites

#10 ·  Posted (edited)

The only time 32bit ints are used is for the bit operations (BItOR) and also for the hex format 0x12345678.

What about FileGetSize(). It returns a signed 32 bit number. I.e. it works only on files smaller than 2GB. B) Jon could fix it by using the Win32 API GetFileSizeEx(), but it works only for W2K and XP. As long as Win 9x/ME is supported, you could put the following func with the standard includes:

; Works also for files larger than 2GB
Func _FileGetSize($filename)
   Local $tmp
   Local $line
   Local $pos
   $tmp = @TempDir & "\au3getsz.tmp"
   RunWait(@COMSPEC & ' /c dir /-c "' & $filename & '" > "' & $tmp & '"', "", @SW_HIDE)
   $line = FileReadLine($tmp, 6)
   FileDelete($tmp)
   $tmp = StringSplit($filename, '\')
   $pos = StringInStr($line, $tmp[$tmp[0]])
   Return Number(StringMid($line,  $pos - 13, 13))
EndFunc

Looks a little complex, but it's hard to make it simpler and general, because the dir's date format is variable. Ps: I haven't tested it on Win98, but works well on XP with >2GB files. :whistle:

/EDITED: shortened code.

Edited by tylo

blub

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0