D808 progress report

Wed Dec 9 05:05:07 UTC 2015

I've just updated the nokinds-dev branch with the latest. It should compile with bootstrapping from 7.8. 

Haddock should also compile, but only after doing this from utils/haddock:

 > git remote add goldfire git://github.com/goldfirere/haddock.git
 > git fetch goldfire

For some reason, I couldn't push a wip/rae-nokinds branch to haddock.git at git.haskell.org.

I'm also still hitting the out-of-memory error when posting to Phab. :(

Nothing particularly interesting to report otherwise. I still have hope that I'll be able to validate cleanly (modulo performance) by Wed evening.

Thanks,
Richard

On Dec 8, 2015, at 9:35 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:

> 
> 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
>> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs