I love "Scrap Your Type Applications" (SYTA) too, although I'm a little biased since I'm a co-author.
But SYTA is a change that has a pretty pervasive effect on the way GHC manipulates types. Since then we've added TypeInType, from which a lot of consequences flowed. I simply don't know how hard it'd be to do a "scrap your type applications" job on GHC today. I agree that the cost/benefit tradeoff could have shifted. We can only find out by trying it. But trying it would take quite a lot of work. On the other hand, SYTA is the only principled approach that I know of that solves the type blow-up we get with deeply-nested data types (notoriously, tuples). It's a problem we have known of for decades, but is still essentially unsolved. Simon | -----Original Message----- | From: ghc-devs <ghc-devs-boun...@haskell.org> On Behalf Of Viktor Dukhovni | Sent: 02 July 2021 15:30 | To: ghc-devs@haskell.org | Subject: Re: Trying to speedup GHC compile times...Help! | | On Fri, Jul 02, 2021 at 08:08:39AM +0000, Simon Peyton Jones via ghc-devs | wrote: | | > I strongly urge you to keep a constantly-update status wiki page, | > which lists the ideas you are working on, and points to relevant | > resources and tickets. An email thread like this is a good way to | > gather ideas, but NOT a good way to organise and track them. | | I remain curious as to whether "Scrap your type applications" is worth a | second look. There are edge cases in which compile time blowup is a result | of type blowup (as opposed to code blowup via inlining). Might GHC have | changed enough in the last ~5 years to make it now "another | compiler": | | | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.micros | oft.com%2Fen-us%2Fresearch%2Fwp- | content%2Fuploads%2F2016%2F07%2Fif.pdf&data=04%7C01%7Csimonpj%40microsof | t.com%7C7effa9c7dd004554fdf408d93d6626f0%7C72f988bf86f141af91ab2d7cd011db47% | 7C1%7C0%7C637608331663562915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ | QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=brNlPRnQgHqbTSO | AOs9hbZOdC84VZfhfnO8g%2BtwSKOQ%3D&reserved=0 | | (Section 4.4): | | Overall, allocation decreased by a mere 0.1%. The largest reduction was | 4%, and the largest increase was 12%, but 120 of the 130 modules showed | a | change of less than 1%. Presumably, the reduction in work that arises | from smaller types is balanced by the additional overheads of SystemIF. | On this evidence, the additional complexity introduced by the new | reduction rules does not pay its way. Nevertheless, these are matters | that are dominated by nitty-gritty representation details, and the | balance might well be different in another compiler. | | Could it be that some of the more compile time intensive packages on hackage | (aeson, vector, ...) would benefit more than the various modules in base? | | Wild speculation aside, of course finding and fixing inefficiencies in the | implementation of existing common primitive should be a win across the | board, and should not require changing major compiler design features, just | leaner code. | | -- | Viktor. | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel | l.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=04%7C01%7Csimonpj%40microsoft.com%7C7effa9c7dd004554fdf408d93d | 6626f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637608331663562915%7CUnk | nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV | CI6Mn0%3D%7C3000&sdata=OYuQV%2FP3Sgly62Ex5m1kwv5ciHLchWEXq7XvvPYJCJ4%3D& | amp;reserved=0 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs