I've just updated the nokinds-dev branch with the latest. It should compile with bootstrapping from 7.8.
Haddock should also compile, but only after doing this from utils/haddock: > git remote add goldfire git://github.com/goldfirere/haddock.git > git fetch goldfire For some reason, I couldn't push a wip/rae-nokinds branch to haddock.git at git.haskell.org. I'm also still hitting the out-of-memory error when posting to Phab. :( Nothing particularly interesting to report otherwise. I still have hope that I'll be able to validate cleanly (modulo performance) by Wed evening. Thanks, Richard On Dec 8, 2015, at 9:35 AM, Richard Eisenberg <[email protected]> wrote: > > On Dec 8, 2015, at 7:22 AM, Simon Peyton Jones <[email protected]> wrote: > >> Kind equalities are the Big New Thing in 8.0. Let's just get it in and deal >> with the fallout. >> >> After all, there is no reason for performance to be worse. For programs that >> 7.10 accepts, 8.0 should yield essentially the same coercions. They might >> need a bit of optimisation to squeeze them down but the result should be >> essentially identical. If not, let's investigate. > > Yes. Modulo levity polymorphism, I agree. However, I just can't find a > "smoking gun" in any of the profiling that might indicate what's causing the > regressions. It seems to be that everything is just a bit more sluggish. Of > course, what that suggests is that there is some low-level function, used a > ton, which is slower, but I just haven't found it yet. > > Richard > >> >> I could imagine the typechecker being a bit slower, but not a lot. >> >> For T3738, compile the compiler before and after with -ticky and compare. >> >> | In light of all this, I propose the following: >> | - Scramble to fix all non-perf failures. I expect I can finish this by >> | Wed evening. >> | - Hope that one of you (or another dev) can take a look at T3738 and >> | friends. That clearly needs to get fixed. >> | - Adjust perf targets to get validation to work, clearly labeling the >> | remaining problems as the fault of type=kind. >> | - Commit to fixing #8095 in the next two weeks. But probably not by >> | early next week, I'm afraid. >> | >> >> In short, yes. >> >> Simon >> >> >> | -----Original Message----- >> | From: Richard Eisenberg [mailto:[email protected]] >> | Sent: 08 December 2015 03:35 >> | To: Simon Peyton Jones <[email protected]>; Ben Gamari <ben@well- >> | typed.com>; Austin Seipp <[email protected]> >> | Subject: D808 progress report >> | >> | Hi Simon, Ben, Austin, >> | >> | First, the bad news: >> | I'm a bit stalled on performance issues. When I sent my earlier email, >> | I was celebrating having gotten one test case from 319M of allocation >> | down to 182M via several seemingly general-purpose optimizations. But >> | this was with -fno-opt-coercion. Once I re-enabled coercion >> | optimization, that particular test case still fails >> | (pert/compiler/T5030), along with 22 others. This is bad. But many ~4 >> | hours of effort this evening I've made no substantive progress at all, >> | shaving off maybe 1% of allocation via a few tiny tweaks. Even >> | characterizing what's going wrong is proving difficult. I've only >> | analyzed a few of the failing tests, but each one is stubbornly >> | refusing to break, so I'm losing hope about the others. >> | >> | Then, the good news: >> | I think the idea posited in #8095 (not to bother building coercions >> | unless -dcore-lint is on) will solve all of these problems and more, >> | as long as users don't use -dcore-lint. With one exception that I've >> | noticed (see below), my performance failures aren't catastrophic: on >> | the performance tests, which tend to be pathological, my branch is >> | running 10-20% worse than HEAD. Not good, but not so bad that -dcore- >> | lint users can't cope. So, with #8095 addressed, I think we'll be OK. >> | And #8095 should be very straightforward and done in a few hours' >> | work. >> | >> | Finally, the ugly: >> | The exception to the non-catastrophic nature of the failures is this: >> | perf/should_run/T3738 fails with 3479.1% overage. (Yes, the percentage >> | is in the thousands.) Worse, this is at runtime, not in the compiler. >> | Yet the Core produced in my branch (as observed by -ddump-simpl) and >> | in HEAD appears identical. There are a few other should_run failures >> | that have me nervous, but my guess is that they're all from one >> | source. I'd love an offer of help to debug this. >> | >> | >> | In light of all this, I propose the following: >> | - Scramble to fix all non-perf failures. I expect I can finish this by >> | Wed evening. >> | - Hope that one of you (or another dev) can take a look at T3738 and >> | friends. That clearly needs to get fixed. >> | - Adjust perf targets to get validation to work, clearly labeling the >> | remaining problems as the fault of type=kind. >> | - Commit to fixing #8095 in the next two weeks. But probably not by >> | early next week, I'm afraid. >> | >> | What do we think? >> | >> | Thanks, >> | Richard >> > > _______________________________________________ > ghc-devs mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
