Re: Better perf

[Sebastian Graf]

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

[Simon Peyton Jones via ghc-devs]

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

[Joachim Breitner]

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

[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.

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

[Ben Gamari]

Simon Peyton Jones via ghc-devs  writes:

> 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

[Joachim Breitner]

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

Better perf

[Simon Peyton Jones via ghc-devs]

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/compiler/T13035.runT13035 [stat too good] (normal)

-6.4% alloc



   perf/compiler/T12425.runT12425 [stat too good] (optasm)

-6.6% alloc



   perf/compiler/T9675.run T9675 [stat too good] (optasm)

-10.4% alloc



   perf/compiler/T1969.run T1969 [stat too good] (normal)

-21% peak megabytes



   perf/space_leaks/T4029.run  T4029 [stat too good] (ghci)

-14% peak megabytes
This is good.  I did not see these in earlier validations (perhaps I did not 
rebuild the libraries sufficiently), so I have left them.  If Harbormaster 
agrees that perf has improved, could someone re-centre the numbers?  Ideally 
say which patch is responsible.
Simon
___
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)

[Simon Peyton Jones via ghc-devs]

| 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 +0000
| >
| > 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)

[Ben Gamari]

Joachim Breitner  writes:

> 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)

[Joachim Breitner]

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://perf.haskell.org/ghc/#revision/fc9d152b058f21ab03986ea722d0c94688b9969f
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/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?

[Simon Peyton Jones via ghc-devs]

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?

[Joachim Breitner]

Hi,

according to
https://perf.haskell.org/ghc/#graph/tests/alloc/T5837
it was 

commit a48de37dcca98e7d477040b0ed298bcd1b3ab303
Author: Sergei Trofimovich 
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://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

Better perf?

[Simon Peyton Jones via ghc-devs]

I’m getting this perf improvement from T5837, which is type-function heavy.  Is 
anyone else seeing this


bytes allocated value is too low:

(If this is because you have improved GHC, please

update the test so that GHC doesn't regress again)

ExpectedT5837(normal) bytes allocated: 48507272 +/-10%

Lower bound T5837(normal) bytes allocated: 43656544

Upper bound T5837(normal) bytes allocated: 53358000

Actual  T5837(normal) bytes allocated: 42384144

Deviation   T5837(normal) bytes allocated:-12.6 %

Its good, but I’d quite  like to know which patch made the difference.  Could 
it be

commit 03541cbae50f0d1cdf99120ab88698f29a278159

Author: Simon Peyton Jones 

Date:   Fri Sep 9 17:42:42 2016 +0100



Be less picky about reporing inaccessible code

Seems implausible, but possible I suppose.
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [commit: testsuite] master: Much better perf on 5030, higher peak on 3064 (53b3199)

[Simon Marlow]

On 12/11/13 15:07, g...@git.haskell.org wrote:

Repository : ssh://g...@git.haskell.org/testsuite

On branch  : master
Link   : 
http://ghc.haskell.org/trac/ghc/changeset/53b3199b03bd2e52c63babffd33d478242ae74d5/testsuite


---


commit 53b3199b03bd2e52c63babffd33d478242ae74d5
Author: Simon Peyton Jones simo...@microsoft.com
Date:   Tue Nov 12 15:06:56 2013 +

 Much better perf on 5030, higher peak on 3064

 The peak-megabytes is vulnerable to when GC runs


Juat a reminder to everyone: when peak_megabytes or max_bytes_used 
changes, please run with +RTS -h -i0.01 to get a heap profile and check 
whether it's a real change or not.  You don't need to compile for 
profiling or anything.


Cheers,
Simon

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: [commit: testsuite] master: Much better perf on 5030, higher peak on 3064 (53b3199)

[Simon Peyton-Jones]

Aha.  I've updated
https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Updating

Simon

| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon
| Marlow
| Sent: 21 November 2013 10:50
| To: ghc-devs@haskell.org
| Subject: Re: [commit: testsuite] master: Much better perf on 5030,
| higher peak on 3064 (53b3199)
| 
| On 12/11/13 15:07, g...@git.haskell.org wrote:
|  Repository : ssh://g...@git.haskell.org/testsuite
| 
|  On branch  : master
|  Link   :
| http://ghc.haskell.org/trac/ghc/changeset/53b3199b03bd2e52c63babffd33d47
| 8242ae74d5/testsuite
| 
|  ---
| 
|  commit 53b3199b03bd2e52c63babffd33d478242ae74d5
|  Author: Simon Peyton Jones simo...@microsoft.com
|  Date:   Tue Nov 12 15:06:56 2013 +
| 
|   Much better perf on 5030, higher peak on 3064
| 
|   The peak-megabytes is vulnerable to when GC runs
| 
| Juat a reminder to everyone: when peak_megabytes or max_bytes_used
| changes, please run with +RTS -h -i0.01 to get a heap profile and check
| whether it's a real change or not.  You don't need to compile for
| profiling or anything.
| 
| Cheers,
| Simon
| 
| ___
| ghc-devs mailing list
| ghc-devs@haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs