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.)
Inlcuding the ghc-users list.
On Mon, Dec 6, 2010 at 10:10 AM, 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.)
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
andrewcoppin:
[100 lines snipped] Andrew, if you have a bug report, please use the bug tracker: http://hackage.haskell.org/trac/ghc/wiki/ReportABug Keep your reports concise and to-the-point, for the best hope of getting useful stuff done. Cheers, Don
On Mon, Dec 06, 2010 at 10:04:35AM -0800, Don Stewart wrote:
Andrew, if you have a bug report, please use the bug tracker:
Or reddit, of course. ;-) -- You've been warned.
On 06/12/2010 06:04 PM, Don Stewart wrote:
Andrew, if you have a bug report, please use the bug tracker:
From what I've seen, the GHC devs already have vastly more bug reports than they know what to do with. I tend to hessitate filing tickets until I'm sure I'm looking at an actual bug, rather than just a misunderstanding on my part.
Keep your reports concise and to-the-point, for the best hope of getting useful stuff done.
There's actually a couple of seperate issues there, which should presumably end up being seperate tickets. The fact that, out of the box, dynamic linking fails is a bug. The fact that I can't work out the reason or rhyme behind where the DLLs get put is more sort of a "hey guys, I'm not really sure what you were going for here" type of thing than an actual /bug/. I don't know if it's worth filing a ticket for prior versions of GHC failing to build dynamically in a less than graceful way. On one hand, the problem doesn't exist in GHC7. On the other hand, maybe we want to record this information anyway? Regarding the documentation, what's the best way to fix this? Do I just file a bug against every sentence that's wrong, or would it be quicker for me to actually download a copy of the source and fix the problems myself? (I can probably fix some of it myself, but in other cases I actually don't know what the correct information is, so it would have to be written by somebody who knows what they're talking about.)
participants (4)
-
Andrew Coppin -
Antoine Latter -
Darrin Chandler -
Don Stewart