[Haskell-cafe] Building Haskell Platform natively for 64bit Windows

[austin seipp]

On Thu, Jun 9, 2011 at 1:53 PM, Andrew Coppin
<andrewcoppin at btinternet.com> wrote:
> 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.
>

The problem is you're probably going to need to spill things
(somewhere) in order to operate on the upper 32bits of any given
register in the non trivial case. x86 already is pathetic in its 8 GP
registers. amd64 brings it up to 16. GHC already has to put a
significant amount of stuff on the stack on x86 because of that, IIRC
(I think only 3 STG registers are actually pinned, and the remaining 5
are for use by the register allocator.)

> 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...

It's highly unlikely that the cost of a foreign call (even an unsafe
one) in terms of just CPU cycles will be cheaper than executing a few
primitive arithmetic ops on the CPU. GHC will at least need to spill
to the stack before and reload after every call. If the arithmetic ops
were to somehow pipeline, that would be even worse in your favor,
because the cycle count for your core operation would go *down* as a
result of the pipelining, making the foreign call that much more
expensive.

Furthermore, GHC will invoke the C compiler on a FFI'd .c file to
produce an object file. It's unlikely the linker will be able to
inline copies of the function at call sites at link time, so if you
use C, the function will likely exist as object-code far away from the
call sites, and that will probably hurt your L1i cache locality a bit.

-- 
Regards,
Austin