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
