[Haskell-cafe] Trying out GHC 7

[Andrew Coppin]

OK, so the other day I decided to take GHC 7.0.1 for a spin.

Suffice it to say, it definitely compiles stuff. So far, I've only tried 
running it in a Windows XP virtual machine with a single core, so I 
haven't been able to test what multicore performance is like.

One thing that did interest me is the conflicting information about 
whether or not dynamic linking is supported on Windows. Half the User 
Guide claims that this /is/ supported, and the other half still contains 
statements that it is /not/ supported. So I thought I'd just go 
physically try it and see if it works.

Well... it compiles stuff. Hello World goes from being 518KB to being a 
piffling 13KB. Which is nice.

I almost didn't bother actually trying to /run/ the resulting binary... 
But when I did, I discovered that it immediately crashes, whining that 
it can't find the DLL it wants. So, out of the box, the Windows setup is 
broken. (Obviously the Windows section of the User Guide makes no 
mention of how DLLs are located; it only explains the situation for 
Linux and Mac OS. I especially liked the bit where it says that there 
are "three modes", and then proceeds to list only two...)

In the interests of science, I wanted to see if I could make it run by 
just putting the necessary DLLs into the same folder as the binary. But 
first I had to /find/ them. I had expected to find a folder somewhere 
with all the DLLs in it... but no, the installer appears to have 
sprinkled them around the filesystem more or less at random. Some of 
them are in folders named for the package, some of them just sit in the 
root folder.

After about 20 minutes of searching, I found the RTS DLL. Running the 
program, it now instantly crashes because of a /different/ DLL. This one 
didn't take quite so long to find (now that I know roughly where to 
look). I fixed that, and now the binary crashes with yet another missing 
DLL. And so on and so forth. In the end, Hello World required 5 DLLs. 
Better still, together these totalled 8MB of data. (!) So the 
distribution package is now about 16x bigger than with static linking. 
Oh joy.

Clearly if you just want to distribute one executable binary, you're 
going to use static linking. (E.g., darcs.exe will hopefully remain 
statically linked.) But I suppose if I had a whole heap of Haskell 
programs then the extra complexity of delivering half a dozen DLLs might 
may off in terms of space reductions. And of course, on /my/ development 
box, I don't need a zillion redundant copies of the RTS code, etc. (Or 
at least, I won't if I can figure out how to make the programs able to 
actually /find/ the necessary DLLs...)

Actually, of all the DLLs, only "base" is actually large - it's 
approximately 6MB on its own. GHC-Prim is 0.5MB, and the others are all 
relatively tiny. It feels slightly irritating that I need to inclide the 
FFI DLL when I'm not doing and FFI - but of course, the entire Haskell 
I/O subsystem /is/ doing FFI. Similarly, I'm not using 
arbitrary-precision integers, but various I/O operations return file 
sizes as Integer, so GMP must also be included. Neither of these things 
are actually especially large.

It's rather confusing that the User Guide is out of date in so many 
places. (And not just regarding dynamic linking on Windows. For example, 
one section claims that "+RTS -f" will tell you what options are 
supported, but that actually yields "unknown RTS opion: -f". It seems 
that "-?" is the correct option name.) If I can get a suitable Linux VM 
going, I might have a go at contributing some updates.

Just for completeness, I tried asking for dynamic linking with an older 
version of GHC (6.10, IIRC) - one that supports it on Linux but not 
Windows. I was expecting to get either "dynamic linking is not supported 
on this platform", or at worst "unknown option -dynamic". In fact, what 
I got was "gcc: cannot find file Main.dyn_hi". Oh, that's graceful 
failure then. >_<

I did also briefly see if the LLVM backend would work under Windows. I 
wasn't entirely sure if LLVM comes with the installer binary or you need 
to get it seperately. (You might say "obviously it's seperate", but the 
installer already contains the entire GCC system, for example.) 
Attempting to use this resulted in a summary error message ("cannot run: 
opt") which doesn't make it especially clear that the problem is that 
LLVM isn't installed. Perhaps there's no better way of detecting this 
condition, I don't know, but something more illuminating would be nice.

I briefly had a look at how to install LLVM, but it appears that you 
have to build it from source. This is not my idea of a fun time, so 
given the minimal speed difference, I just won't bother.

I haven't had time to play with any of the other new good stuff in GHC 
7. (The multicore performance, the new GC stuff, etc.)