Re: The Haskell compiler of my dreams...
George Russell wrote: [snip] It won't be so hard to speed up GHC later if that becomes important. Since this has been disputed, here are three ways I believe you could speed up GHC without rewriting the whole of it. I would be surprised if you didn't get at least twice the speed, and you could probably get a lot more. The suggestions are in increasing order of difficulty. I don't say that all of them will produce dramatic improvements; you would of course have to experiment. (1) (I've suggested this before.) Make GHC access interface files more efficiently. If you do top and truss (on a Sun system) you will find that GHC has to read in a huge number of interface files, mainly from the prelude but also from other places, to get going. This is all done just using fopen in a single thread so the whole of GHC is grounded while the disk spins and (if you are using NFS like me) you wait for the network. A quick fix would be to use a Zip archive or something similar; there are not many parts of the source to change. Then you would only have to open one file for the whole of the prelude and believe me that would make a difference. (2) Stop using Make, instead steal SML/NJ's clothes and have your own compilation manager. This solves problem (1) nicely and also means you don't have to read in anything else over and over again. (Like hsc itself.) For programs which consist of lots of small modules, as they should, this would also save lots of time. Actually I think this would also provide much better handling of instance declarations. At the moment instance declarations are only picked up from files which GHC "knows about" via a transitive chain of imports. This has two user-unfriendly consequences; (a) it means that when a .hi file changes, every module which transitively imports (rather than just directly imports) has to be recompiled; (b) it is counter-intuitive. It would be better if all instance declarations in the compilation manager files were automatically known about. I can testify that SML/NJ's compilation manager really works very well and you don't miss the ability to set different compiler options for different files. Note that neither of these two suggestions actually do anything for GHC's cpu time. If I run top when GHC is running I rarely find it is using up more than 50% of the available CPU time; most of the time it is waiting on IO. However: (3) Stop using GCC-C as a backend. Instead make the GHC backend a new frontend to GCC. See http://www13.informatik.tu-muenchen.de/forschung/papers/eigene/piz_gic.ps for some explanation and arguments for this approach. Of course there are other obvious approaches. I'm sure it's unnecessary to re-code GHC in C to get C-like performance. Surely it would be better to optimise key sections of GHC by the normal tricks of unboxing things and specialising. I'm not suggesting that the GHC implementors actually do any of these suggestions now (though I suppose they could put them on the wish list). I'm much more concerned about getting GHC and Hugs talking to each other.
RE: The Haskell compiler of my dreams...
(1) (I've suggested this before.) Make GHC access interface files more efficiently. If you do top and truss (on a Sun system) you will find that GHC has to read in a huge number of interface files, mainly from the prelude but also from other places, to get going. This is all done just using fopen in a single thread so the whole of GHC is grounded while the disk spins and (if you are using NFS like me) you wait for the network. A quick fix would be to use a Zip archive or something similar; there are not many parts of the source to change. Then you would only have to open one file for the whole of the prelude and believe me that would make a difference. Can I make a counter-suggestion: stop using NFS, or use NFSv3 which does client-side caching. We're reluctant to put a workaround for slow NFS in GHC. We use NFS here (on Linux, which is buggy but not slow), and the time taken to actually slurp the interface files is minimal compared to the rest of the compilation time. This is compiling hello world (which does virtually nothing except slurp and parse interface files) using an NFS-served ghc: real0m0.939s user0m0.890s sys 0m0.050s Now that's far too long, but it's not the interface file reading that's slowing it down. I plan to investigate why the renamer is taking this long. However, I can see the advantage of using a database to store pre-parsed interface files, avoiding unnecessary re-parsing each time. This would probably speed up small compilations a lot: you don't have to slurp through type signatures and optimisation info that you're not interested in. (2) Stop using Make, instead steal SML/NJ's clothes and have your own compilation manager. This solves problem (1) nicely and also means you don't have to read in anything else over and over again. (Like hsc itself.) For programs which consist of lots of small modules, as they should, this would also save lots of time. Actually I think this would also provide much better handling of instance declarations. At the moment instance declarations are only picked up from files which GHC "knows about" via a transitive chain of imports. This has two user-unfriendly consequences; (a) it means that when a .hi file changes, every module which transitively imports (rather than just directly imports) has to be recompiled; (b) it is counter-intuitive. It would be better if all instance declarations in the compilation manager files were automatically known about. I can testify that SML/NJ's compilation manager really works very well and you don't miss the ability to set different compiler options for different files. Using Malcolm Wallace's hmake tool buys you most of this I think, and it works with GHC. It won't save the extra reading of interface files for each compilation, unfortunately. Note that neither of these two suggestions actually do anything for GHC's cpu time. If I run top when GHC is running I rarely find it is using up more than 50% of the available CPU time; most of the time it is waiting on IO. However: (3) Stop using GCC-C as a backend. Instead make the GHC backend a new frontend to GCC. See http://www13.informatik.tu-muenchen.de/forschung/papers/eigene /piz_gic.ps for some explanation and arguments for this approach. Of course there are other obvious approaches. This has been considered (in the distant past). The problem is that gcc's RTL really isn't a nice intermediate language, we'd gain very little except for some compilation speed by going this route, and it would be a tortuous one. A better alternative is to get GHC's native code generator going: it was originally designed to cut compilation time, after all. On x86, the native code generator has a bug or two. Nothing major, but we just haven't got around to fixing it yet. I believe the NCG is close to working on Sparc. I'm sure it's unnecessary to re-code GHC in C to get C-like performance. Surely it would be better to optimise key sections of GHC by the normal tricks of unboxing things and specialising. Have you looked at the source for GHC? We use unboxing all over the place to speed things up. We've used just about all the tools in the box at one time or another. That's not to say that GHC is as fast as it can be, but profiling and tinkering with it take time, and there aren't any "factor of 2" type speedups left to be had. In an optimising compilation, GHC spends about 30% of its time in the simplifier (which is run about 6 times, so that's not surprising), 30% writing the C output (urk! but there's a lot of string manipulation going on here), and the rest spread out among the various opimisations and front-end passes. I'm not suggesting that the GHC implementors actually do any of these suggestions now (though I suppose they could put
Re: Scientific uses of Haskell?
: From: "Rob MacAulay" [EMAIL PROTECTED] : I have long been interested in Computer Algebra systems, and I : admit that one of the things that attracted me to Haskell were the : tantalizing hints that it would be ideal for mathematical : programming. [snip] : Would it also be true to say that FP offers the possibilty of : implementing more mathematically rigorous 'proof' systems as : well? I haven't had the time to find out more about this project. Also I don't know if you know about this yet. If not you may find the following interesting [quote from one of Bruno Buchberger's pages] The development of a new approach to mathematics that integrates "pure" and "algorithmic" mathematics in one common logical and software technological frame and is meant as an alternative to the currently prevailing "Bourbaki" formalization of mathematics. This research combines my past research experience in algorithmic mathematics, foundations of mathematics and computer science, didactics of mathematics, software and algorithm design, see publications since 1994. For more details, see the Theorema project http://www.theorema.org Regards, Marc van Dongen ___ Marc van Dongen, CS Dept | phone: +353 21 903578 University College Cork, NUIC | Fax: +353 21 903113 College Road, Cork, Ireland | Email: [EMAIL PROTECTED]
RE: Programming Win32
Hi, try using getModuleHandle -- see the graphical Win32 "Hello, World" example available via the ghc-win32 homepage, http://www.dcs.gla.ac.uk/~sof/ghc-win32.html It demos how to use it. As you've gathered, there's no separate user doc for the Win32 library. Consult any Win32 programming text (e.g., Petzold) for API details. --sigbjorn -Original Message- From: Axel Simon [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 25, 1999 6:29 AM To: [EMAIL PROTECTED] Subject: Programming Win32 Hi all, I tried to write a Win32 program in with GHC 4.05 but I am stumbeling over the definition type WNDCLASS = (ClassStyle, -- style HINSTANCE, -- hInstance MbHICON, -- hIcon MbHCURSOR, -- hCursor MbHBRUSH,-- hbrBackground MbLPCSTR,-- lpszMenuName ClassName) -- lpszClassName which looks fine if I'd knew where to get hInstance. main doesn't give it to me. Can specify something like winMain hInstance ... = as my main program entry? Or a more sensible question: Is there any userguide on how to use the Win32 library? Cheers, Axel.
