[Haskell-cafe] Trying out GHC 7
andrewcoppin at btinternet.com
Mon Dec 6 17:10:10 CET 2010
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
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.
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.)
More information about the Haskell-Cafe