On the other hand, I still think it would be worth actually
benchmarking this stuff to see how much difference it makes. Wouldn't
surprise me if the CPU designers did some clever trickery with
pipelining and superscalar execution to make two adjacent 32-bit
instructions execute the same way as a single 64-bit instruction would...
(I've seen various sources claim that running software in 64-bit mode
only gives you a 2% speedup. Then again, they presumably aren't
testing with chess software which heavily utilises explicit 64-bit
operations.)
For a chess engine this is for sure not true. I guess that this is one
of very few domains where it really matters! The most (basic) operations
with bitboards are anding, oring, xoring, shifting and (for magic
bitboards) multiplying 64 bits values. When using 32 bits you need for
some of these more then double time to achieve the same.
I'm still left wondering if using 32-bit instructions to manipulate
64-bit values is actually that much slower. Back in the old days of
non-pipelined, uniscalar CPUs, it would certainly have been the case.
Today's processors are far more complex than that. Things like cache
misses tend to have a way, way bigger performance hit than anything
arithmetic-related.
I was wondering if there is a possibility to support 64 bit native codes
without other stuff (calling conventions, win64 specific system calls
etc). This could be perhaps a first step to full 64 bit support. But
from the code of ghc I could not understand what this would mean.
I'm wondering if you could write the operations you want is small C stub
functions, and FFI to them and do it that way. I don't really know
enough about this sort of thing to know whether that'll work...
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
