Re: Better perf
Hey, when going through Simon-nofib-notes, I stumbled over this thread from March 2017, when I hadn't yet subscribed to this list: https://mail.haskell.org/pipermail/ghc-devs/2017-March/013887.html. Joachim and Simon were trying to pin-point seemingly random regressions and improvements of ~5% to `binary-trees`. It's hard to say in retrospect, but I suspect this is the same effect I experienced in #15333 and I'm about to fix in #15999, e.g. that small changes to allocations lead to big, uncorrelated jumps in runtime performance due to GC. Just wanted to record this here for posterity. Cheers Sebastian Hi, > > Am Dienstag, den 07.03.2017, 22:55 + schrieb Simon Peyton Jones via > ghc-devs: > >* > But: binary-trees runtime increases by 5%. > *> >* David: might you look to see if there is any obvious reason for this > *>* regression? We could just accept it, but it's always good to know > *>* why, and to document it. > * > Turns out that my commit > Add rule mapFB c (λx.x) = c > fixed that > regression:https://perf.haskell.org/ghc/#revision/2fa44217c1d977297eefb0d6c6aed7e128ca > > Maybe there is just a performance cliff there, and these jumps don’t > really mean anything. > > Greetings, > Joachim > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Better perf
Interesting! I keep nofib/Simon-nofib-notes for per-benchmark notes on perf. Would you like to add a note for 'binary-trees' pointing to these emails? So if someone later is looking for perf changes in binary-trees, they have some back-pointers to chase up. Thanks Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Joachim Breitner | Sent: 09 March 2017 15:10 | To: ghc-devs@haskell.org | Subject: Re: Better perf | | Hi, | | Am Dienstag, den 07.03.2017, 22:55 + schrieb Simon Peyton Jones | via | ghc-devs: | > > But: binary-trees runtime increases by 5%. | > | > David: might you look to see if there is any obvious reason for this | > regression? We could just accept it, but it's always good to know | > why, and to document it. | | Turns out that my commit | Add rule mapFB c (λx.x) = c | fixed that regression: | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fperf. | haskell.org%2Fghc%2F%23revision%2F2fa44217c1d977297eefb0d6c6aed7e1 | 28ca=02%7C01%7Csimonpj%40microsoft.com%7C874797bc62de4b6aecf208d4 | 66fe7720%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6362466904875493 | 08=ysGORaGgIlhCc88uQHB3v0sh5LNWhFY06iSgnTm6Pgo%3D=0 | | Maybe there is just a performance cliff there, and these jumps don’t | really mean anything. | | Greetings, | Joachim | | -- | Joachim “nomeata” Breitner | m...@joachim-breitner.de • | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.j | oachim- | breitner.de%2F=02%7C01%7Csimonpj%40microsoft.com%7C874797bc62de4b | 6aecf208d466fe7720%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636246 | 690487549308=HxOTFdoh4hIqXVbPCgZOwMjob%2B572b1ymbAdBEXTF6A%3D | served=0 | XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F | Debian Developer: nome...@debian.org ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Better perf
Hi, Am Dienstag, den 07.03.2017, 22:55 + schrieb Simon Peyton Jones via ghc-devs: > > But: binary-trees runtime increases by 5%. > > David: might you look to see if there is any obvious reason for this > regression? We could just accept it, but it's always good to know > why, and to document it. Turns out that my commit Add rule mapFB c (λx.x) = c fixed that regression: https://perf.haskell.org/ghc/#revision/2fa44217c1d977297eefb0d6c6aed7e128ca Maybe there is just a performance cliff there, and these jumps don’t really mean anything. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nome...@debian.org 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: Better perf
| But: binary-trees runtime increases by 5%. David: might you look to see if there is any obvious reason for this regression? We could just accept it, but it's always good to know why, and to document it. Thanks Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Joachim | Breitner | Sent: 07 March 2017 10:43 | To: ghc-devs@haskell.org | Subject: Re: Better perf | | Hi, | | perf.haskell.org has something to say about these: | | Am Montag, den 06.03.2017, 15:45 + schrieb Simon Peyton Jones via | ghc-devs: | > I’ve just committed this patch sequence | > fb9ae288088a3eabc4e1bb4e86fa473a3881d2e2 Make FloatOut/SetLevels | > idemoptent on bottoming functions | | increases lambda runtime by 3%. Maybe an environment-dependent | performance cliff, given that you did not report this regression in your | nofib listing. | | > 995ab74b3c55fe3a0299bd94b49e948c942e76d6 Comments only | | No change reported. Good :-) | | > 1163f4f2fe9aabd722c963497c67c5f8c71ef71b Tiny refactor | | No change reported. | | > 9b2c73ea8082199245bfa6a28390b70b38f87fd1 Make TH_Roles2 less fragile | | No change reported. | | > 9304df5230a7a29d3e992916d133e462b854e55f Fix CSE (again) on literal | > strings | | This is where most of the changes are: | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fperf.has | kell.org%2Fghc%2F%23revision%2F9304df5230a7a29d3e992916d133e462b854e55f | ata=02%7C01%7Csimonpj%40microsoft.com%7C68ad9d20aa794e70cdb708d46546c5ff% | 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244802039385263=pvj | YNwtA3NHHxF7z7bwagYX5Cjun8%2FIztPvXEO1AtdY%3D=0 | | There are some nice runtime improvements in cryptarithm1 (-12%), fasta, | integer and scs (each -3%). | | But: binary-trees runtime increases by 5%. | | | This was your daily performance weather report. | | Joachim | | -- | Joachim “nomeata” Breitner | m...@joachim-breitner.de • | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joac | him- | breitner.de%2F=02%7C01%7Csimonpj%40microsoft.com%7C68ad9d20aa794e70c | db708d46546c5ff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244802039 | 385263=hbp839x4Boa3J6gY4sOchfHGsLZeHiEsNatxsSv08iQ%3D=0 | XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F | Debian Developer: nome...@debian.org ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Better perf
Simon Peyton Jones via ghc-devswrites: > I've just committed this patch sequence > > fb9ae288088a3eabc4e1bb4e86fa473a3881d2e2 Make FloatOut/SetLevels idemoptent > on bottoming functions > > 995ab74b3c55fe3a0299bd94b49e948c942e76d6 Comments only > > 1163f4f2fe9aabd722c963497c67c5f8c71ef71b Tiny refactor > > 9b2c73ea8082199245bfa6a28390b70b38f87fd1 Make TH_Roles2 less fragile > > 9304df5230a7a29d3e992916d133e462b854e55f Fix CSE (again) on literal strings > In my final validate run (after updating to HEAD) I saw > > Unexpected stat failures: > >perf/space_leaks/T4029.run T4029 [stat too good] (ghci) > This one is rather interesting since I have also been seeing this for quite some time locally, but Harbormaster consistently disagrees. Moreover, it passes locally if my machine isn't under load. I haven't yet investigated why allocations are so inconsistent. 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: Better perf
Hi, perf.haskell.org has something to say about these: Am Montag, den 06.03.2017, 15:45 + schrieb Simon Peyton Jones via ghc-devs: > I’ve just committed this patch sequence > fb9ae288088a3eabc4e1bb4e86fa473a3881d2e2 Make FloatOut/SetLevels idemoptent > on bottoming functions increases lambda runtime by 3%. Maybe an environment-dependent performance cliff, given that you did not report this regression in your nofib listing. > 995ab74b3c55fe3a0299bd94b49e948c942e76d6 Comments only No change reported. Good :-) > 1163f4f2fe9aabd722c963497c67c5f8c71ef71b Tiny refactor No change reported. > 9b2c73ea8082199245bfa6a28390b70b38f87fd1 Make TH_Roles2 less fragile No change reported. > 9304df5230a7a29d3e992916d133e462b854e55f Fix CSE (again) on literal strings This is where most of the changes are: https://perf.haskell.org/ghc/#revision/9304df5230a7a29d3e992916d133e462b854e55f There are some nice runtime improvements in cryptarithm1 (-12%), fasta, integer and scs (each -3%). But: binary-trees runtime increases by 5%. This was your daily performance weather report. Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nome...@debian.org 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: Better perf for haddock.base, haddock.Cabal (f4aa998)
| clearly points to this commit: | | commit fc9d152b058f21ab03986ea722d0c94688b9969f | Author: Simon Peyton Jones <simo...@microsoft.com> | Date: Thu Feb 16 09:41:55 2017 + | | Comments and tiny refactor only Crumbs! You are right! I have NO IDEA why this effect is so large. I fixed the bug in occAnalApp when I was auditing your changes, but I couldn't think of a situation in which I would matter, and then I forgot all about it. It's hard to add a comment both the call to mkOneOcc and isExpandableApp were designed for the number of args the function is *syntactically* applied to. But the argOneShots needs how many it is *semantically* applied to, once. But is_exp only matters if isRhsEnv is true; and in that case I think occ_one_shots is empty (see rhsCtxt); so I doubt the change to is_exp makes any difference at all. It's a mystery. Ideally one would find out why. But life is short, and this is in the right direction. I've added a note to the ticket, FWIW Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Joachim | Breitner | Sent: 16 February 2017 20:41 | To: ghc-devs@haskell.org | Subject: Re: Better perf for haddock.base, haddock.Cabal (f4aa998) | | Hi, | | Am Donnerstag, den 16.02.2017, 17:46 + schrieb g...@git.haskell.org: | > commit f4aa9984790332a908e8b1321d00a839fb42c3ea | > Author: Simon Peyton Jones <simo...@microsoft.com> | > Date: Thu Feb 16 17:44:58 2017 + | > | > Better perf for haddock.base, haddock.Cabal | > | > I think this is due to | > commit 6bab649bde653f13c15eba30d5007bef4a9a9d3a | > Author: Simon Peyton Jones <simo...@microsoft.com> | > Date: Thu Feb 16 09:42:32 2017 + | > | > Improve checking of joins in Core Lint | > | > Improvement is around 5%. | | no, | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fperf.has | kell.org%2Fghc%2F%23revision%2Ffc9d152b058f21ab03986ea722d0c94688b9969f | ata=02%7C01%7Csimonpj%40microsoft.com%7Caacdd3c960ea4e56ea6c08d456ac2c5d% | 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636228744888337816=vZW | XXwyBzBcUMliVMtS9vUFmlQuBXOhciC9uzSm7aW0%3D=0 | clearly points to this commit: | | commit fc9d152b058f21ab03986ea722d0c94688b9969f | Author: Simon Peyton Jones <simo...@microsoft.com> | Date: Thu Feb 16 09:41:55 2017 + | | Comments and tiny refactor only | | Which is not just a refactoring. If you look at the diff, e.g. at | | https://phabricator.haskell.org/rGHCfc9d152b058f21ab03986ea722d0c94688b99 | 69f | you will see that after your change, the “one shot arguments according to | the environment” are no longer counted towards n_val_args in fun_uds and | is_exp. And it seems they should not! Is that something you understand | and can explain in a note? | | I guess https://phabricator.haskell.org/D3089 was merged a bit | prematurely in that respect.¹ | | Greetings, | Joachim | | | ¹ There is a workflow problem with Phab’s DR: | * A creates a new DR. | * B requests changes. DR now in state “revision needed” | * C requests changes. DR still in state “revision needed” | * A makes changes. DR now in state “needs review” | * C looks at the changes and finds his concern addressed | and accepts the revision. DR now in state “accepted”. | * G comes along, sees a DR in state “accepted” and lands it. | Problem: B did not have the chance to check the new revision. | | | | | | | -- | Joachim “nomeata” Breitner | m...@joachim-breitner.de • | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joac | him- | breitner.de%2F=02%7C01%7Csimonpj%40microsoft.com%7Caacdd3c960ea4e56e | a6c08d456ac2c5d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636228744888 | 337816=vsGnQwAfqS%2B0hfL0ZLwnDy87eNSBeLltJQXqPOadnXo%3D=0 | XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F | Debian Developer: nome...@debian.org ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Better perf for haddock.base, haddock.Cabal (f4aa998)
Joachim Breitnerwrites: > Hi, > ... > > I guess https://phabricator.haskell.org/D3089 was merged a bit > prematurely in that respect.¹ > > Greetings, > Joachim > > > ¹ There is a workflow problem with Phab’s DR: > * A creates a new DR. > * B requests changes. DR now in state “revision needed” > * C requests changes. DR still in state “revision needed” > * A makes changes. DR now in state “needs review” > * C looks at the changes and finds his concern addressed > and accepts the revision. DR now in state “accepted”. > * G comes along, sees a DR in state “accepted” and lands it. > Problem: B did not have the chance to check the new revision. > Actually, the problem in this particular case was the Simon left comments but didn't request changes. Had he done so the Diff wouldn't have entered "accepted" state until he accepted. Sorry if I had been a bit premature in merging this one. While I understand why this is the case, it can be a bit unfortunate in the case of an open-source project, where a drive-by reviewer might leave a comment, the author makes the requested change, and the reviewer never returns to accept the change. In this case the Diff remains in a sort of limbo, even if someone else accepts it. This is to some extent a social problem: In an ideal world reviewers would continue to submit reviews until the patch is merged. However, in the case of a project like GHC this is rarely the case. For this reason I sometimes need to ping reviewers and explicitly ask them to accept changes. 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: Better perf for haddock.base, haddock.Cabal (f4aa998)
Hi, Am Donnerstag, den 16.02.2017, 17:46 + schrieb g...@git.haskell.org: > commit f4aa9984790332a908e8b1321d00a839fb42c3ea > Author: Simon Peyton Jones> Date: Thu Feb 16 17:44:58 2017 + > > Better perf for haddock.base, haddock.Cabal > > I think this is due to > commit 6bab649bde653f13c15eba30d5007bef4a9a9d3a > Author: Simon Peyton Jones > Date: Thu Feb 16 09:42:32 2017 + > > Improve checking of joins in Core Lint > > Improvement is around 5%. no, https://perf.haskell.org/ghc/#revision/fc9d152b058f21ab03986ea722d0c94688b9969f clearly points to this commit: commit fc9d152b058f21ab03986ea722d0c94688b9969f Author: Simon Peyton Jones Date: Thu Feb 16 09:41:55 2017 + Comments and tiny refactor only Which is not just a refactoring. If you look at the diff, e.g. at https://phabricator.haskell.org/rGHCfc9d152b058f21ab03986ea722d0c94688b9969f you will see that after your change, the “one shot arguments according to the environment” are no longer counted towards n_val_args in fun_uds and is_exp. And it seems they should not! Is that something you understand and can explain in a note? I guess https://phabricator.haskell.org/D3089 was merged a bit prematurely in that respect.¹ Greetings, Joachim ¹ There is a workflow problem with Phab’s DR: * A creates a new DR. * B requests changes. DR now in state “revision needed” * C requests changes. DR still in state “revision needed” * A makes changes. DR now in state “needs review” * C looks at the changes and finds his concern addressed and accepts the revision. DR now in state “accepted”. * G comes along, sees a DR in state “accepted” and lands it. Problem: B did not have the chance to check the new revision. -- Joachim “nomeata” Breitner m...@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nome...@debian.org 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: Better perf?
Cool. Perhaps someone can update the numbers with a comment pointing to the relevant commit? Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Joachim Breitner | Sent: 13 September 2016 17:00 | To: ghc-devs@haskell.org | Subject: Re: Better perf? | | Hi, | | according to | https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fperf. | haskell.org%2fghc%2f%23graph%2ftests%2falloc%2fT5837=02%7c01%7csi | monpj%40microsoft.com%7ca9cef754e1f246ad325e08d3dbef0f3a%7c72f988bf86f | 141af91ab2d7cd011db47%7c1%7c0%7c636093792210134741=fh4bxFFGsWKAA | 8iZ0J%2faz6d3p4eLv2ZbX2K0qM%2b7GZY%3d | it was | | commit a48de37dcca98e7d477040b0ed298bcd1b3ab303 | Author: Sergei Trofimovich <sly...@gentoo.org> | Date: Thu Sep 1 17:34:58 2016 +0100 | | restore -fmax-worker-args handling (Trac #11565) | | | Greetings, | Joachim | | -- | Joachim “nomeata” Breitner | m...@joachim-breitner.de • | https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.j | oachim- | breitner.de%2f=02%7c01%7csimonpj%40microsoft.com%7ca9cef754e1f246 | ad325e08d3dbef0f3a%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636093 | 792210144750=gv6NQVusbo5hJ0w4vvHZyyJGsXWe6iPadR6emQWaKZo%3d | XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F | Debian Developer: nome...@debian.org ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Better perf?
Hi, according to https://perf.haskell.org/ghc/#graph/tests/alloc/T5837 it was commit a48de37dcca98e7d477040b0ed298bcd1b3ab303 Author: Sergei TrofimovichDate: Thu Sep 1 17:34:58 2016 +0100 restore -fmax-worker-args handling (Trac #11565) Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nome...@debian.org 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