Inlcuding the ghc-users list. On Mon, Dec 6, 2010 at 10:10 AM, Andrew Coppin <andrewcop...@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-c...@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users