Re: GHC compile times (was Re: GHC 6.4.3 is stalled)

2006-07-26 Thread Joel Reymont


On Jul 25, 2006, at 2:57 PM, Simon Marlow wrote:

If you think your build is slow, try building it on Windows  
sometime :-(


Well, I re-built ghc from scratch on my PowerBook G4 1.25Ghz with 1Gb  
of memory. It took somewhere north of 7 hours. The MacBook Pro 2Ghz  
looks speedy by comparison and 3+ hours look like nothing.


--
http://wagerlabs.com/





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


RE: GHC compile times (was Re: GHC 6.4.3 is stalled)

2006-07-26 Thread Simon Marlow
On 26 July 2006 09:41, Joel Reymont wrote:

 On Jul 25, 2006, at 2:57 PM, Simon Marlow wrote:
 
 If you think your build is slow, try building it on Windows
 sometime :-(
 
 Well, I re-built ghc from scratch on my PowerBook G4 1.25Ghz with 1Gb
 of memory. It took somewhere north of 7 hours. The MacBook Pro 2Ghz
 looks speedy by comparison and 3+ hours look like nothing.

That's way too long.  Next time, it might be a good idea to pipe the log
file through something that adds timestamps to each line - I've attached
a little Haskell program I use for this.

Cheers,
Simon


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


Re: GHC compile times (was Re: GHC 6.4.3 is stalled)

2006-07-26 Thread Chris Kuklewicz

Simon Marlow wrote:

On 26 July 2006 09:41, Joel Reymont wrote:


On Jul 25, 2006, at 2:57 PM, Simon Marlow wrote:


If you think your build is slow, try building it on Windows
sometime :-(

Well, I re-built ghc from scratch on my PowerBook G4 1.25Ghz with 1Gb
of memory. It took somewhere north of 7 hours. The MacBook Pro 2Ghz
looks speedy by comparison and 3+ hours look like nothing.


That's way too long.  Next time, it might be a good idea to pipe the log
file through something that adds timestamps to each line - I've attached
a little Haskell program I use for this.

Cheers,
Simon


When I use darwinports on my powerbook 1.33GHz and 2GB of RAM is also takes 
hours and hours and hours.  Next time I will try to get a record of exactly how long


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


Re: GHC compile times (was Re: GHC 6.4.3 is stalled)

2006-07-26 Thread Malcolm Wallace
Joel Reymont [EMAIL PROTECTED] wrote:

 Thanks for the tip! I'm _really_ interested in why it takes 55 min on 
 Linux and 3+ hours on Mac Intel, though. Any clues?

Building a compiler generally reads/touches/creates a very large number
of files.  So one possibility is the relative efficiency of the OS
filesystem implementation.  Apple's HFS+ is reputed to be fairly slow,
as are the Microsoft filesystems (VFAT, NTFS), at least compared to the
various unix-derived filesystems (UFS, ext2 etc).

I recall from a few years back that building nhc98 took twice as long
under Windows as under linux, on the very same machine, with the same
versions of boot-compilers.  The only major variable I could think of
at the time was VFAT vs ext2.

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


Re: GHC compile times (was Re: GHC 6.4.3 is stalled)

2006-07-26 Thread Malcolm Wallace
Joel Reymont [EMAIL PROTECTED] wrote:

 Thanks for the tip! I'm _really_ interested in why it takes 55 min on 
 Linux and 3+ hours on Mac Intel, though. Any clues?

Another thought.  The ghc HACKING guide has this to say:

The GHC build tree is set up so that, by default, it builds a
compiler ready for installing and using.  That means full
optimisation, and the build can take a *long* time.  If you unpack
your source tree and right away say ./configure; make, expect to
have to wait a while.

For hacking, you want the build to be quick - quick to build in the
first place, and quick to rebuild after making changes.  Tuning your
build setup can make the difference between several hours to build
GHC, and less than an hour.  Here's how to do it.

http://cvs.haskell.org/cgi-bin/cvsweb.cgi/~checkout~/fptools/ghc/HACKING?content-type=text%2Fplain

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


Re: Rebuilding GHC on Mac OSX PPC

2006-07-26 Thread Gregory Wright


Hi Joel,

The -threaded flag is set in ghc/compiler/Makefile.  Look around  
line 398, for

SRC_HC_OPTS += -threaded

-Greg

On Jul 26, 2006, at 9:17 AM, Joel Reymont wrote:



On Jul 26, 2006, at 2:06 PM, Gregory Wright wrote:

The crash while building the crypto library was one of the first  
signs

that the threaded RTS had a problem.


My question was whether the CVS version has the flag set. I looked  
through mk/config.mk but could not figure it out quickly so I just  
set off another build of ghc. Should be ready in a few hours :-).


I compiled crypto with ghc 6.5 on Mac Intel and it went through  
fine after some tweaks to cabal dependencies.


--
http://wagerlabs.com/







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


Re: Rebuilding GHC on Mac OSX PPC

2006-07-26 Thread Joel Reymont

This is being set in the CVS version.

On Jul 26, 2006, at 2:49 PM, Gregory Wright wrote:



Hi Joel,

The -threaded flag is set in ghc/compiler/Makefile.  Look around  
line 398, for

SRC_HC_OPTS += -threaded


--
http://wagerlabs.com/





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


Re: Rebuilding GHC on Mac OSX PPC

2006-07-26 Thread Joel Reymont

I'm using ghc 6.4.2 from darwinports to build the CVS version.

There's positively no Cabal directory under fptools.

On Jul 26, 2006, at 2:50 PM, Gregory Wright wrote:



Hi Joel,

Off the top of my head, I can't tell what is the reason for this.   
What compiler are

you using to build ghc 6.4.2?


--
http://wagerlabs.com/





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


Re: Rebuilding GHC on Mac OSX PPC

2006-07-26 Thread Simon Marlow

Joel Reymont wrote:
I'm building ghc 6.4.2 from CVS on Mac PPC and get the error below.  Any 
clues?


==fptools== make boot - --no-print-directory -r;
in /Users/zomariya/Work/fptools/ghc/lib/compat

../../../glafp-utils/mkdependC/mkdependC -f .depend-I. -Iinclude - 
I../../includes  -- -O -I. -Iinclude-- cbits/directory.c cbits/ 
rawSystem.c
/opt/local/bin/ghc -M -optdep-f -optdep.depend  -osuf o -optdep-- 
exclude-module=System.Directory.Internals   -H16m -O -I. -Iinclude - 
Rghc-timing -ignore-package Cabal -I../../../libraries -fglasgow-exts  
-no-recomp Compat/Directory.hs Compat/RawSystem.hs Distribution/ 
Compat/FilePath.hs Distribution/Compat/ReadP.hs Distribution/ 
Compiler.hs Distribution/GetOpt.hs Distribution/ InstalledPackageInfo.hs 
Distribution/License.hs Distribution/ Package.hs 
Distribution/ParseUtils.hs Distribution/Version.hs  
Language/Haskell/Extension.hs
Distribution/Compat/FilePath.hs:2: error: Cabal/Distribution/Compat/ 
FilePath.hs: No such file or directory
ghc: 14349576 bytes, 3 GCs, 9/9 avg/max bytes residency (1  
samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.06 MUT (0.22  
elapsed), 0.02 GC (0.04 elapsed) :ghc

make[3]: *** [depend] Error 1
make[2]: *** [boot] Error 1
make[1]: *** [boot] Error 1
make: *** [build] Error 1


ghc/lib/compat/Distribution/Compat/FilePath.hs #include's 
Cabal/Distribution/Compat/FilePath.hs, which it is supposed to find by virtue of 
the -I../../../libraries arg passed to ghc.


So does Cabal/Distribution/Compat/FilePath.hs exist relative to libraries in 
your tree?


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


Re: Rebuilding GHC on Mac OSX PPC

2006-07-26 Thread Joel Reymont


On Jul 26, 2006, at 3:20 PM, Simon Marlow wrote:

ghc/lib/compat/Distribution/Compat/FilePath.hs #include's Cabal/ 
Distribution/Compat/FilePath.hs, which it is supposed to find by  
virtue of the -I../../../libraries arg passed to ghc.


So does Cabal/Distribution/Compat/FilePath.hs exist relative to  
libraries in your tree?


Nope. Nowhere under fptools. I forgot to checkout libraries. Anything  
else I need? hslibs?


--
http://wagerlabs.com/





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


Re: Rebuilding GHC on Mac OSX PPC

2006-07-26 Thread Joel Reymont

Foot in mouth. Gotta read the manual (README).

On Jul 26, 2006, at 3:20 PM, Simon Marlow wrote:

So does Cabal/Distribution/Compat/FilePath.hs exist relative to  
libraries in your tree?


--
http://wagerlabs.com/





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


Re: Building NewBinary with ghc 6.5

2006-07-26 Thread Jeremy Shaw
Hrm,

Odd. The cabal code looks like it should be outputting the
command-line that it uses to invoke ghc-pkg, but it does not work here
either. Perhaps that is a cabal bug.

In any case, I think it is just running:

 ghc-pkg update .installed-pkg-config

If you run that command, does it generate the same error ? Can you
paste the contents of your .installed-pkg-config?

Thanks.
j.

At Wed, 26 Jul 2006 01:07:54 +0100,
Joel Reymont wrote:
 
 Close but no cigar!
 
 sudo runhaskell Setup.lhs install -v5
 directory dist/doc/html does exist: False
 Installing: /usr/local/lib/NewBinary-0.1/ghc-6.5  /usr/local/bin  
 NewBinary-0.1...
 copy dist/build/NewBinary/FastMutInt.hi to /usr/local/lib/ 
 NewBinary-0.1/ghc-6.5/NewBinary/FastMutInt.hi
 copy dist/build/NewBinary/Binary.hi to /usr/local/lib/NewBinary-0.1/ 
 ghc-6.5/NewBinary/Binary.hi
 copy dist/build/libHSNewBinary-0.1.a to /usr/local/lib/NewBinary-0.1/ 
 ghc-6.5/libHSNewBinary-0.1.a
 copy dist/build/HSNewBinary-0.1.o to /usr/local/lib/NewBinary-0.1/ 
 ghc-6.5/HSNewBinary-0.1.o
 /usr/bin/ranlib /usr/local/lib/NewBinary-0.1/ghc-6.5/ 
 libHSNewBinary-0.1.a
 Registering NewBinary-0.1...
 Reading package info from .installed-pkg-config ... done.
 ghc-pkg: invalid package identifier:
 
 It's not showing me the ghc-pkg that's being invoked.
 
 On Jul 26, 2006, at 12:56 AM, Jeremy Shaw wrote:
 
  At Wed, 26 Jul 2006 00:40:33 +0100,
  Joel Reymont wrote:
 
  Is there something that looks particularly wrong below?
 
  Can you try the install with verbosity turned up:
 
 $ sudo runhaskell Setup.lhs install -v
 
  or perhaps even
 
 $ sudo runhaskell Setup.lhs install -v5
 
  I believe this will show the actually invocation of ghc-pkg that is
  being used. You can then try running ghc-pkg by hand and see if it
  gives you the same result.
 
  That should at least yield some useful data.
 
  Thanks.
  j.
 
 --
 http://wagerlabs.com/
 
 
 
 
 
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: GHC compile times (was Re: GHC 6.4.3 is stalled)

2006-07-26 Thread John Meacham
On Wed, Jul 26, 2006 at 11:54:37AM +0100, Malcolm Wallace wrote:
 For hacking, you want the build to be quick - quick to build in the
 first place, and quick to rebuild after making changes.  Tuning your
 build setup can make the difference between several hours to build
 GHC, and less than an hour.  Here's how to do it.

This reminds me of something. I ofter use {-# NOINLINE ... #-} with ghc
combined with frugal export lists in order to speed up the rebuild
process when I know something is not going to benefit from being inlined
or temporarily when I am making lots of internal changes to a file and
want the rebuilds to go as fast as possible.

However, whenever I change a data type or class even if they are not
exported, it seems to force a full rebuild of everything that depends on
that file. Is there any fundamental reason this can't be fixed? why do
the non exported classes and data types end up in the hi file anyway
(assuming they appear in no exported functions type signature of course)

perhaps there could be a mode that means optimize, but do so in a way
that minimized the need to rebuild anything, so it will do optimization
and inlining within a module, but will avoid anything that changes the
external interface in a way that will cause dependencies to need to be
rebuilt.

John

-- 
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users