D808 progress report
Richard Eisenberg
eir at cis.upenn.edu
Tue Dec 8 14:35:27 UTC 2015
On Dec 8, 2015, at 7:22 AM, Simon Peyton Jones <simonpj at microsoft.com> 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:eir at cis.upenn.edu]
> | Sent: 08 December 2015 03:35
> | To: Simon Peyton Jones <simonpj at microsoft.com>; Ben Gamari <ben at well-
> | typed.com>; Austin Seipp <aseipp at pobox.com>
> | 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
>
More information about the ghc-devs
mailing list