But if we generate identical Core after desugaring there just aren't any downstream changes. Or are there?
| -----Original Message----- | From: Richard Eisenberg [mailto:[email protected]] | Sent: 08 December 2015 14:35 | To: Simon Peyton Jones <[email protected]> | Cc: Ben Gamari <[email protected]>; Austin Seipp <[email protected]>; | [email protected] | Subject: Re: D808 progress report | | | On Dec 8, 2015, at 7:22 AM, Simon Peyton Jones <[email protected]> | 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:[email protected]] | > | Sent: 08 December 2015 03:35 | > | To: Simon Peyton Jones <[email protected]>; Ben Gamari | > | <ben@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 <[email protected]> | > | 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 [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
