- Glasgow-haskell-users

RE: moving from ghc-6.2 to 6.4
by Simon Marlow 30 Mar '05

30 Mar '05

On 29 March 2005 08:59, Johannes Waldmann wrote: > I am trying to bring a larger heap of code > (http://141.57.11.163/auto/ ) into 6.4 land (because of wonder > stories about faster compilation, faster execution, Data.Map, and so > on ...) > Here are a few observations and questions > that may be useful to others as well. > > * what is the situation with ghc-6.4 for sparc/solaris? > I don't see a binary package in the download area. > I started to build from source - can this be successful? > > (The rest of this report refers to i386/linux) There are some outstanding issues on Sparc/Solaris that I didn't get around to investigating before the release. One of them is a random crash, so you should probably consider 6.4 to be broken on Sparc/Solaris for the time being (it might be related to gcc version though: 6.2.x might be just as broken with recent gcc versions). I'm keen to get more data points, if you have the time & inclination to test it. We could really do with a Sparc/GHC guru to take up the mantle of maintaining the Sparc port - it's kind of hard for us to do it without the hardware locally, and I'm no Sparc expert. > * Cabal is very nice! - The only thing that was confusing me > is that I have to list all modules in the *.cabal file: > if I don't, it still happily builds and installs the package > but it cannot be used, giving linker errors. Couldn't this be > checked earlier? Or better, couldn't it infer the needed > hidden modules? Anyway I can generate the module list by a shell > script but that does not feel right. - How do I build and install > a profiling version of a package, how does Cabal support this? The module list: yes, I think this is something the Cabal team would like to automate in the future. There's no way to build profiled packages at the moment, as far as I'm aware. I agree it's an important feature, though. > * I don't see "dramatic" improvements in execution times - > are there some magic ghc options I missed? I used -O -fvia-C. > Still, executables are maybe 2 .. 5 % smaller and faster than they > were with 6.2 - and compilation without -O is really fast. I don't know where this rumour of dramatic improvements in execution time comes from :-) Our testing shows modest improvements in most programs, with some programs going slower. The focus of 6.4 wasn't really on performance, but we hope to merge performance improvements back into future 6.4 releases. Cheers, Simon

4 3

RE: moving from ghc-6.2 to 6.4
by Simon Marlow 30 Mar '05

30 Mar '05

On 29 March 2005 17:56, Keean Schupke wrote: > Thought I would run some benchmarks with different compiler options, > so I pulled out some code (that compiled fine with 6.2). The code uses > MArrays to calculate a tree difference between two different XML > files. Anyway tying to compile with 6.4 I get: > > >ghc-6.3: panic! (the `impossible' happened, GHC version 6.3): > > app_match: unbound tpl s{tv a2M9} > > > >Please report it as a compiler bug to > glasgow-haskell-bugs(a)haskell.org, > > Any idea how to track down the cause of this? The error message claims to be from GHC 6.3, perhaps you're using a pre-6.4 snapshot? Could you try with the released 6.4 and let us know if it still happens? Cheers, Simon > Keean. > > Simon Marlow wrote: > >> On 29 March 2005 08:59, Johannes Waldmann wrote: >> >> >> >>> I am trying to bring a larger heap of code >>> (http://141.57.11.163/auto/ ) into 6.4 land (because of wonder >>> stories about faster compilation, faster execution, Data.Map, and >>> so on ...) Here are a few observations and questions >>> that may be useful to others as well. >>> >>> * what is the situation with ghc-6.4 for sparc/solaris? >>> I don't see a binary package in the download area. >>> I started to build from source - can this be successful? >>> >>> (The rest of this report refers to i386/linux) >>> >>> >> >> There are some outstanding issues on Sparc/Solaris that I didn't get >> around to investigating before the release. One of them is a random >> crash, so you should probably consider 6.4 to be broken on >> Sparc/Solaris for the time being (it might be related to gcc version >> though: 6.2.x might be just as broken with recent gcc versions). >> I'm keen to get more data points, if you have the time & inclination >> to test it. >> >> We could really do with a Sparc/GHC guru to take up the mantle of >> maintaining the Sparc port - it's kind of hard for us to do it >> without the hardware locally, and I'm no Sparc expert. >> >> >> >>> * Cabal is very nice! - The only thing that was confusing me >>> is that I have to list all modules in the *.cabal file: >>> if I don't, it still happily builds and installs the package >>> but it cannot be used, giving linker errors. Couldn't this be >>> checked earlier? Or better, couldn't it infer the needed >>> hidden modules? Anyway I can generate the module list by a shell >>> script but that does not feel right. - How do I build and install >>> a profiling version of a package, how does Cabal support this? >>> >>> >> >> The module list: yes, I think this is something the Cabal team would >> like to automate in the future. There's no way to build profiled >> packages at the moment, as far as I'm aware. I agree it's an >> important feature, though. >> >> >> >>> * I don't see "dramatic" improvements in execution times - >>> are there some magic ghc options I missed? I used -O -fvia-C. >>> Still, executables are maybe 2 .. 5 % smaller and faster than they >>> were with 6.2 - and compilation without -O is really fast. >>> >>> >> >> I don't know where this rumour of dramatic improvements in execution >> time comes from :-) Our testing shows modest improvements in most >> programs, with some programs going slower. The focus of 6.4 wasn't >> really on performance, but we hope to merge performance improvements >> back into future 6.4 releases. >> >> Cheers, >> Simon >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: Kind of StableName
by Simon Marlow 29 Mar '05

29 Mar '05

On 28 March 2005 11:25, Nicolas Oury wrote: > I try to use StableNames for hash consing on complex types - I have to > mix in a same table StableNames of different types - and I wonder why > StableName is of kind * -> * and not *. I think we gave StableName the extra type parameter to help with type safety. But I can't think of a convincing example right now... anyway, it would be quite easy to build an alternative StableName implementation without the type parameter. Take a look at the source code for System.Mem.StableName, it's quite short. Cheers, Simon

1 0

RE: Biographical Profiling
by Simon Marlow 29 Mar '05

29 Mar '05

On 25 March 2005 15:59, Andreas Marth wrote: > The ghc user guide says that there are 4 states a heap object may be > in. Unfortunately in my program there are 5 states (inherent_use, > use, drag, lag, void) with inherent_use being the biggest part (many > MBs) and the one not mentioned in the users guide. > My question is what does it mean? What can I do to get rid of it? IIRC, inherently used closures are primitive objects that we don't record use-stamps on. This includes things like the stack (part of a primitive thread object), arrays, MVars, and IORefs. Cheers, Simon

1 0

RE: [Haskell] Haskell 6.4 perfomance
by Simon Marlow 29 Mar '05

29 Mar '05

GHC 6.4 uses C-- as an intermediate language, it doesn't compile via C-- (yet). A full C-- backend has the potential to generate faster code that going via GCC, because C-- would have control over the stack and the calling convention. In my experience, extra optimisation flags for gcc make very little difference for GHC-compiled code, and may even make things worse. By all means do some benchmarks, though! Cheers, Simon On 25 March 2005 08:19, Alexandre wrote: > Keean, thank you. > > Does any tests/benchmarks available? > > Regards, > /Alexandre. > > > On Mar 25, 2005, at 00:47, Keean Schupke wrote: > >> Think this should really go to glasgow-haskell-users... >> >> If this is true - how do I get ghc to use C--, and is it really >> faster than using gcc as a backend with all the bells & whistles >> turned on (for a pentium-III) something like >> >> "-O3 -mcpu=pentium3 -march=pentium3 -pipe -fomit-frame-pointer >> -momit-leaf-frame-pointer -ftracer -fno-crossjumping -mfpmath=sse,387 >> -ffast-math -fsched-spec-load -fprefetch-loop-arrays >> -maccumulate-outgoing-args -fmove-all-movables >> -freduce-all-givs" >> >> Keean. >> >> Alexandre wrote: >> >>> As I heard, 6.4 version of the Haskell using C-- backend and make >>> lots of the resulting code perfomance (programs executed faster). >>> If so, does any test/comparison with other languages available? >>> >>> Thank you in advance, >>> Regards, >>> /Alexandre. >>> >> _______________________________________________ >> Haskell mailing list >> Haskell(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell >> > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

moving from ghc-6.2 to 6.4
by Johannes Waldmann 28 Mar '05

28 Mar '05

I am trying to bring a larger heap of code (http://141.57.11.163/auto/ ) into 6.4 land (because of wonder stories about faster compilation, faster execution, Data.Map, and so on ...) Here are a few observations and questions that may be useful to others as well. * what is the situation with ghc-6.4 for sparc/solaris? I don't see a binary package in the download area. I started to build from source - can this be successful? (The rest of this report refers to i386/linux) * Cabal is very nice! - The only thing that was confusing me is that I have to list all modules in the *.cabal file: if I don't, it still happily builds and installs the package but it cannot be used, giving linker errors. Couldn't this be checked earlier? Or better, couldn't it infer the needed hidden modules? Anyway I can generate the module list by a shell script but that does not feel right. - How do I build and install a profiling version of a package, how does Cabal support this? * (when building HSQL-1.4) CTime is no longer an instance of Integral, so I replaced fromIntegral by fromIntegral . fromEnum, is this OK? * the name of mkAppTy changed to mkTyConApp (I hope it's only the name that changed) * I don't see "dramatic" improvements in execution times - are there some magic ghc options I missed? I used -O -fvia-C. Still, executables are maybe 2 .. 5 % smaller and faster than they were with 6.2 - and compilation without -O is really fast. Best regards, and thanks to the GHC team. -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------

1 0

Kind of StableName
by Nicolas Oury 28 Mar '05

28 Mar '05

Hello, I try to use StableNames for hash consing on complex types - I have to mix in a same table StableNames of different types - and I wonder why StableName is of kind * -> * and not *. Best regards, Nicolas Oury

1 0

static linking with ghc
by Patrick Scheibe 27 Mar '05

27 Mar '05

Hi, I have a programm which is linked against some shared object libraries. Now I want to run my prog on a different machine (but same type, x86 linux). So I took the compiled prog and the needed .so files, put both in one directory and tried it on the other machine. That worked fine. Is it possible to tell ghc to take all stuff out of the .so libs and compile my source to a "all-including" executable? I know that ghc just calls the linker which is doing this part. The --static flag for the linker just says: "take the static library if possible for linking...". But I don't have a static version of these libs and I don't want to recompile all libraries. Am I totally wrong? Is this possible in general? Are there some good papers except of the "man ld"?? Cheers Patrick

2 1

Biographical Profiling
by Andreas Marth 25 Mar '05

25 Mar '05

Hallo! The ghc user guide says that there are 4 states a heap object may be in. Unfortunately in my program there are 5 states (inherent_use, use, drag, lag, void) with inherent_use being the biggest part (many MBs) and the one not mentioned in the users guide. My question is what does it mean? What can I do to get rid of it? Thanks, Andreas

1 0

Problem starting GHC 6.4 on windows 98
by J L Russell 25 Mar '05

25 Mar '05

When trying to run GHC 6.4 (from the installer) on Windows 98, I get the following error message: "The GHC.EXE file is linked to missing export SHELL32.DLL:SHGetFolderPathA" >From what I've been able to determine, on Windows version prior to Windows 2000, this function was instead exported from shfolder.dll, which is retained in later versions of Windows for backward compatibility, and on newer version of Windows, simply calls the version in shell32.dll. So it looks to me like GHC 6.4 from the installer won't be able to run on Windows 98 unless the executable in the installer is updated to link this function from shfolder.dll instead. -James

3 2