GHC perf
Ben, David I'm still baffled by how to reliably get GHC perf metrics on my local machine. The wiki page https://gitlab.haskell.org/ghc/ghc/wikis/building/running-tests/performance-tests helps, but not enough! * There are two things going on: * CI perf measurements * Local machine perf measurements I think that they are somehow handled differently (why?) but they are all muddled up on the wiki page. * My goal is this: * Start with a master commit, say from Dec 2019. * Implement some change, on a branch. * sh validate -legacy (or something else if you like) * Look at perf regressions. * I believe I have first to utter the incantation $ git fetch https://gitlab.haskell.org/ghc/ghc-performance-notes.git refs/notes/perf:refs/notes/ci/perf * But then: * How do I ensure that the baseline perf numbers I get relate to the master commit I started from, back in Dec 2019? I don't want numbers from Jan 2020. * If I rebase my branch on top of HEAD, say, how do I update the perf baseline numbers to be for HEAD? * Generally, how can I tell the commit to which the baseline numbers relate? * Also, in my tree I have a series of incremental changes; I want to see if any of them have perf regressions.How do I do that? Thanks Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Windows testsuite failures
Hi all, Currently Windows CI is a bit flaky due to some unfortunately rather elusive testsuite driver bugs. Progress in resolving this has been a bit slow due to travel over the last week but I will be back home tomorrow and should be able to resolve the issue soon thereafter. Cheers, - Ben ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Fixing type synonyms to Uniq(D)FM newtypes
One advantage of the phantom-parameter approach is that it allows for nice polymorphism. > lookupEnv :: Uniquable dom => UniqFM dom rng -> dom -> Maybe rng Now, we don't need lookupVarEnv separately from lookupNameEnv, but we get the type-checking for free. I agree with Ben about the fact that newtypes have their own advantages. I don't have much of an opinion, in the end. Richard > On Jan 14, 2020, at 10:31 AM, Ben Gamari wrote: > > Matthew Pickering writes: > >> Can someone explain the benefit of the newtype wrappers over the >> phantom type parameter approach? >> >> In my mind adding a phantom type parameter to `UniqFM` solves the >> issue entirely but will result in less code churn and follows the >> example from the existing map data types from containers. >> > I would say the same of newtype wrappers; afterall, we already have a > convention of using the "specialised" type synonyms and their functions > instead of UniqFM directly where possible. Turning VarEnv, etc. into > newtypes likely touch little code outside of the modules where they are > defined. > > Which approach is preferable is really a question of what degree of > encapsulation we want. The advantage of making, e.g., VarEnv a newtype > is that our use of Uniques remains an implementation detail (which it > is, in my opinion). We are then in principle free to change the > representation of VarEnv down the road. > > Of course, in practice it is hard to imagine GHC moving away from > uniques for things like VarEnv. However, properly encapsulating them > seems like good engineering practice and incurs very little cost > (especially given our current conventions). > > Cheers, > > - Ben > > ___ > 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: Fixing type synonyms to Uniq(D)FM newtypes
Matthew Pickering writes: > Can someone explain the benefit of the newtype wrappers over the > phantom type parameter approach? > > In my mind adding a phantom type parameter to `UniqFM` solves the > issue entirely but will result in less code churn and follows the > example from the existing map data types from containers. > I would say the same of newtype wrappers; afterall, we already have a convention of using the "specialised" type synonyms and their functions instead of UniqFM directly where possible. Turning VarEnv, etc. into newtypes likely touch little code outside of the modules where they are defined. Which approach is preferable is really a question of what degree of encapsulation we want. The advantage of making, e.g., VarEnv a newtype is that our use of Uniques remains an implementation detail (which it is, in my opinion). We are then in principle free to change the representation of VarEnv down the road. Of course, in practice it is hard to imagine GHC moving away from uniques for things like VarEnv. However, properly encapsulating them seems like good engineering practice and incurs very little cost (especially given our current conventions). 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: Fixing type synonyms to Uniq(D)FM newtypes
Can someone explain the benefit of the newtype wrappers over the phantom type parameter approach? In my mind adding a phantom type parameter to `UniqFM` solves the issue entirely but will result in less code churn and follows the example from the existing map data types from containers. Cheers, Matt On Tue, Jan 14, 2020 at 10:02 AM Ben Gamari wrote: > > Ömer Sinan Ağacan writes: > > > Hi, > > > > UniqFM and UniqDFM types are basically maps from Uniques to other stuff. > > Most of > > the time we don't actually map Uniques but instead map things like Vars or > > Names. For those we have types like VarEnv, NameEnv, FastStringEnv, ... > > which > > are defined as type synonyms to UniqFM or UniqDFM, and operations are > > defined > > like > > > > extendFsEnv = addToUFM > > extendNameEnv = addToUFM > > extendVarEnv = addToUFM > > > > This causes problems when I have multiple Uniquables in scope and use the > > wrong > > one to update an environment because the program type checks and does the > > wrong > > thing in runtime. An example is #17667 where I did > > > > delVarEnv env name > > > > where `name :: Name`. I shouldn't be able to remove a Name from a Var env > > but > > this currently type checks. > > > At first I was a bit confused at how this could possibly typecheck. > Afterall, delVarEnv has type, > > VarEnv a -> Var -> VarEnv a > > which seems quite reasonable and should correctly reject the application > to a Name as given in Omer's example. However, the mistake in #17667 > is actually that he wrote, > > delVarEnv env name > > instead of > > delNameEnv env (varName var) > > That is, because `VarEnv a ~ NameEnv a` one can easily mix up a > NameEnv with a VarEnv and not get a compile-time error. I can see how > this could be a nasty bug to track down. > > > > Two solutions proposed: > > > > - Make these env types newtypes instead of type synonyms. > > - Add a phantom type parameter to UniqFM/UniqDFM. > > > IIRC this has been suggested before. I, for one, see the value in this > and certainly wouldn't be opposed to either of these options, although > would weakly favor the former over the latter. > > Cheers, > > - Ben > ___ > 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: Fixing type synonyms to Uniq(D)FM newtypes
Ömer Sinan Ağacan writes: > Hi, > > UniqFM and UniqDFM types are basically maps from Uniques to other stuff. Most > of > the time we don't actually map Uniques but instead map things like Vars or > Names. For those we have types like VarEnv, NameEnv, FastStringEnv, ... which > are defined as type synonyms to UniqFM or UniqDFM, and operations are defined > like > > extendFsEnv = addToUFM > extendNameEnv = addToUFM > extendVarEnv = addToUFM > > This causes problems when I have multiple Uniquables in scope and use the > wrong > one to update an environment because the program type checks and does the > wrong > thing in runtime. An example is #17667 where I did > > delVarEnv env name > > where `name :: Name`. I shouldn't be able to remove a Name from a Var env but > this currently type checks. > At first I was a bit confused at how this could possibly typecheck. Afterall, delVarEnv has type, VarEnv a -> Var -> VarEnv a which seems quite reasonable and should correctly reject the application to a Name as given in Omer's example. However, the mistake in #17667 is actually that he wrote, delVarEnv env name instead of delNameEnv env (varName var) That is, because `VarEnv a ~ NameEnv a` one can easily mix up a NameEnv with a VarEnv and not get a compile-time error. I can see how this could be a nasty bug to track down. > Two solutions proposed: > > - Make these env types newtypes instead of type synonyms. > - Add a phantom type parameter to UniqFM/UniqDFM. > IIRC this has been suggested before. I, for one, see the value in this and certainly wouldn't be opposed to either of these options, although would weakly favor the former over the latter. 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
