Re: Pattern matching desugaring regression? Re: [Haskell-cafe] Why does my module take so long to compile?
They already said something about waiting on dependencies to catch up with
ghc9, IIRC.
On Mon, Feb 15, 2021 at 2:22 PM Carter Schonwald
wrote:
> Don’t forget ghc 9 is already out! :)
>
> On Mon, Feb 15, 2021 at 2:10 PM Troels Henriksen wrote:
>
>> It is very likely that issue 17386 is the issue. With
>>
>> {-# OPTIONS_GHC -Wno-overlapping-patterns -Wno-incomplete-patterns
>> -Wno-incomplete-uni-patterns -Wno-incomplete-record-updates #-}
>>
>> my module(s) compile very quickly. I'll wait and see if GHC 9 does
>> better before I try to create a smaller case (and now I at least have a
>> workaround).
>>
>> Sebastian Graf writes:
>>
>> > Hi,
>> >
>> > I'm not sure I see all the context of the conversation, but it is
>> entirely
>> > possible that code with many local constraints regresses the
>> pattern-match
>> > checker (which is accounted to Desugaring in the profile emitted by
>> -v2),
>> > I'm afraid. That simply has to do with the fact that we now actually
>> care
>> > about them, previously they were mostly discarded.
>> >
>> > I'd be glad if you submitted a relatively isolated reproducer of what is
>> > fast with 8.8 and slow with 8.10 (even better 9.0).
>> > I hope that things have improved since we fixed
>> > https://gitlab.haskell.org/ghc/ghc/-/issues/17836, which is part of
>> 9.0 but
>> > not of 8.10.
>> >
>> > Cheers,
>> > Sebastian
>> >
>> > Am Mo., 15. Feb. 2021 um 19:04 Uhr schrieb Troels Henriksen <
>> > at...@sigkill.dk>:
>> >
>> >> Carter Schonwald writes:
>> >>
>> >> > Ccing ghc devs since that’s a better forum perhaps
>> >> > Crazy theory:
>> >> >
>> >> > this is a regression due the the partial changes to pattern matching
>> >> > coverage checking in 8.10 that finished / landed in ghc 9
>> >> >
>> >> > Why:
>> >> > Desugaring is when pattern/ case statement translation happens I
>> think?
>> >> > And the only obvious “big thing” is that you have some huge , albeit
>> sane
>> >> > for a compiler, pattern matching
>> >> >
>> >> > I’d first check if the new ghc 9 release doesn’t have that
>> regression in
>> >> > build time that you experienced. And if it does file a ticket.
>> >> >
>> >> > I may be totally wrong, but that seems like a decent likelihood !
>> >>
>> >> You may be right! Another module that regressed is also mainly
>> >> characterised by large-but-not-insane case expressions:
>> >>
>> >>
>> https://github.com/diku-dk/futhark/blob/d0839412bdd11884d75a1494dd5de5191833f39e/src/Futhark/Optimise/Simplify/Rules.hs
>> >>
>> >> I'll try to split these modules up a little bit (I should have done so
>> a
>> >> while ago anyway) and maybe that will make the picture even clearer.
>> >>
>> >> --
>> >> \ Troels
>> >> /\ Henriksen
>> >> ___
>> >> ghc-devs mailing list
>> >> ghc-devs@haskell.org
>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >>
>>
>> --
>> \ Troels
>> /\ Henriksen
>>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
--
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Pattern matching desugaring regression? Re: [Haskell-cafe] Why does my module take so long to compile?
Don’t forget ghc 9 is already out! :)
On Mon, Feb 15, 2021 at 2:10 PM Troels Henriksen wrote:
> It is very likely that issue 17386 is the issue. With
>
> {-# OPTIONS_GHC -Wno-overlapping-patterns -Wno-incomplete-patterns
> -Wno-incomplete-uni-patterns -Wno-incomplete-record-updates #-}
>
> my module(s) compile very quickly. I'll wait and see if GHC 9 does
> better before I try to create a smaller case (and now I at least have a
> workaround).
>
> Sebastian Graf writes:
>
> > Hi,
> >
> > I'm not sure I see all the context of the conversation, but it is
> entirely
> > possible that code with many local constraints regresses the
> pattern-match
> > checker (which is accounted to Desugaring in the profile emitted by -v2),
> > I'm afraid. That simply has to do with the fact that we now actually care
> > about them, previously they were mostly discarded.
> >
> > I'd be glad if you submitted a relatively isolated reproducer of what is
> > fast with 8.8 and slow with 8.10 (even better 9.0).
> > I hope that things have improved since we fixed
> > https://gitlab.haskell.org/ghc/ghc/-/issues/17836, which is part of 9.0
> but
> > not of 8.10.
> >
> > Cheers,
> > Sebastian
> >
> > Am Mo., 15. Feb. 2021 um 19:04 Uhr schrieb Troels Henriksen <
> > at...@sigkill.dk>:
> >
> >> Carter Schonwald writes:
> >>
> >> > Ccing ghc devs since that’s a better forum perhaps
> >> > Crazy theory:
> >> >
> >> > this is a regression due the the partial changes to pattern matching
> >> > coverage checking in 8.10 that finished / landed in ghc 9
> >> >
> >> > Why:
> >> > Desugaring is when pattern/ case statement translation happens I
> think?
> >> > And the only obvious “big thing” is that you have some huge , albeit
> sane
> >> > for a compiler, pattern matching
> >> >
> >> > I’d first check if the new ghc 9 release doesn’t have that regression
> in
> >> > build time that you experienced. And if it does file a ticket.
> >> >
> >> > I may be totally wrong, but that seems like a decent likelihood !
> >>
> >> You may be right! Another module that regressed is also mainly
> >> characterised by large-but-not-insane case expressions:
> >>
> >>
> https://github.com/diku-dk/futhark/blob/d0839412bdd11884d75a1494dd5de5191833f39e/src/Futhark/Optimise/Simplify/Rules.hs
> >>
> >> I'll try to split these modules up a little bit (I should have done so a
> >> while ago anyway) and maybe that will make the picture even clearer.
> >>
> >> --
> >> \ Troels
> >> /\ Henriksen
> >> ___
> >> ghc-devs mailing list
> >> ghc-devs@haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >>
>
> --
> \ Troels
> /\ Henriksen
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Pattern matching desugaring regression? Re: [Haskell-cafe] Why does my module take so long to compile?
It is very likely that issue 17386 is the issue. With
{-# OPTIONS_GHC -Wno-overlapping-patterns -Wno-incomplete-patterns
-Wno-incomplete-uni-patterns -Wno-incomplete-record-updates #-}
my module(s) compile very quickly. I'll wait and see if GHC 9 does
better before I try to create a smaller case (and now I at least have a
workaround).
Sebastian Graf writes:
> Hi,
>
> I'm not sure I see all the context of the conversation, but it is entirely
> possible that code with many local constraints regresses the pattern-match
> checker (which is accounted to Desugaring in the profile emitted by -v2),
> I'm afraid. That simply has to do with the fact that we now actually care
> about them, previously they were mostly discarded.
>
> I'd be glad if you submitted a relatively isolated reproducer of what is
> fast with 8.8 and slow with 8.10 (even better 9.0).
> I hope that things have improved since we fixed
> https://gitlab.haskell.org/ghc/ghc/-/issues/17836, which is part of 9.0 but
> not of 8.10.
>
> Cheers,
> Sebastian
>
> Am Mo., 15. Feb. 2021 um 19:04 Uhr schrieb Troels Henriksen <
> at...@sigkill.dk>:
>
>> Carter Schonwald writes:
>>
>> > Ccing ghc devs since that’s a better forum perhaps
>> > Crazy theory:
>> >
>> > this is a regression due the the partial changes to pattern matching
>> > coverage checking in 8.10 that finished / landed in ghc 9
>> >
>> > Why:
>> > Desugaring is when pattern/ case statement translation happens I think?
>> > And the only obvious “big thing” is that you have some huge , albeit sane
>> > for a compiler, pattern matching
>> >
>> > I’d first check if the new ghc 9 release doesn’t have that regression in
>> > build time that you experienced. And if it does file a ticket.
>> >
>> > I may be totally wrong, but that seems like a decent likelihood !
>>
>> You may be right! Another module that regressed is also mainly
>> characterised by large-but-not-insane case expressions:
>>
>> https://github.com/diku-dk/futhark/blob/d0839412bdd11884d75a1494dd5de5191833f39e/src/Futhark/Optimise/Simplify/Rules.hs
>>
>> I'll try to split these modules up a little bit (I should have done so a
>> while ago anyway) and maybe that will make the picture even clearer.
>>
>> --
>> \ Troels
>> /\ Henriksen
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
--
\ Troels
/\ Henriksen
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Pattern matching desugaring regression? Re: [Haskell-cafe] Why does my module take so long to compile?
Hi, I'm not sure I see all the context of the conversation, but it is entirely possible that code with many local constraints regresses the pattern-match checker (which is accounted to Desugaring in the profile emitted by -v2), I'm afraid. That simply has to do with the fact that we now actually care about them, previously they were mostly discarded. I'd be glad if you submitted a relatively isolated reproducer of what is fast with 8.8 and slow with 8.10 (even better 9.0). I hope that things have improved since we fixed https://gitlab.haskell.org/ghc/ghc/-/issues/17836, which is part of 9.0 but not of 8.10. Cheers, Sebastian Am Mo., 15. Feb. 2021 um 19:04 Uhr schrieb Troels Henriksen < at...@sigkill.dk>: > Carter Schonwald writes: > > > Ccing ghc devs since that’s a better forum perhaps > > Crazy theory: > > > > this is a regression due the the partial changes to pattern matching > > coverage checking in 8.10 that finished / landed in ghc 9 > > > > Why: > > Desugaring is when pattern/ case statement translation happens I think? > > And the only obvious “big thing” is that you have some huge , albeit sane > > for a compiler, pattern matching > > > > I’d first check if the new ghc 9 release doesn’t have that regression in > > build time that you experienced. And if it does file a ticket. > > > > I may be totally wrong, but that seems like a decent likelihood ! > > You may be right! Another module that regressed is also mainly > characterised by large-but-not-insane case expressions: > > https://github.com/diku-dk/futhark/blob/d0839412bdd11884d75a1494dd5de5191833f39e/src/Futhark/Optimise/Simplify/Rules.hs > > I'll try to split these modules up a little bit (I should have done so a > while ago anyway) and maybe that will make the picture even clearer. > > -- > \ Troels > /\ Henriksen > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Pattern matching desugaring regression? Re: [Haskell-cafe] Why does my module take so long to compile?
Carter Schonwald writes: > Ccing ghc devs since that’s a better forum perhaps > Crazy theory: > > this is a regression due the the partial changes to pattern matching > coverage checking in 8.10 that finished / landed in ghc 9 > > Why: > Desugaring is when pattern/ case statement translation happens I think? > And the only obvious “big thing” is that you have some huge , albeit sane > for a compiler, pattern matching > > I’d first check if the new ghc 9 release doesn’t have that regression in > build time that you experienced. And if it does file a ticket. > > I may be totally wrong, but that seems like a decent likelihood ! You may be right! Another module that regressed is also mainly characterised by large-but-not-insane case expressions: https://github.com/diku-dk/futhark/blob/d0839412bdd11884d75a1494dd5de5191833f39e/src/Futhark/Optimise/Simplify/Rules.hs I'll try to split these modules up a little bit (I should have done so a while ago anyway) and maybe that will make the picture even clearer. -- \ Troels /\ Henriksen ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Pattern matching desugaring regression? Re: [Haskell-cafe] Why does my module take so long to compile?
Ccing ghc devs since that’s a better forum perhaps Crazy theory: this is a regression due the the partial changes to pattern matching coverage checking in 8.10 that finished / landed in ghc 9 Why: Desugaring is when pattern/ case statement translation happens I think? And the only obvious “big thing” is that you have some huge , albeit sane for a compiler, pattern matching I’d first check if the new ghc 9 release doesn’t have that regression in build time that you experienced. And if it does file a ticket. I may be totally wrong, but that seems like a decent likelihood ! On Mon, Feb 15, 2021 at 12:20 PM Troels Henriksen wrote: > Carter Schonwald writes: > > > How big are your data types in the file In question? Do you ghc generics > or > > deriving or template Haskell? Could you share a link to the file in > > question ? > > The file does not define any large data types itself, but it operates on > some fairly large data types (an AST, it's a compiler). But so do many > other modules that work just fine. It uses no generics, nontrivial > deriving, or Template Haskell. It's this file: > > https://github.com/diku-dk/futhark/blob/master/src/Futhark/Pass/ExtractKernels/DistributeNests.hs > > I also found a handful of other modules in my project that are > significantly slower to compile in GHC 8.10, and seemingly also because > of the desugarer, but none of them have any obvious smoking guns like > generics or TH. > > The only commonality I can find is that the affected modules contain > functions with a relatively large typeclass context. I use > ConstraintKinds to make them more concise, and I guess unfolded there > may be 30-40 equality/class constraints in total. Like this: > > type DistLore lore = > ( Bindable lore, > HasSegOp lore, > BinderOps lore, > LetDec lore ~ Type, > ExpDec lore ~ (), > BodyDec lore ~ () > ) > > where the 'Bindable' constraint in particular then implies a further > handful of "~" constraints: > > class > ( ASTLore lore, > FParamInfo lore ~ DeclType, > LParamInfo lore ~ Type, > RetType lore ~ DeclExtType, > BranchType lore ~ ExtType, > SetType (LetDec lore) > ) => > Bindable lore > where > ... > > FParamInfo/LParamInfo/etc are type families. Are such constraints > particularly slow? > > -- > \ Troels > /\ Henriksen > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: cep_app traces
Simon Peyton Jones via ghc-devs writes: > Ben > I'm getting a lot of > > cpe_app(keepAlive#) 3 > > cpe_app(keepAlive) > trace messages from HEAD. Maybe it's a leftover from tracing when you were > developing? Remove? Oh dear. Yes, it looks like I removed them from the version merged to 9.0 but not from the master version. I'll remove them. Thanks! 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
RE: Plan for GHC 9.2
Simon Peyton Jones via ghc-devs writes: > Ben > > Can we get record dot syntax into 9.2? > > * Shayne is really nearly there in !4532; he has been working > hard and recently. Yes, Shayne asked about this last week; I updated the milestone and added it to the milestone highlights [1]. > * It depends on my !4981 (was 4722) which fixes some bugs and > I'm keen to commit. > Alright, let's add it > > So, is it ok in principle to pull to trigger on !4981, and hopefully !4532? Yes, I've added !4981 to the merge queue. !4532 can be merged whenever it is ready. 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
Re: Weekly show & tell video meeting
What time works for you? My schedule is flexible. On Mon, Feb 15, 2021 at 5:11 PM Edward Kmett wrote: > I'd be happy to go with one and see how it goes and plan from there if > that works for you. > > -Edward > > On Mon, Feb 15, 2021 at 7:06 AM Csaba Hruska > wrote: > >> Hello, >> Would you be interested in a weekly show & tell video meeting? >> The topic would be Haskell & compilers in general. Either GHC or non-GHC >> related. >> >> Regards, >> Csaba >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Weekly show & tell video meeting
I'd be happy to go with one and see how it goes and plan from there if that works for you. -Edward On Mon, Feb 15, 2021 at 7:06 AM Csaba Hruska wrote: > Hello, > Would you be interested in a weekly show & tell video meeting? > The topic would be Haskell & compilers in general. Either GHC or non-GHC > related. > > Regards, > Csaba > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Weekly show & tell video meeting
Hello, Would you be interested in a weekly show & tell video meeting? The topic would be Haskell & compilers in general. Either GHC or non-GHC related. Regards, Csaba ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Plan for GHC 9.2
[Re-sending from the correct address, apologies!] It would be great to get RecordDotSyntax for selection into 9.2. As I just commented on !4532 [1] there's one awkward point to resolve, which is that 9.2 will probably not have `setField`, on which RecordDotSyntax updates depend. Cheers, Adam [1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4532#note_330581) On 15/02/2021 10:33, Simon Peyton Jones via ghc-devs wrote: > Ben > > Can we get record dot syntax into 9.2? > > * Shayne is really nearly there in !4532; he has been working > hard and recently. > * It depends on my !4981 (was 4722) which fixes some bugs and > I'm keen to commit. > > > So, is it ok in principle to pull to trigger on !4981, and hopefully !4532? > > Simon > > | -Original Message- > | From: ghc-devs On Behalf Of Ben Gamari > | Sent: 04 February 2021 18:56 > | To: GHC developers > | Subject: Plan for GHC 9.2 > | > | > | tl;dr. Provisional release schedule for 9.2 enclosed. Please discuss, > | especially if you have something you would like merged for > | 9.2.1. > | > | Hello all, > | > | With GHC 9.0.1 at long-last out the door, it is time that we start > | turning attention to GHC 9.2. I would like to avoid making the mistake > | made in the 9.0 series in starting the fork in a state that required a > | significant amount of backporting to be releaseable. Consequently, I > | want to make sure that we have a fork schedule that is realistic given > | the things that need to be merged for 9.2. These include: > | > | * Update haddock submodule in `master` (Ben) > | * Bumping bytestring to 0.11 (#19091, Ben) > | * Finishing the rework of sized integer primops (#19026, John > | Ericson) > | * Merge of ghc-exactprint into GHC? (Alan Zimmerman, Henry) > | * Merge BoxedRep (#17526, Ben) > | * ARM NCG backend and further stabilize Apple ARM support? (Moritz) > | * Some form of coercion zapping (Ben, Simon, Richard) > | * Tag inference analysis and tag check elision (Andreas) > | > | If you see something that you would like to see in 9.2.1 please do > | holler. Otherwise, if you see your name in this list it would be great > | if you could let me know when you think your project may be in a > | mergeable state. > | > | Ideally we would strive for a schedule like the following: > | > | 4 February 2021: We are here > | ~4 weeks pass > | 3 March 2021: Release branch forked > | 1 week passes > | 10 March 2021: Alpha 1 released > | 3 weeks pass > | 31 March 2021: Alpha 2 released > | 2 weeks pass > | 14 April 2021: Alpha 3 released > | 2 weeks pass > | 28 April 2021: Alpha 4 released > | 1 week passes > | 5 May 2021:Beta 1 released > | 1 week passes > | 12 May 2021: Release candidate 1 released > | 2 weeks pass > | 26 May 2021: Final release > | > | This provides ample time for stabilization while avoiding deviation > | from the usual May release timeframe. However, this would require that > | we move aggressively to start getting the tree into shape since the > | fork would be less than four weeks away. I would appreciate > | contributors' > | thoughts on the viability of this timeline. > | > | Cheers, > | > | - Ben -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 118 Wymering Mansions, Wymering Road, London W9 2NF, England ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Plan for GHC 9.2
Ben Can we get record dot syntax into 9.2? * Shayne is really nearly there in !4532; he has been working hard and recently. * It depends on my !4981 (was 4722) which fixes some bugs and I'm keen to commit. So, is it ok in principle to pull to trigger on !4981, and hopefully !4532? Simon | -Original Message- | From: ghc-devs On Behalf Of Ben Gamari | Sent: 04 February 2021 18:56 | To: GHC developers | Subject: Plan for GHC 9.2 | | | tl;dr. Provisional release schedule for 9.2 enclosed. Please discuss, | especially if you have something you would like merged for | 9.2.1. | | Hello all, | | With GHC 9.0.1 at long-last out the door, it is time that we start | turning attention to GHC 9.2. I would like to avoid making the mistake | made in the 9.0 series in starting the fork in a state that required a | significant amount of backporting to be releaseable. Consequently, I | want to make sure that we have a fork schedule that is realistic given | the things that need to be merged for 9.2. These include: | | * Update haddock submodule in `master` (Ben) | * Bumping bytestring to 0.11 (#19091, Ben) | * Finishing the rework of sized integer primops (#19026, John | Ericson) | * Merge of ghc-exactprint into GHC? (Alan Zimmerman, Henry) | * Merge BoxedRep (#17526, Ben) | * ARM NCG backend and further stabilize Apple ARM support? (Moritz) | * Some form of coercion zapping (Ben, Simon, Richard) | * Tag inference analysis and tag check elision (Andreas) | | If you see something that you would like to see in 9.2.1 please do | holler. Otherwise, if you see your name in this list it would be great | if you could let me know when you think your project may be in a | mergeable state. | | Ideally we would strive for a schedule like the following: | | 4 February 2021: We are here | ~4 weeks pass | 3 March 2021: Release branch forked | 1 week passes | 10 March 2021: Alpha 1 released | 3 weeks pass | 31 March 2021: Alpha 2 released | 2 weeks pass | 14 April 2021: Alpha 3 released | 2 weeks pass | 28 April 2021: Alpha 4 released | 1 week passes | 5 May 2021:Beta 1 released | 1 week passes | 12 May 2021: Release candidate 1 released | 2 weeks pass | 26 May 2021: Final release | | This provides ample time for stabilization while avoiding deviation | from the usual May release timeframe. However, this would require that | we move aggressively to start getting the tree into shape since the | fork would be less than four weeks away. I would appreciate | contributors' | thoughts on the viability of this timeline. | | Cheers, | | - Ben ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
cep_app traces
Ben I'm getting a lot of cpe_app(keepAlive#) 3 cpe_app(keepAlive) trace messages from HEAD. Maybe it's a leftover from tracing when you were developing? Remove? Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
