- Glasgow-haskell-users

RE: Performance week 25/6-29/6
by Simon Marlow 01 Aug '05

01 Aug '05

[ duh, hit send by mistake, that's twice today :-( ] Ok, we made some progress on performance last week, but there's still plenty to do. Here's a summary: - Simon PJ found an O(n^2) case in the simplifier that appears to be the cause of most, if not all, of the cases of GHC going out to lunch when compiling certain modules. However, while testing the fix we discovered that it caused worse code to be generated for some programs, so we're still looking into this. - I added a hack in GHC's back end to do some lightweight buffering of the output, which results in about a 10% speedup in compilation time. The C output was also using the full pretty printer, when it doesn't really need to do indentation. - I tweaked the garbage collector in a few places, to get some modest speedup. - A nasty space leak in the native code generator was found & fixed. The space usage of GHC in general remains worse than we'd like. - A few other minor optimisations were made in the compiler. We plan to put the simplifier fix into 6.4.1, and the NCG space-leak fix is already in. The other fixes are a little too intrusive with 6.4.1 being so close, so we'll hold off on those (possibly for 6.4.2). Cheers, Simon

1 0

RE: Performance week 25/6-29/6
by Simon Marlow 01 Aug '05

01 Aug '05

Ok, we made some progress on performance last week, but there's still plenty to do. Here's a summary: - Simon PJ found an O(n^2) case in the simplifier that appears to be the cause of most, if not all, of the cases of GHC going out to lunch when compiling certain modules. However, while testing the fix we discovered that it caused worse code to be generated for some programs, so we're still looking into this. - I added a hack in GHC's back end to do some lightweight buffering of the

1 0

RE: Re[2]: C--
by Simon Marlow 01 Aug '05

01 Aug '05

On 01 August 2005 14:25, Bulat Ziganshin wrote: > Monday, August 01, 2005, 4:13:16 PM, you wrote: > >> On 31 July 2005 08:10, Bulat Ziganshin wrote: > >>> can you please say about value of using C-- in GHC? will this > >> It should reduce compile time compared to compiling via C, though I >> It should improve the speed of compiled programs, because C-- will be > > great. and when this will be implemented? I'll let those who are implementing it answer that :-) Cheers, Simon

1 0

RE: C--
by Simon Marlow 01 Aug '05

01 Aug '05

On 31 July 2005 08:10, Bulat Ziganshin wrote: > can you please say about value of using C-- in GHC? will this > reduce compile time, increase speed of compiled programs, improve > portability or make some other effect? would the C-- compile path > replace asm or C path? It should reduce compile time compared to compiling via C, though I suspect it will still be slower than using GHC's built-in native code generator. It should improve the speed of compiled programs, because C-- will be using its own, efficient, calling convention. For example, this will mean that some arguments can be passed in registers on x86, which we can't do currently because of a combination of the lack of registers and limitations in what we can convince gcc to do. It should improve portability, because there is less work in GHC required to compile via C-- on a new platform: no mangler to modify, for example. Eventually, we hope the registerised via-C path would become redundant. The unregisterised path is still useful for bootstrapping, given that more platforms have a C compiler than a C-- compiler (if C-- were to become ubiquitous, the unregisterised path would become irrelevant too). Cheers, Simon

2 1

C--
by Bulat Ziganshin 31 Jul '05

31 Jul '05

Hello glasgow-haskell-users, can you please say about value of using C-- in GHC? will this reduce compile time, increase speed of compiled programs, improve portability or make some other effect? would the C-- compile path replace asm or C path? -- Best regards, Bulat mailto:bulatz@HotPOP.com

1 0

Inferred type is less polymorphic than expected?
by Benjamin Franksen 30 Jul '05

30 Jul '05

Hi, I get an error message when I compile the following program with ghc-6.4: \begin{code} class Catalog c where traverse :: c -> Viewer -> IO () instance Catalog Int where traverse i v = viewShowable v i type View a = a -> IO () data Viewer = Viewer { viewShowable :: forall s. Show s => View s, viewCatalog :: forall c. Catalog c => View c } printer :: Viewer --printer = Viewer { -- viewCatalog = \x -> traverse x printer, -- viewShowable = putStrLn . show } printer = Viewer { viewCatalog = printCatalog, viewShowable = putStrLn . show } printCatalog :: forall c. Catalog c => View c printCatalog x = traverse x printer data X = X { cat :: Int } instance Catalog X where traverse x v = do viewCatalog v (cat x) main = do let x = X { cat = 20 } traverse x printer \end{code} This is a stripped-down version of my actual code, BTW. The exact mesage is: ~> ghc -fallow-undecidable-instances -fglasgow-exts Bug.lhs Bug.lhs:23:10: Inferred type is less polymorphic than expected Quantified type variable `c' is mentioned in the environment: printCatalog :: c -> IO () (bound at Bug.lhs:28:0) In the `viewCatalog' field of a record In the record construction: Viewer {viewCatalog = printCatalog, viewShowable = putStrLn . show} In the definition of `printer': printer = Viewer {viewCatalog = printCatalog, viewShowable = putStrLn . show} Bug.lhs:27:0: Contexts differ in length When matching the contexts of the signatures for printer :: Viewer printCatalog :: forall c. (Catalog c) => View c The signature contexts in a mutually recursive group should all be identical The code compiles and works fine if the definition of 'printer' is replaced by the out-commented version, that is, if a lambda expression is used that is identical to the definition of 'printCatalog'. BTW, this does not happen with hugs. It looks like a bug to me, but since I use some non-standard features, maybe there is some subtle explanation for this behavior. Ben

2 5

Installation problem
by Dieter 30 Jul '05

30 Jul '05

Hi, I'm using Linux 9.3 on a PC with a 64-architecture. I'd like to install GHC and thought the easiest way would be to take an appropriate rpm-file.So I downloaded an rpm file, it was said to running with SUSE 9.2 without problems. But when starting rpm -i ghc.-6.4-1.i386.rpm I got the message: error: Failed dependencies: libgmp.so.3 is needed by ghc-6.4-1 But it is installed on my systems. I downloaded it again and installed it again and copied it (3 files: - the symlink libgmp.so, the symlink libgmp.so.3 and the file the libgmp.so.3.3.3) into several lib directories. NO SUCCESS What is wrong? Has anyone an idea? Thank you Dieter

1 0

Bug in placing _stub.o files with HEAD
by Einar Karttunen 30 Jul '05

30 Jul '05

Hello I noticed the following behaviour using GHC 6.5.20050728: If compiling a Cabal package containing hs-source-dirs it places the _stub.o under dist/build/<source-dir>/path/to/Module when Cabal expects it in dist/build/path/to/Module. Things appear to work without hs-source-dirs. For example with "hs-source-dirs: src" Network/GnuTLS/IOWrap.hs contains foreign export declarations. runnning Setup build creates the files: dist/build/src/Network/GnuTLS/IOWrap_stub.o src/Network/GnuTLS/IOWrap_stub.h src/Network/GnuTLS/IOWrap_stub.c But Cabal fails to include the IOWrap_stub.o as it is expected as dist/build/Network/GnuTLS/IOWrap_stub.o - Einar Karttunen

1 0

RE: more on GHC 6.4 Debian packages
by Simon Marlow 29 Jul '05

29 Jul '05

On 28 July 2005 22:42, Ian Lynagh wrote: > However, the timeout program tickles known bugs in Linux 2.4 on hppa > (and possibly unknown bugs on ia64, as discussed briefly on ghc-cvs). I'd still like to get your souped-up timeout program into CVS. Would you like to post it? Cheers, Simon

2 1

RE: -split-objs and --make together?
by Simon Marlow 29 Jul '05

29 Jul '05

On 29 July 2005 05:10, Dimitry Golubovsky wrote: > Is it possible to use --make when one or more of modules involved are > split? Not right now, but it's on the ToDo list. Cheers, Simon

1 0