RE: Pusing to haddock

[Ben Gamari]

Simon Peyton Jones  writes:

> |  tests/alloc/haddock.Cabal  11811321368 + 6.40% 12567003040
> | bytes
> |  tests/alloc/haddock.compiler   60211764264 + 7.39%
> | 64658444232 bytes
> |  
> |  The haddock stats changes are probably genuine, I assume, but the
> |  expected value in all.T should be updated.
> |  
>
> I'm sad about this. My changes should have had no visible performance
> impact. But I'm not set up to dig into why this one patch might have
> had such large impact on Haddock. Presumably it's not Haddock per-se
> but perhaps the GHC session that it invokes.
>
> I am not sure what to do... I'm quite reluctant to cause a 7%
> regression in allocation without investigation. I suppose I or someone
> should investigate before-and-after, but I don't have time to do that
> this week.
>
> If someone felt able to have a go, that'd be fantastic. Otherwise
> let's at least make a ticket.
>
> For the record, the series of patches, one of which presumably causes
> the regression, is below. Bisecting to the right one would be very
> helpful -- but you have to apply the final one (haddock-update) first.
>
I've opened #12191 to track this. I'll try to get to it although I have
a friend visiting at the moment so time will be a bit tight until
Thursday.

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: Pusing to haddock

[Joachim Breitner]

Hi,

Am Dienstag, den 14.06.2016, 08:18 + schrieb Simon Peyton Jones:
> For the record, the series of patches, one of which presumably causes
> the regression, is below.   Bisecting to the right one would be very
> helpful -- but you have to apply the final one (haddock-update)
> first.

I added a hack to the script that runs perf.haskell.org to cherry-pick
this final patch if it is told to build something from that version
range, and re-started the build of the affected commits. This should
narrow it down. Will report back.

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: Pusing to haddock

[Simon Peyton Jones]

|  tests/alloc/haddock.Cabal    11811321368 + 6.40% 12567003040
|   bytes
|  tests/alloc/haddock.compiler 60211764264 + 7.39%
|   64658444232 bytes
|  
|  The haddock stats changes are probably genuine, I assume, but the
|  expected value in all.T should be updated.
|  

I'm sad about this. My changes should have had no visible performance impact. 
But I'm not set up to dig into why this one patch might have had such large 
impact on Haddock.  Presumably it's not Haddock per-se but perhaps the GHC 
session that it invokes.

I am not sure what to do... I'm quite reluctant to cause a 7% regression in 
allocation without investigation.  I suppose I or someone should investigate 
before-and-after, but I don't have time to do that this week.

If someone felt able to have a go, that'd be fantastic.  Otherwise let's at 
least make a ticket. 

For the record, the series of patches, one of which presumably causes the 
regression, is below.   Bisecting to the right one would be very helpful -- but 
you have to apply the final one (haddock-update) first.

Sigh.  I should be more careful.

Simon



commit d55a9b4fd5a3ce24b13311962bca66155b17a558
Author: Simon Peyton Jones 
Date:   Mon Jun 13 18:28:30 2016 +0100

Update Haddock to follow change in LHsSigWcType

Update submodule to accompany this commit:

commit 15b9bf4ba4ab47e6809bf2b3b36ec16e502aea72
Author: Simon Peyton Jones 
Date:   Sat Jun 11 23:49:27 2016 +0100

Improve typechecking of let-bindings

Sorry it's late!

commit 0497ee504cc9ac5d6babee9b98bf779b3fc50b98
Author: Bartosz Nitka 
Date:   Thu Jun 9 08:50:32 2016 -0700

Make the Ord Module independent of Unique order

The `Ord Module` instance currently uses `Unique`s for comparison.
We don't want to use the `Unique` order because it can introduce 
nondeterminism.
This switches `Ord ModuleName` and `Ord UnitId` to use lexicographic 
ordering
making `Ord Module` deterministic transitively.

I've run `nofib` and it doesn't make a measurable difference.

See also Note [ModuleEnv determinism and performance].

Test Plan:
./validate
run nofib: P112

Reviewers: simonpj, simonmar, austin, bgamari

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D2030

GHC Trac Issues: #4012

commit 586d55815401c54f4687d053fb033e53865e0bf1
Author: Bartosz Nitka 
Date:   Mon Jun 13 07:35:32 2016 -0700

Use UniqFM for SigOf

Summary:
The Ord instance for ModuleName is currently implemented in
terms of Uniques causing potential determinism problems.
I plan to change it to use the actual FastStrings and in
preparation for that I'm switching to UniqFM where it's
possible (you need *one* Unique per key, and you can't get
the keys back), so that the performance doesn't suffer.

Test Plan: ./validate

Reviewers: simonmar, austin, ezyang, bgamari

Reviewed By: bgamari

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D2320

GHC Trac Issues: #4012

commit 7de776cfe7825fca6a71fe6b3854c3c86bf9ca12
Author: Bartosz Nitka 
Date:   Mon Jun 13 04:53:43 2016 -0700

Kill unused foldModuleEnv

With the current implementation, it's nondeterministic
because Ord Module is nondeterministic.

commit 5cee88d766723929f789ffcd2ef24d8b5ef62a16
Author: Tamar Christina 
Date:   Mon Jun 13 13:29:17 2016 +0200

Add thin library support to Windows too

Summary:
Code already existed in the RTS to add thin library support for non-Windows
operating systems. This adds it to Windows as well.

ar thin libraries have the exact same format as normal archives except they
have a different magic string and they don't copy the object files into the
archive.

Instead each header entry points to the location of the object file on disk.
This is useful when a library is only created to satisfy a compile time 
dependency
instead of to be distributed. This saves the time required for copying.

Test Plan: ./validate and new test T11788

Reviewers: austin, bgamari, simonmar, erikd

Reviewed By: bgamari, simonmar

Subscribers: thomie, #ghc_windows_task_force

Differential Revision: https://phabricator.haskell.org/D2323

GHC Trac Issues: #11788

commit 1dcb32ddba605bced2e0e0ce3f52b58e8ff33f5b
Author: Simon Peyton Jones 
Date:   Mon Jun 13 12:02:54 2016 +0100

A second test for Trac #12055

This one omits the extension, thereby making GHC 8.0 produce
"GHC internal error".

commit 921ebc9f0854d033cbafd43d3b2c5ba679c27b3c
Author: Simon Peyton Jones 
Date:   Mon Jun 13 11:56:44 

Re: Pusing to haddock

[Joachim Breitner]

Hi,

Am Montag, den 13.06.2016, 22:54 + schrieb Simon Peyton Jones:
> I hope that should settle things.

it does, but unfortunately, now perf.haskell.org can only give
aggregate results for the joint commit:

Benchmark name  previous    change  now 
nofib/time/fannkuch-redux   2.838   + 3.74% 2.944   seconds
nofib/time/scs  0.338   - 3.55% 0.326   seconds
testsuite/expected failures 114 + 1 115 tests
testsuite/unexpected failures   1   - 1 0   tests
testsuite/unexpected stats  0   + 2 2   tests
tests/alloc/haddock.Cabal   11811321368 + 6.40% 12567003040 
bytes
tests/alloc/haddock.compiler    60211764264 + 7.39% 64658444232 
bytes

Both the fannkuch-redux and the scs improvement are probably not
interesting; both merely goes back to the state before Simon’s NUMA
patch, which indicates a performance cliff (discussed
at https://phabricator.haskell.org/rGHC9e5ea67e268be2659cd30ebaed7044d298198ab0)

The haddock stats changes are probably genuine, I assume, but the
expected value in all.T should be updated.

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: Pusing to haddock

[Simon Peyton Jones]

| if you look in the 'packages' text-file at the top of GHC's source-tree,
| you'll notice that haddock's upstream repo is declared as
| ssh://g...@github.com/haskell/haddock.git
| 
| And you should have permission to push there.

Oh yes, thanks -- I'd forgotten that AGAIN.

I have now pushed to both the Haddock repo, and the submodule update to master. 
I hope that should settle things.

Ben you can stand down.

Simon

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Pusing to haddock

[Herbert Valerio Riedel]

On 2016-06-13 at 23:44:14 +0200, Ben Gamari wrote:
> Simon Peyton Jones  writes:
>> Devs,
>> I want to push to the haddock repo, to fix the build.  But I can’t.
>> .git/modules/utils/haddock/ contains
>>
>> [remote "origin"]
>>
>>url = git://git.haskell.org/haddock.git
>>
>> pushurl = ssh://g...@git.haskell.org/haddock.git

well, that's incorrect...

if you look in the 'packages' text-file at the top of GHC's source-tree,
you'll notice that haddock's upstream repo is declared as
ssh://g...@github.com/haskell/haddock.git

And you should have permission to push there.

git.haskell.org/haddock.git is a mirror of the GitHub repo

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Pusing to haddock

[Simon Peyton Jones]

| Hmm, I suspect this means that you (or perhaps just this key?) don't
| have push permission to the haskell.org Haddock repository. We should
| rectify this. Herbert, could you verify this when you get a chance?

I'm sure I used to be able to. I know I've done this before.

| > What now? I attach the patch if someone else would like to push. If
| > you do, update ghc HEAD to match
| 
| I'll take care of this.

Thanks.  All builds currently broken because of this.. my fault, sorry!

Simon

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Pusing to haddock

[Ben Gamari]

Simon Peyton Jones  writes:

> Devs,
> I want to push to the haddock repo, to fix the build.  But I can’t.
> .git/modules/utils/haddock/ contains
>
> [remote "origin"]
>
>url = git://git.haskell.org/haddock.git
>
> pushurl = ssh://g...@git.haskell.org/haddock.git
>
>fetch = +refs/heads/*:refs/remotes/origin/*
> I’m on branch ghc-head.  But when I push I get
>
> /cygdrive/c/code/HEAD/utils/haddock$ git push
>
> remote: W refs/heads/ghc-head haddock simonpj DENIED by refs/.*
>
> remote: error: hook declined to update refs/heads/ghc-head
>
> To ssh://g...@git.haskell.org/haddock.git
>
> ! [remote rejected] ghc-head -> ghc-head (hook declined)
>
> error: failed to push some refs to 'ssh://g...@git.haskell.org/haddock.git'
> No info on WHY it rejected.
> 
Hmm, I suspect this means that you (or perhaps just this key?) don't
have push permission to the haskell.org Haddock repository. We should
rectify this. Herbert, could you verify this when you get a chance?

> What now? I attach the patch if someone else would like to push. If
> you do, update ghc HEAD to match

I'll take care of this.

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

Pusing to haddock

[Simon Peyton Jones]

Devs,
I want to push to the haddock repo, to fix the build.  But I can’t.
.git/modules/utils/haddock/ contains

[remote "origin"]

   url = git://git.haskell.org/haddock.git

pushurl = ssh://g...@git.haskell.org/haddock.git

   fetch = +refs/heads/*:refs/remotes/origin/*
I’m on branch ghc-head.  But when I push I get

/cygdrive/c/code/HEAD/utils/haddock$ git push

remote: W refs/heads/ghc-head haddock simonpj DENIED by refs/.*

remote: error: hook declined to update refs/heads/ghc-head

To ssh://g...@git.haskell.org/haddock.git

! [remote rejected] ghc-head -> ghc-head (hook declined)

error: failed to push some refs to 'ssh://g...@git.haskell.org/haddock.git'
No info on WHY it rejected.
What now?  I attach the patch if someone else would like to push.  If you do, 
update ghc HEAD to match
Simon




spj-haddock-patch
Description: spj-haddock-patch
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs