D808 progress report

[Richard Eisenberg]

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
>