Re: [commit: ghc] master: WIP on combined Step 1 and 3 for Trees That Grow, HsExpr (e3ec2e7)

[Joachim Breitner]

Hi,


> A 15% regression in the compilation time of GHC is indeed hard to stomach but 
> Alan had said that much of this will likely disappear in the future.

great, that’s all I wanted to hear :-)

Joachim
-- 
Joachim Breitner
  m...@joachim-breitner.de
  http://www.joachim-breitner.de/


signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [commit: ghc] master: WIP on combined Step 1 and 3 for Trees That Grow, HsExpr (e3ec2e7)

[Ben Gamari]

On November 11, 2017 10:03:37 PM EST, Joachim Breitner 
 wrote:
>Hi Alan,
>
>the combined effect of 
>
>commit e3ec2e7ae94524ebd111963faf34b84d942265b4
>WIP on combined Step 1 and 3 for Trees That Grow, HsExpr
>
>
>and 
>
>commit 438dd1cbba13d35f3452b4dcef3f94ce9a216905
>WIP on Doing a combined Step 1 and 3 for Trees That Grow
>
>
>causes a 15% regression in the time it takes to build GHC, according to
>https://perf.haskell.org/ghc/#compare/fe6848f544c2a14086bcef388c46f4070c22d287/e3ec2e7ae94524ebd111963faf34b84d942265b4
>
>
>Is that a known, expected and accepted regression?
>
>Joachim

I noted this on D4177 and discussed the effect with Alan. Indeed there is quite 
a sizeable regression in compilation time but thankfully this is not because 
GHC itself is slower. Rather, it simply requires more work to compile. I did a 
set of nofib runs with and without the first TTG patch and found that compiler 
allocations remained essentially unchanged.

A 15% regression in the compilation time of GHC is indeed hard to stomach but 
Alan had said that much of this will likely disappear in the future. If this is 
the case then a temporary regression is in my opinion acceptable.

Cheers,

- Ben 
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [commit: ghc] master: WIP on combined Step 1 and 3 for Trees That Grow, HsExpr (e3ec2e7)

[Joachim Breitner]

Hi Alan,

the combined effect of 

commit e3ec2e7ae94524ebd111963faf34b84d942265b4
WIP on combined Step 1 and 3 for Trees That Grow, HsExpr


and 

commit 438dd1cbba13d35f3452b4dcef3f94ce9a216905
WIP on Doing a combined Step 1 and 3 for Trees That Grow


causes a 15% regression in the time it takes to build GHC, according to
https://perf.haskell.org/ghc/#compare/fe6848f544c2a14086bcef388c46f4070c22d287/e3ec2e7ae94524ebd111963faf34b84d942265b4


Is that a known, expected and accepted regression?

Joachim

-- 
Joachim Breitner
  m...@joachim-breitner.de
  http://www.joachim-breitner.de/


signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Asserting vars with different Uniques represent the same Object

[Ben Gamari]

Andreas Klebinger  writes:

> My core questions are:
>
> * Should variables representing the same thing always have the same unique?
> * If not how can one assert they actually represent the same thing?
>
> Working on the pattern matching code I came across this assertion:
>
>  > ASSERT(tvs1 `equalLength` ex_tvs )
> http://git.haskell.org/ghc.git/blob/HEAD:/compiler/deSugar/MatchCon.hs#l125
>
> tvs1 and ex_tvs are both the existentially quantified type variables
> of a pattern. One gained by taking apart the pattern itself and one by
> taking apart the ConLike in the pattern.
>
Could you elaborate a bit more here? This sounds like a bug but I'm not
sure I completely follow how you came about these tyvars.

> Follow up question:
> The whole assert is essentially a unit test as ex_tvs isn't used outside 
> of the assert.
> Is there a solution to check these invariants in tests instead of the 
> source code?

If I understand the question correctly: no. GHC contains hundreds of
assertions like this which are only enabled when the compiler is
compiled with -DDEBUG. The advantage of including them in the source
instead of an external test is that it keeps the invariant check right
next to the implementation, where it belonds.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Asserting vars with different Uniques represent the same Object

[Andreas Klebinger]

My core questions are:

* Should variables representing the same thing always have the same unique?
* If not how can one assert they actually represent the same thing?

Working on the pattern matching code I came across this assertion:

> ASSERT(tvs1 `equalLength` ex_tvs )
http://git.haskell.org/ghc.git/blob/HEAD:/compiler/deSugar/MatchCon.hs#l125

tvs1 and ex_tvs are both the existentially quantified type variables of 
a pattern.
One gained by taking apart the pattern itself and one by taking apart 
the ConLike in the pattern.


While as far as I can tell they always represent the same Types they 
don't always compare as equal.
Is there any other stable way to compare them? (By name? Something 
else?). Or is them not being

equal a bug to begin with.

Follow up question:
The whole assert is essentially a unit test as ex_tvs isn't used outside 
of the assert.
Is there a solution to check these invariants in tests instead of the 
source code?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs