On Sun, Aug 12, 2007 at 02:43:20PM -0700, Stefan O'Rear wrote:
> On Sun, Aug 12, 2007 at 09:00:34PM +0100, Ian Lynagh wrote:
> > On Sun, Aug 12, 2007 at 08:37:44PM +0100, Simon Marlow wrote:
> > >
> > > Aargh! That's the data from ghc-inplace, not ghc itself. Since
> > > ghc-inplace became a Ha
On Sun, Aug 12, 2007 at 09:00:34PM +0100, Ian Lynagh wrote:
> On Sun, Aug 12, 2007 at 08:37:44PM +0100, Simon Marlow wrote:
> >
> > Aargh! That's the data from ghc-inplace, not ghc itself. Since
> > ghc-inplace became a Haskell program, it's harder to get it to recognise
> > +RTS options. Sup
Simon Marlow wrote:
../../compiler/stage2/ghc-6.7.20070812 -B../.. +RTS -sstderr
i.e. bypass ghc-inplace and run the ghc binary directly, passing the
appropriate -B flag.
BTW. is -B still undocumented in the user's guide? Of course it's not
obvious that it should be, but still.
Okay, th
On Sun, Aug 12, 2007 at 08:37:44PM +0100, Simon Marlow wrote:
>
> Aargh! That's the data from ghc-inplace, not ghc itself. Since
> ghc-inplace became a Haskell program, it's harder to get it to recognise
> +RTS options. Supposedly ghc-inplace passes the +RTS options through to
> ghc itself,
Isaac Dupree wrote:
Second includes FastString and FiniteMap changes above the first (that's
what builds I have convenient now)... and I'm just using the stage1,
which will certainly have some effect on the results (similar effect on
both)
first:
40,328 bytes allocated in the heap
Isaac Dupree wrote:
Second includes FastString and FiniteMap changes above the first (that's
what builds I have convenient now)... and I'm just using the stage1,
which will certainly have some effect on the results (similar effect on
both)
first:
40,328 bytes allocated in the heap
1
On Sat, Aug 11, 2007 at 06:43:18PM -0300, Isaac Dupree wrote:
> Of course I can test other patch combinations at approximately 15 minutes
> each (to rebuild GHC+libs... maybe that can be shortened by taking some
> shortcuts. Certainly if the changes aren't supposed to change ghc's
> behavior _at
BTW, I wish I could put my performance test results in the patch
descriptions, but I generally record the patches before testing them so
that I can easily test just those patches, combine, whatever darcs lets
me do. Maybe I should re-record them I don't like doing that
though, and amend-re
Simon Marlow wrote:
This is certainly a useful test, but I use a slightly different method
to check for performance regressions when I'm trying small modifications
to the compiler. This isn't as foolproof, but in some ways it's more
sensitive and it's deterministic.
Okay, allocations are a r
Isaac Dupree wrote:
The procedure I am about to describe, should make me notice serious
performance regressions in the compiled stage1. Also it tells me when
my patches don't break validate any *more* than an unpatched HEAD
(***which is true currently, that validate is slightly broken for me
I can't comment about the build process (others will) but if you find
performance regressions please do report them as precisely as possible when you
have them nailed down, so we can reproduce them.
Thanks
S
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
| On
11 matches
Mail list logo
