D808 progress report

[Simon Peyton Jones]

But if we generate identical Core after desugaring there just aren't any downstream changes.  Or are there?

|  -----Original Message-----
|  From: Richard Eisenberg [mailto:eir at cis.upenn.edu]
|  Sent: 08 December 2015 14:35
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: Ben Gamari <ben at well-typed.com>; Austin Seipp <aseipp at pobox.com>;
|  ghc-devs at haskell.org
|  Subject: Re: D808 progress report
|  
|  
|  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-
|  > |
|  https://na01.safelinks.protection.outlook.com/?url=typed.com&data=01
|  > |
|  %7c01%7csimonpj%40064d.mgd.microsoft.com%7cdcf30e53878843801e5908d30
|  > |
|  0335b8b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=YFFgz5PA5Oh7Ehq
|  > | qbtST23860krFwxHQrWRf4MRksyU%3d>; 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
|  >