On 18/05/2011 19:22, Jason Dagit wrote:

On Wed, May 18, 2011 at 2:50 AM, John Sneer wrote:

...

Hello all,

I know it is not probably good question to this list, but anyway, could anyone point me to some more detailed "how to" where is described building of Haskell Platform natively to 64bit Windows?

If you figure out how to do this, I would like to know as well. I could also benefit from 64bit Haskell on windows.

There is no port of GHC to 64-bit Windows yet. Various people have expressed an interest in having one, but it is a significant chunk of work to implement (plus extra work to maintain and build distributions), so we don't have any plans to do it in the short term. You can track progress (or lack thereof) by adding your email to the CC on the ticket: http://hackage.haskell.org/trac/ghc/ticket/1884 If you want to help out, join cvs-ghc@haskell.org and we can help with pointers to what needs to be done. Cheers, Simon

Am 23.05.2011 13:32, schrieb Simon Marlow:

On 18/05/2011 19:22, Jason Dagit wrote:

...

On Wed, May 18, 2011 at 2:50 AM, John Sneer wrote:

...

Hello all,

I know it is not probably good question to this list, but anyway, could anyone point me to some more detailed "how to" where is described building of Haskell Platform natively to 64bit Windows?

If you figure out how to do this, I would like to know as well. I could also benefit from 64bit Haskell on windows.

There is no port of GHC to 64-bit Windows yet. Various people have expressed an interest in having one, but it is a significant chunk of work to implement (plus extra work to maintain and build distributions), so we don't have any plans to do it in the short term.

You can track progress (or lack thereof) by adding your email to the CC on the ticket:

http://hackage.haskell.org/trac/ghc/ticket/1884

If you want to help out, join cvs-ghc@haskell.org and we can help with pointers to what needs to be done.

Cheers, Simon

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hi, Just to double check: that means, today it's not possible to generate 64 bit operations under Windows, including bit level .&., .|. a.s.o. (from Data.Bits), and this situation will stay like this for a while. I'm asking this because I'm currently writing a pure Haskell chess engine based on bitboards. The bitboards are 64 bit wide and the basic operations are critical for speed, which is always critical in chess engines. Then it looks I'll have to implement these operations in C and use FFI to link them. Nicu

On 06/06/2011 09:34 PM, Nicu Ionita wrote:

Hi,

Just to double check: that means, today it's not possible to generate 64 bit operations under Windows, including bit level .&., .|. a.s.o. (from Data.Bits), and this situation will stay like this for a while.

I'm asking this because I'm currently writing a pure Haskell chess engine based on bitboards. The bitboards are 64 bit wide and the basic operations are critical for speed, which is always critical in chess engines.

Then it looks I'll have to implement these operations in C and use FFI to link them.

No, 64-bit integer operations will /work/ just fine, regardless of what platform you're on. Whether it will take advantage of 64-bit operations at the machine-code level is another matter entirely. I'm not especially sure, but I think even in 32-bit mode, the x86 line of processors supports performing 64-bit operations via MMX, SSE or similar. Whether GHC is using that, I couldn't tell you. I suppose the ultimate answer is: Benchmark it, and see how fast it is.

On Tue, Jun 7, 2011 at 11:32 AM, Nicu Ionita wrote:

Yes, I was a little bit unclear, I wanted to say: the generated code does not use the 64 bit instructions (i.e. 1 instruction for .&., for example). Of course, it works, but I suppose, much slower then it could (3-4 times, for that part?)

Have you checked this by looking at the generated assembly? I generated some assembly from GHC on windows. Here is what it looks ilke: http://hpaste.org/47610 My assembly-fu is not strong enough to tell if it's using 64bit instructions. Jason

It is 32 bits, I'm sure. Besides the 32-bit stack manipulation, it uses eax and ecx to hold two 32-bit parts of the 64-bit number. Best regards, Rafael On Thu, Jun 9, 2011 at 02:54, Scott Lawrence wrote:

On 06/09/2011 01:47 AM, Jason Dagit wrote:

...

Have you checked this by looking at the generated assembly? I generated some assembly from GHC on windows. Here is what it looks ilke: http://hpaste.org/47610

My assembly-fu is not strong enough to tell if it's using 64bit instructions.

It would appear to be 32-bit. (pushl instead of pushq & no instances of aligning to 8-byte boundaries)

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Rafael Gustavo da Cunha Pereira Pinto

On 09/06/2011 06:54 AM, Scott Lawrence wrote:

On 06/09/2011 01:47 AM, Jason Dagit wrote:

...

Have you checked this by looking at the generated assembly? I generated some assembly from GHC on windows. Here is what it looks ilke: http://hpaste.org/47610

My assembly-fu is not strong enough to tell if it's using 64bit instructions.

It would appear to be 32-bit. (pushl instead of pushq& no instances of aligning to 8-byte boundaries)

The general register naming scheme on x86 is: AL, AH: 8 bits AX: 16 bits EAX: 32 bits RAX: 64 bits There's a lot of code there, but from what I can see, it's all operating on 32-bit registers. So I'd say this is 32-bit code. 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.)

...

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

On 09/06/2011 08:44 PM, austin seipp wrote:

On Thu, Jun 9, 2011 at 1:53 PM, Andrew Coppin wrote:

...

I'm still left wondering if using 32-bit instructions to manipulate 64-bit values is actually that much slower.

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.

Well, that's true enough. Given that AMD64 adds more registers, I'm surprised that this apparently makes such a small difference to wall-clock run-times. (But perhaps it makes a bigger difference for GHC. I don't know.)

...

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.

Yeah, you're probably right there actually. Too bad GHC doesn't support inline assembly yet... (Or does it? I know it supports inline Core now.)

On Thu, Jun 9, 2011 at 2:06 PM, Andrew Coppin wrote:

Too bad GHC doesn't support inline assembly yet... (Or does it? I know it supports inline Core now.)

Really? I found this in the manual so I think either the docs need to be updated or you are mistaken: http://www.haskell.org/ghc/docs/latest/html/users_guide/ext-core.html

It's worth mentioning 'foreign prim' is still a bit different from "inline" code - while you can certainly write Cmm and have GHC link it into your program, it is not really "inline." GHC has two different kinds of primitive operations: inline primops, and out of line primops. foreign primops are currently always out of line. Inline primops require actual GHC hacking, as they are short code sequences emitted directly by the code generator, that don't block or require allocation. As far as I know, GHC will naturally still generate a call to these out of line primops when you use them - in the form of a 'jmp' instruction, which is all that exists in Cmm (if someone out there knows more, like Johan perhaps who recently did memcpy inline primops, please correct me.) GHC will not necessarily have to spill STG registers (as it would in the case of a true foreign call,) but the instructions certainly won't be inline. Truthfully the use case for foreign prim is frighteningly small I think. It's been around for a while, but currently it's only client is integer-gmp, which was part of the motivation for the implementation anyway (to split GMP away from the GHC RTS, so it would be possibly to build full BSD3 haskell executables for commercial purposes, etc.) Outside of perhaps, an integer-openssl binding that instead used OpenSSL bignums, I can't think of many use cases personally. And a true 64bit GHC port to windows is of course, going to help the situation much more than any amount of hacking around the issue with 32bits and 8 registers will, while trying to retain some sense of efficiency. On Fri, Jun 10, 2011 at 12:16 PM, Andrew Coppin wrote:

On 10/06/2011 01:44 AM, Jason Dagit wrote:

...

On Thu, Jun 9, 2011 at 2:06 PM, Andrew Coppin  wrote:

...

Too bad GHC doesn't support inline assembly yet... (Or does it? I know it supports inline Core now.)

Really?  I found this in the manual so I think either the docs need to be updated or you are mistaken:

Apparently I am mistaken. It allows inline C-- (as of 6.12.1):

http://www.haskell.org/ghc/docs/6.12.1/html/users_guide/ffi.html#ffi-prim

Of course, C-- is not nearly the same as Core. Sorry about that...

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Regards, Austin