- User Since
- Jun 6 2014, 3:01 AM (141 w, 5 d)
Runtime performance improvements in fasta and lambda:
A bit weird, isn’t it?
Thu, Feb 16
Wed, Feb 15
I have doubts about the VERBOSE setting. If increasing the verbosity can make tests fail, then that is a harsh violation of the principle of least surprise!
Sorry to jump on this after it has been commited, but I have doubts about the VERBOSE setting. If increasing the verbosity can make tests fail, then that is a harsh violation of the principle of least surprise!
Sat, Feb 11
Also recenter haddock.compiler
Update perf data.
Rebase to master
Thu, Feb 9
https://travis-ci.org/ghc/ghc/builds/200216540 looks good, thanks!
Hmm, baking in the output of a tool that is not under our control, has several implementations and may of course change its error message from versin to version does not strike me as very useful in the long run. Maybe just grep the output for TH_addCStub2.hs:13:13, assuming that at least that part stays stable?
On Travis, this causes test cases to fail: https://api.travis-ci.org/jobs/200040619/log.txt?deansi=true
Wed, Feb 8
Tue, Feb 7
I see different runtime results from nofib:
Mon, Feb 6
@nomeata looks like there's a perf regression though in the testsuite (T4029).
Sun, Feb 5
https://perf.haskell.org/ghc/#revision/fbcef83a3aa130d976a201f2a21c5afc5a43d000 reports some speed-ups, but also that some stats in the test suite might need to be adjusted
https://perf.haskell.org/ghc/#revision/a2f39da0461b5da62a9020b0d98a1ce2765dd700 reports some speed-ups!
Sat, Feb 4
From a very brief look at this, and assuming for a moment the plugin architecture allowed for hooks prior to the desugarer, would this change still be necessary
perf.haskell.org reports the absence of significant regressions: https://perf.haskell.org/ghc/#revision/b59c2de7abe3cd4e046f11c3536ba8e7137c4f84
Whoohoo! Build time down by 13%. And sizes down. Well spotted!
Redone the patch, and make mkMachInt etc. do the wrapping.
Rebase to master
I disagree with that review.
Fri, Feb 3
I have a better approach now. Do you like it?
New approach to not dropping dead code in the desugarer
Obviously I’ll push these as separate commits; but I’d like to get a quick nod from someone else before I do so.
Thu, Feb 2
Clean up some code is simpler without ProbOneShot
Wed, Feb 1
Does this have to live in a separate library? Can it not be part of base (which already has a bunch of low-level GHC. modules) or ghc-prim?
Tue, Jan 24
This had a reproducible effect of increasing runtime of fasta by +4.47%. Are runtime effects here expected?
Jan 19 2017
Good job, tests/alloc/T13056 improves by 4%!
Jan 17 2017
Jan 6 2017
Well, I expect programs that use Monad (Either s) or Functor (Either s) or similar constructs to benefit, but we might not just have them in nofib.
Yes, at https://perf.haskell.org/ghc/#revision/19d5c7312bf0ad9ae764168132aecf3696d5410b. Unfortunately, nothing significant shows up. When I tested it locally, I saw some relevant improvements with the runtime of binary-trees. I continue to conclude that our benchmark situation sucks when it comes to producing hard evidence.
Jan 5 2017
Pushed version of the DR
Yes, I think so as well. Will do that in a second.
Dec 29 2016
Dec 27 2016
Dec 26 2016
Marking a few inline-comments as “Done”
Do not rewrite case binders to trivial case scrutinees
Dec 25 2016
Dec 23 2016
More notes, use of In… and Out… types, and more careful handling of renaming due to shadowing. (Is shadowing a thing in STG?)
Dec 20 2016
Use a record for the env, general notes fine-tuning
Thanks for the review, Simon. I did change the env to a record, and refined some notes.
Ok, discussion continues at https://phabricator.haskell.org/D2883.
Dec 19 2016
@hsyl20 I am still not convinced that this is a useful test case. If case folding would suddenly stop working, would this test case really catch the regression?
Fix in comments
Dec 17 2016
Rebase onto master