RE: moving from ghc-6.2 to 6.4

2005-03-30 Thread Simon Marlow 
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@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@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
 
 
 
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ghc-6.4 on sparc/solaris

2005-03-30 Thread Ulf Norell 
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
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Size of UArrays

2005-03-30 Thread Andreas Marth 
Hallo!



I would like to know how big an UArray (100,100) Double is (approximately)
in Bytes.

And how much heap will the program consume for it. (I mean does the garbage
collector need this size, or double the size, or what?)



Thanks,

Andreas




___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Size of UArrays

2005-03-30 Thread Tomasz Zielonka 
On Wed, Mar 30, 2005 at 06:41:02PM +0200, Andreas Marth wrote:
 Hallo!
 
 I would like to know how big an UArray (100,100) Double is (approximately)
 in Bytes.

I guess you mean:
(accumArray const 0.0 ((1, 1), (100, 100)) []) :: UArray (Int, Int) Double
It should take about 100 * 100 * 8 = 8 bytes .

 And how much heap will the program consume for it.
 (I mean does the garbage collector need this size, or double the size, or 
 what?)

About the same. I just checked that GHC allocates it as a big object, so
the array isn't copied during GC.

Best regards
Tomasz
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users