Trying to speedup GHC compile times...Help!

[Simon Peyton Jones]

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-bounces at haskell.org> On Behalf Of Viktor Dukhovni
|  Sent: 02 July 2021 15:30
|  To: ghc-devs at 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 at 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