D808 progress report

[Simon Peyton Jones]

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.

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