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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Joachim Breitner-2
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
  [hidden email]
  http://www.joachim-breitner.de/

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Ben Gamari-2
On November 11, 2017 10:03:37 PM EST, Joachim Breitner <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

Joachim Breitner-2
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
  [hidden email]
  http://www.joachim-breitner.de/

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Manuel M T Chakravarty-4
In reply to this post by Ben Gamari-2
Ben Gamari <[hidden email]>:

On November 11, 2017 10:03:37 PM EST, Joachim Breitner <[hidden email]> 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.

Hmm, on what grounds does he think that this is going to disappear and how likely is likely? This doesn’t sound convincing TBH.

Cheers,
Manuel


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

Ben Gamari-2
Manuel M T Chakravarty <[hidden email]> writes:

>> 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.
>
> Hmm, on what grounds does he think that this is going to disappear and how likely is likely? This doesn’t sound convincing TBH.
>
As Alan has pointed out elsewhere, currently the TTG involves some
unnecessarily large constraints which very likely inflate typechecking
time. This is almost certainly why we are seeing such increases in
compilation time of the compiler (and, as importantly, no changes in the
performance characteristics of the resulting compiler).

Given how consistent the story seems to be, a reduction after the
constraints are simplified sounds very likely.

Cheers,
- Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment