<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Great presentation, Csaba!</p>
<p>I definitely strongly agree in broad terms that these are the
overlooked big questions we should be asking.</p>
<p>On the is last point, not only can we find a middle ground we
like best, we can also do the full spectrum. I know something that
many people I've talked to would like is a "compilation server" of
sorts that just keeps on optimizing, building up a bigger database
of knowledge of spitting out better binaries the longer you keep
it running. If I understand correctly, a datalog-based method with
very good properties re incrementality and monotonicity should be
the perfect architecture for this.</p>
<p>Cheers,</p>
<p>John<br>
</p>
<div class="moz-cite-prefix">On 1/11/21 8:17 AM, Csaba Hruska wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CANjChErkOyFs0TbcH3k7rT6rzUzZhu-uZpmqyHwkYohj=jMArA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Sure, some require whole-program analysis. But I really do
not worry about it, because what I'd like to build is an
engineering vehicle. Where a single optimization idea could be
built in several ways with different tradeoffs. Then the sweet
spot could be found after an in depth investigation of the
problem domain.<br>
</div>
<div>I.e. removing all indirect calls surely require whole
program defunctionalization, but a significant reduction of
indirect calls could be achieved with other techniques that
does not require whole program analysis. But it is totally
valuable to compare the two approaches just to know the
tradeoffs even if only one of them is applicable in practice.</div>
<div><br>
</div>
<div>Csaba<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Jan 11, 2021 at 1:51
PM Simon Peyton Jones <<a
href="mailto:simonpj@microsoft.com" moz-do-not-send="true">simonpj@microsoft.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="overflow-wrap: break-word;" lang="EN-GB">
<div class="gmail-m_-2287421066628245625WordSection1">
<p class="MsoNormal"
style="margin-right:0cm;margin-bottom:6pt;margin-left:36pt">
I may not emphasize in the talk, but the goal of the
grin compiler project is to build a compiler pipeline
that allows easy experimentation of different
compilation techniques. Anything between whole program
compilation to per module incremental codegen. So the
whole program compilation is not really a requirement
but an option.</p>
<p class="MsoNormal"><span>Right – but <i>some</i>
optimisations absolutely require whole-program
analysis, don’t they? I’m thinking of flow analyses
that support defunctionalisation, when you must know
all the lambdas that could be bound to `f` in the
definition of `map` for example.</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>Such optimisations are
powerful, but brittle because they are simply
inapplicable without whole-program analysis. Or maybe
you can find ways to make them more resilient.</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>Simon</span></p>
<p class="MsoNormal"><span> </span></p>
<div style="border-color:currentcolor currentcolor
currentcolor blue;border-style:none none none
solid;border-width:medium medium medium
1.5pt;padding:0cm 0cm 0cm 4pt">
<div>
<div style="border-color:rgb(225,225,225) currentcolor
currentcolor;border-style:solid none
none;border-width:1pt medium medium;padding:3pt 0cm
0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span
lang="EN-US"> ghc-devs <<a
href="mailto:ghc-devs-bounces@haskell.org"
target="_blank" moz-do-not-send="true">ghc-devs-bounces@haskell.org</a>>
<b>On Behalf Of </b>Csaba Hruska<br>
<b>Sent:</b> 11 January 2021 12:19<br>
<b>To:</b> Sebastian Graf <<a
href="mailto:sgraf1337@gmail.com"
target="_blank" moz-do-not-send="true">sgraf1337@gmail.com</a>><br>
<b>Cc:</b> GHC developers <<a
href="mailto:ghc-devs@haskell.org"
target="_blank" moz-do-not-send="true">ghc-devs@haskell.org</a>><br>
<b>Subject:</b> Re: presentation: Next-gen
Haskell Compilation Techniques</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<div>
<div>
<p class="MsoNormal"
style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
Hi Sebastian,</p>
</div>
<div>
<p class="MsoNormal"
style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
</p>
</div>
<div>
<p class="MsoNormal"
style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
Thanks for your feedback.</p>
</div>
<div>
<p class="MsoNormal"
style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
I know that CIB and Perceus have issues with
cycles, but these systems are still in development
so who knows what will be the conclusion.</p>
</div>
<div>
<p class="MsoNormal"
style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
I may not emphasize in the talk, but the goal of
the grin compiler project is to build a compiler
pipeline that allows easy experimentation of
different compilation techniques. Anything between
whole program compilation to per module
incremental codegen. So the whole program
compilation is not really a requirement but an
option.</p>
</div>
<div>
<p class="MsoNormal"
style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
</p>
</div>
<div>
<p class="MsoNormal"
style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
Cheers,</p>
</div>
<div>
<p class="MsoNormal"
style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
Csaba</p>
</div>
</div>
<p class="MsoNormal"
style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
</p>
<div>
<div>
<p class="MsoNormal"
style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
On Sun, Jan 10, 2021 at 1:58 PM Sebastian Graf
<<a href="mailto:sgraf1337@gmail.com"
target="_blank" moz-do-not-send="true">sgraf1337@gmail.com</a>>
wrote:</p>
</div>
<blockquote style="border-color:currentcolor
currentcolor currentcolor
rgb(204,204,204);border-style:none none none
solid;border-width:medium medium medium
1pt;padding:0cm 0cm 0cm
6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"
style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
Hi Csaba,</p>
</div>
<div>
<p class="MsoNormal"
style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
</p>
</div>
<div>
<p class="MsoNormal"
style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
Thanks for your presentation, that's a nice
high-level overview of what you're up to.</p>
</div>
<div>
<p class="MsoNormal"
style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
</p>
</div>
<div>
<p class="MsoNormal"
style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
A few thoughts:</p>
</div>
<div>
<ul type="disc">
<li class="MsoNormal">
Whole-program optimization sounds great, but
also very ambitious, given the amount of
code GHC generates today. I'd be amazed to
see advances in that area, though, and your
>100-module CFA performance incites hope!</li>
<li class="MsoNormal">
I wonder if going through GRIN results in a
more efficient mapping to hardware. I
recently found that the code GHC generates
is dominated by administrative traffic from
and to the heap [1]. I suspect that you can
have big wins here if you manage to convey
better call stack, heap and alias
information to LLVM.</li>
<li class="MsoNormal">
The Control Analysis+specialisation approach
sounds pretty similar to doing Constructor
Specialisation [2] for Lambdas (cf. 6.2) if
you also inline the function for which you
specialise afterwards. I sunk many hours
into making that work reliably, fast and
without code bloat in the past, to no avail.
Frankly, if you can do it in GRIN, I don't
see why we couldn't do it in Core. But maybe
we can learn from the GRIN implementation
afterwards and maybe rethink SpecConstr.
Maybe the key is not to inline the function
for which we specialise? But then you don't
gain that much...</li>
<li class="MsoNormal">
I follow the Counting Immutable Beans [3]
stuff quite closely (Sebastian is a
colleague of mine) and hope that it is
applicable to Haskell some day. But I think
using Perceus, like any purely RC-based
memory management scheme, means that you
can't have cycles in your heap, so no loopy
thunks (such as constant-space `ones =
1:ones`) and mutability. I think that makes
a pretty huge difference for many use cases.
Sebastian also told me that they have to
adapt their solutions to the cycle
restriction from time to time, so far always
successfully. But it comes at a cost: You
have to adapt the code you want to write
into a form that works.</li>
</ul>
<div>
<p class="MsoNormal">I only read the slides,
apologies if some of my points were
invalidated by something you said.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Keep up the good work!</p>
</div>
<div>
<p class="MsoNormal">Cheers,</p>
</div>
<div>
<p class="MsoNormal">Sebastian</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">[1] <a
href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F19113&data=04%7C01%7Csimonpj%40microsoft.com%7C0a889669aa404e4b938008d8b62b23f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637459644503167010%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0W9ejmKCDKpuBT0mEArvIwAmHDUS4QI9kc5j%2BhGUX5I%3D&reserved=0"
target="_blank" moz-do-not-send="true">
https://gitlab.haskell.org/ghc/ghc/-/issues/19113</a></p>
</div>
<div>
<p class="MsoNormal">[2] <a
href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.microsoft.com%2Fen-us%2Fresearch%2Fwp-content%2Fuploads%2F2016%2F07%2Fspec-constr.pdf&data=04%7C01%7Csimonpj%40microsoft.com%7C0a889669aa404e4b938008d8b62b23f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637459644503177005%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=8wJJXOpNuaQpjOWBTwbQ0upeOj1LLXSUD86cn8TbKI8%3D&reserved=0"
target="_blank" moz-do-not-send="true">
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/spec-constr.pdf</a></p>
</div>
<div>
<p class="MsoNormal">[3] <a
href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Farxiv.org%2Fabs%2F1908.05647&data=04%7C01%7Csimonpj%40microsoft.com%7C0a889669aa404e4b938008d8b62b23f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637459644503186998%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=LCFO8R5SZT0KveoB9GyPcMpwbhU9DTLOnYhxD%2FZNXxU%3D&reserved=0"
target="_blank" moz-do-not-send="true">
https://arxiv.org/abs/1908.05647</a></p>
</div>
</div>
</div>
<p class="MsoNormal"> </p>
<div>
<div>
<p class="MsoNormal">Am So., 10. Jan. 2021 um
00:31 Uhr schrieb Csaba Hruska <<a
href="mailto:csaba.hruska@gmail.com"
target="_blank" moz-do-not-send="true">csaba.hruska@gmail.com</a>>:</p>
</div>
<blockquote style="border-color:currentcolor
currentcolor currentcolor
rgb(204,204,204);border-style:none none none
solid;border-width:medium medium medium
1pt;padding:0cm 0cm 0cm
6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal">Hello,</p>
</div>
<div>
<p class="MsoNormal">I did an online
presentation about Haskell related
(futuristic) compilation techniques.</p>
</div>
<div>
<p class="MsoNormal">The application of
these methods is also the main motivation
of my work with the grin compiler project
and ghc-wpc.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">video: <a
href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DjyaR8E325ok&data=04%7C01%7Csimonpj%40microsoft.com%7C0a889669aa404e4b938008d8b62b23f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637459644503196994%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=dbxjJKAKqZJZ2jdYE2aR6ymQIp9awCmOHwsBAHLz9AM%3D&reserved=0"
target="_blank" moz-do-not-send="true">
https://www.youtube.com/watch?v=jyaR8E325ok</a></p>
</div>
<div>
<p class="MsoNormal">slides: <a
href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fpresentation%2Fd%2F1g_-bHgeD7lV4AYybnvjgkWa9GKuP6QFUyd26zpqXssQ%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Csimonpj%40microsoft.com%7C0a889669aa404e4b938008d8b62b23f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637459644503196994%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=UHHOI6Nr80zuDrFDPVUz6wsNXKlxY06%2B5tG%2BCxf847I%3D&reserved=0"
target="_blank" moz-do-not-send="true">
https://docs.google.com/presentation/d/1g_-bHgeD7lV4AYybnvjgkWa9GKuP6QFUyd26zpqXssQ/edit?usp=sharing</a></p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Regards,</p>
</div>
<div>
<p class="MsoNormal">Csaba</p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org"
target="_blank" moz-do-not-send="true">ghc-devs@haskell.org</a><br>
<a
href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=04%7C01%7Csimonpj%40microsoft.com%7C0a889669aa404e4b938008d8b62b23f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637459644503206993%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BAdAJUowngbDQt7BMX43JegOeUNMfh%2B00VYYBVyTPN0%3D&reserved=0"
target="_blank" moz-do-not-send="true">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a></p>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
ghc-devs mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a>
</pre>
</blockquote>
</body>
</html>