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
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@haskell.org,
Any idea how to track down the cause of this? 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@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Simon Marlow wrote:
There are some outstanding issues on Sparc/Solaris ...
the build process seemed to complete, last commands were echo '#!/bin/sh' >>stage2/ghc-inplace echo exec /home/waldmann/software/ghc-6.4/ghc/compiler/stage2/ghc-6.4 '-B/home/waldmann/software/ghc-6.4' '"$@"' >>stage2/ghc-inplace chmod 755 stage2/ghc-inplace gmake[2]: Leaving directory `/home/waldmann/software/ghc-6.4/ghc/compiler' gmake[1]: Leaving directory `/home/waldmann/software/ghc-6.4' but during this compilation (of the bootstrapped compiler), for each file there is a message Warning: retaining unknown function `getpwuid_r' in output from C compiler Warning: retaining unknown function `getpwnam_r' in output from C compiler Warning: retaining unknown function `getgrgid_r' in output from C compiler Warning: retaining unknown function `getgrnam_r' in output from C compiler Then, when I build my application's library (via runhaskell Setup.hs build), it compiles a lot of files (with the above warning for each of them) but finally dies with Compiling Autolib.Boxing.Position ( ./Autolib/Boxing/Position.hs, dist/build/./Autolib/Boxing/Position.o ) *** Exception: waitForProcess: interrupted (Interrupted system call) this being a repeatable error. (I checked that it can compile simple "Hello World" programs - no problems.) (ah yes, I am using gcc-2.95.2, and uname -a = SunOS aaron 5.8 Generic_108528-15 sun4u sparc ) -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
Johannes Waldmann wrote:
Simon Marlow wrote:
There are some outstanding issues on Sparc/Solaris ...
Warning: retaining unknown function `getpwuid_r' in output from C compiler Warning: retaining unknown function `getpwnam_r' in output from C compiler Warning: retaining unknown function `getgrgid_r' in output from C compiler Warning: retaining unknown function `getgrnam_r' in output from C compiler
I get the same warnings. I also get a bus error when I try to use QuickCheck. It works fine in ghci or if I copy the QuickCheck module and compile it with the program, but if I use the library one I get the bus error. I haven't checked if it's only the QuickCheck package that's broken.
*** Exception: waitForProcess: interrupted (Interrupted system call)
This I haven't seen, though. gcc-2.95.3 SunOS 5.9 Generic_117171-11 sun4u sparc SUNW,Sun-Fire-280R / Ulf
participants (4)
-
Johannes Waldmann -
Keean Schupke -
Simon Marlow -
Ulf Norell