- User Since
- Jun 6 2014, 3:01 AM (214 w, 6 d)
Yes, as I wrote in the description of the PR: This is a pre-note preview :-)
Tue, Jul 17
BTW, we really should rename SigTv. The name comes from Pattern Signature, I believe (which with this patch no longer applies), and it is very easy to confuse this with SigmaTv, i.e. a poly type meta variable. But in a separate refactoring commit, of course.
Update more test output
Jun 9 2018
fibheaps allocations -4.82%. Yay!
Jun 3 2018
May 22 2018
May 21 2018
Hmm, Harbormaster seems to be slow right now… build has been running for 9h…
I was only uploading this for the harbormaster run, but thanks for the review anyways :-)
May 8 2018
May 1 2018
Apr 30 2018
Apr 24 2018
Apr 23 2018
Apr 19 2018
Apr 11 2018
Apr 10 2018
Seems to work now:
Running 1 test suites... Test suite tests: RUNNING... Test case Dumb vs. Dietz and Sleator O(log n) amortized time: Pass Test suite tests: PASS
(This is current GHC’s master)
Apr 9 2018
I pushed this as b14c03737574895718eed786a60dfdfd42ab49ce (somehow Phab did not notice).
Apr 8 2018
Apr 3 2018
JFTR, pretty good outcome for VS:
Mar 22 2018
Mar 18 2018
Feb 12 2018
This commit increases allocations in two instances:
Is that avoidable?
Jan 29 2018
Jan 26 2018
Jan 25 2018
- Merge remote-tracking branch 'origin/master' into wip/14691
- Update test suite output due to Trac #14691
I'm not sure why you are using EvExpr where previously we had EvTerm in quite a few places. That statically says "can't be Typable`. Is that the goal? Why di did you make this change?
Glad to see that the “Switch Plan” abstraction that I built a while ago makes changes like this so concise and simple :-)
Jan 23 2018
Not sure what to make of the test failures:
--- "/tmp/ghctest-ia0pyweb/test spaces/./indexed-types/should_fail/T8129.run/T8129.stdout.normalised" 2018-01-23 18:55:19.970369918 +0000 +++ "/tmp/ghctest-ia0pyweb/test spaces/./indexed-types/should_fail/T8129.run/T8129.run.stdout.normalised" 2018-01-23 18:55:19.970369918 +0000 @@ -1,3 +1,3 @@ • Could not deduce (C x0 (F x0)) • Could not deduce (C x0 (F x0)) - • Could not deduce (C x0 (F x0)) + \ \\226\\128\\162 Could not deduce (C x0 (F x0))\n\ Actual stdout output differs from expected: *** unexpected failure for T8129(normal) peak_megabytes_allocated value is too high: Expected T1969(normal) peak_megabytes_allocated: 61 +/-20% Lower bound T1969(normal) peak_megabytes_allocated: 48 Upper bound T1969(normal) peak_megabytes_allocated: 74 Actual T1969(normal) peak_megabytes_allocated: 78 Deviation T1969(normal) peak_megabytes_allocated: 27.9 % *** unexpected stat test failure for T1969(normal) 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) Expected Naperian(optasm) bytes allocated: 2381935784 +/-10% Lower bound Naperian(optasm) bytes allocated: 2143742205 Upper bound Naperian(optasm) bytes allocated: 2620129363 Actual Naperian(optasm) bytes allocated: 53576760 Deviation Naperian(optasm) bytes allocated: -97.8 %
Jan 17 2018
Jan 7 2018
Jan 2 2018
Thanks, updated and pushed. I did not add an example about the casts to not bloat the note, and also since the discussion at Trac #14610 is not completely conclusive yet.
Dec 19 2017
Dec 18 2017
Nov 21 2017
If this derives from https://anonscm.debian.org/cgit/pkg-haskell/DHG_packages.git/tree/p/ghc/debian/patches/reproducible-tmp-names the I claim partial credit for it :-)
Nov 8 2017
Oct 29 2017
Oct 28 2017
Remove the final inlining from this DR, so that maybe we can first merge
exitification, and then see if we do want to inline in the end or not.
Use setInScopeFromE as advised
Ah, I wonder: Previously, floats were part of the SimplEnvt, but in patch 33452d3fc you removed that. Now only these fields are left in a SimplEnv: seMode, seTvSubst, seCvSubst, seIdSubst and seIdSubst. Does this explain the setInScopeFromE business, and also why it might be obsolete now?
Oct 27 2017
Add note about placement
*Note [Placement of the exitification pass]*
Oct 26 2017
Found it, there was a bug with shadowing in the simplifier. Since it is independent, I submitted a separate DR for it. Simon, can you have a quick look at it? It’s here: https://phabricator.haskell.org/D4130
While experimenting with different positions, I triggered another Core Lint error; something is not properly renamed it seems:
Oct 25 2017
That is embarrassing imperative code for something as nice as a mapAccumR. Is there no way nice functional way of implementing this?
I got distracted by finding the right position for Exitification. It seems that Exitification after demand analysis yields better results than Exitification before the main simplifier phase, and the same results than doing it in both places. So I’ll do that.
Oct 24 2017
Let’s see if that was the last bug…
- Exitification: In simplLetUnfolding, set noUnfolding for exitJoinPoint
Sigh. It never ends.
Rebased, squashed and added a test case. If Phabricator is happy with this,
I’ll go ahead and merge it into master.
Oct 23 2017
- Exitification: Preserve exit points in all but the final iteration
- Exitifcation: Experimenting with position in SimplCore
So it turned out that at some point I broke “inlining in the final iteration” and inlined in the wrong iterations. Nevertheless, the bisecting done in the earlier comments was done using an older version of my branch that did not have that bug yet. In particular, some interaction with the Mighty Inliner patch does exist. The interaction seems to require a better (later?) placement of the Exitification pass, so I am experimenting with that right now, and try to see if there is a single placement that yields all the benefits that we want.
@bgamari, are you happy with the changes to the sphinx extension? I guess you’ll be the one that has to maintain it in the long run, so the DR is here mostly for that.
After a weekend of heating my house with nofib runs, I conclude that before rGHC33452dfc6cf891b59d63fa9fe138b18cbce4df81 (“Refactor the Mighty Simplifier”) exitification eliminates the allocations in fannkuch-redux, and afterwards it doesn’t. So there is some unwanted interaction. But this is a mighty large patch! I guess I will have to sit down some time and either understand it properly, or look at my exitification examples again and trace why they don’t work any more. Maybe joinpoints get inlined again somehow?
Oct 22 2017
Indeed, if I rebase the old patch onto current master 99c61e22 (which is then called 1576cc42 – that commit id is not pushed anywhere), then Exitification no longer eliminates the allocations in fannkuch-redux and k-nucleotide. So one of the 374 commits in between has some unfortunate interaction with my branch…
(I hope it’s ok to use this as my research note book. It proved useful at least to me in the past to be able to retrace my steps).
Program Size Allocs Instrs Reads Writes -------------------------------------------------------------------------------- binary-trees +0.1% 0.0% -6.6% -8.3% -5.2% fannkuch-redux +0.1% -100.0% -1.1% +13.3% -4.4% k-nucleotide +0.1% -91.8% -5.9% -5.0% -19.2% scs -0.2% -0.0% -2.8% -3.1% -2.1% spectral-norm +0.1% -0.0% -2.7% -14.3% -33.3% -------------------------------------------------------------------------------- Min -0.2% -95.0% -6.6% -14.3% -33.3% Max +0.1% +0.6% +3.3% +13.3% +2.7% Geometric Mean +0.0% -4.7% -0.2% -0.1% -0.6%
This is better again (this is fee253fc..9239e54a, slow, cachegrind). We see the allocation-free loop in fannkuch-redux and k-nucleotide, and it also kicks in in some other cases. Intriguing that Writes go down but Reads go up.