I am writing some hash functions for a compiler and I use the __int64 datatype frequently. The compiler is intended to be supported (and so far is) on different OS’s. I know that __int64 is a type that can be compiled by most major C++ compilers for my target systems so that’s not the problem. I am using hash functions to make large character strings smaller and quicker to compare and they work wonders on 64-bit capable OS’s; but would there be a large enough performance decrease on 32 bit OS’s to cancel out the benefits? I could use 32 bit integers but then it would greatly lessen the effectiveness of the hash functions.
Edit:
It is custom code and very simple. The first hash function generates a unique 64-bit int from 12 alphanumeric (including underscore) characters. Then a class handles hashes over 12 characters by creating address-linked lists of 64bit hashes and overloads the comparison operators. The overloaded compares are short circuited and compare down the address-linked list. I’ve ran tests on my machine to compare speed of randomly generate large hashes (100 – 300 characters) compared to themselves (worst-case senario) and it proved to be faster than string compares. In order to better simulate the overhead of generating hashes, I’ve also ran compare tests of pre-generated large hashes compares against them selves. This is all running with code optimization turned off. With ~1 billion hash compares vs. ~1 billion string compares, the hash took around 16% of the time. This was all in a 64 environment though. I don’t have a 32-bit machine to run tests with
64bit sized integers aren’t substantially slower at all on a 32bit x86 architecture. They’re not as fast as 32bit ints, obviously, but aren’t notably slower. It’s not at all reckless to use a 64bit int for hashes regardless of x86 or x64. The additional overhead will likely be minimal compared to say, a couple of unneeded dynamic allocations or failed algorithms.