| In order to try to hack my way through and get my library to compile,
| I tried progressively adding more and more pattern synonyms to try to
| avoid exhaustiveness checking,yet, something really surprising
| happened. Big examples have type errors where small ones don't!
That is strange. Sounds as if you want a new Trac report, just for that.
Simon
| -----Original Message-----
| From: Victor Miraldo (UU)
| Sent: 07 April 2018 12:02
| To: Ben Gamari
| Cc: Simon Peyton Jones ; ghc-devs@haskell.org
| Subject: Re: Memory usage exploding for complex pattern matching
|
| Hello all,
|
| Following up on this, I have created a trac ticket
| https://ghc.haskell.org/trac/ghc/ticket/14987#no2 as suggested a
| couple days ago.
|
| In order to try to hack my way through and get my library to compile,
| I tried progressively adding more and more pattern synonyms to try to
| avoid exhaustiveness checking,yet, something really surprising
| happened. Big examples have type errors where small ones don't!
|
| I tried documenting the process in a repository:
| https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
| b.com%2FVictorCMiraldo%2Fghc-14987-repro-
| pipeline&data=02%7C01%7Csimonpj%40microsoft.com%7C59fdacad7f94412d665e
| 08d59c7717f3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636586957847
| 493826&sdata=bnuBOL%2FELkmJahidX%2BmWPSDDf%2BuKlJkBAJyFVyY%2Bel8%3D&re
| served=0
|
| Unfortunately, however, I couldn't get the self contained repros in
| the repository above to throw type errors. Hence, I'm attaching my
| full code. Compiling the file src/Generics/MRSOP/Examples/GoAST.hs
| gives type errors, even though it is being generated by the same
| template haskell code as the other files inside Examples, all of which
| compile just fine. To trigger the error, just run `stack build`.
|
| It really is a shame that the combination of pattern synonyms that
| shows the best memory performance crashes completely on bigger
| examples.
|
| Any suggestions are appreciated, thank you very much!
|
| Have a great weekend!
| Cheers,
| Victor
|
|
|
| On Fri, Mar 30, 2018 at 5:23 PM, Ben Gamari
| wrote:
| > "Victor Miraldo (UU)" writes:
| >
| >> Hello,
| >>
| >>>>>> I have just tried compiling my code with 8.4.2 and using
| >>>>>> -fmax-pmcheck-iterations=0, I gave GHC 12GB of ram and it still
| >>>>>> ran out (through `ulimit -v$((1024*1024*12))`).
| >>>>>>
| >>>>> Hmmm, I'm a bit confused. Why are our results so different? How
| >>>>> precisely are you invoking GHC?
| >>>>
| >>>> Here I meant my whole code, not just the repro. I could have been
| more clear.
| >>>> Nevertheless, I'm calling it through stack:
| >>>>
| >>> I'll admit that I am a bit lost; Minimal.hs compiles for me with a
| >>> maximum residency of ~3.5 GBytes with both -O1 and the PM check
| >>> enabled using GHC 8.4.1. Is this not the repro you are referring
| to?
| >>
| >> I get the same behavior as you for Minimal.hs.
| >>
| >> The "my code" above referred to the whole library that I'm
| developping.
| >> In fact, the Minimal.hs file contains a distilled version of that
| >> library with a template haskell splice that we are trying to use in
| >> one of our fully fledged examples.
| >>
| > Okay, I just wanted to be certain we were indeed seeing the same
| > behavior. Indeed 3.5 GB is quite a lot of memory for a 700 LoC
| > program, even one with the deep matches seen in Minimal.hs.
| >
| > Cheers,
| >
| > - Ben
| >
