[Haskell-cafe] Trying out GHC 7

[Antoine Latter]

Inlcuding the ghc-users list.

On Mon, Dec 6, 2010 at 10:10 AM, Andrew Coppin
<andrewcoppin at btinternet.com> wrote:
> 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.)
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>