<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr">Hi Christoph,</div><div dir="ltr"><br><blockquote type="cite">On Mar 26, 2020, at 10:42 AM, Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p>Hi Eliot,</p>
<p><br>
</p>
<p>thanks for the elaborate explanation! Wow, even more things are getting blocked while we are longing for Scorch. :D Could you tell us when you expect to start making your blessing available for Squeak, only very rough? Are we speaking of months? Years? Decades?
;-)</p></div></div></blockquote><div><br></div>That will depend on if I can find a few skilled collaborators or not (too many and communication costs will overwhelm). Certainly not decades. Clément has things working. So of the order of six to twelve person months of effort.<div><br></div><div>I encourage you to look at Clément’s presentations and see if it interests you. You might be one of those people. This is a great PhD topic.<br><blockquote type="cite"><div dir="ltr"><div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p><span style="font-size: 12pt;">Here're my two cents on the story:</span></p>
<p><br>
</p>
<p>> <span>The check is to find anywhere we see a (non-optimized) block created that closes over an index variable and is passed as an argument.</span></p>
<p><span><br>
</span></p>
<p><span>Hm, what will happen with this:</span></p>
<p><span><br>
</span></p>
<p><span></span></p>
<p style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;">
1 to: 5 do: [:each |</p>
<p style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;">
[:object | object + each] in: [:block | result add: block]].</p>
<br>
<p></p>
<p>The left block is not an argument, but still it would be relevant to disable the inlining of the outer block. So your rule has to respect both receiver and arguments, am I right? This will increase the "collateral damage" of unnecessary slow down even further,
we would also have to forgo inlining for things like {[:object | object + each] cull: 42} etc.</p></div></div></blockquote><div><br></div>Quite right. Can you find out how common cases like these are? I bet you there will be five methods or less in trunk that are affected.</div><div><br><blockquote type="cite"><div dir="ltr"><div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p><span style="font-size: 12pt;">Or this one:</span></p>
<p><span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;">1 to: 5 do: [:each |</span></p>
<p style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;">
<span>[result add: thisContext sender top] value; yourself</span>].</p>
<p></p>
<p><br>
</p>
<p>And finally:</p>
<p><br>
</p>
<p></p>
<p style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;">
1 to: 5 do: [:each |</p>
<p style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;">
result add: [thisContext tempVarNamed: 'each']].</p></div></div></blockquote><div><br></div>I find these last two not compelling. If one is dealing with thisContext one is close to the implementation so I would argue you get the unvarnished reality, not the ideal specification.</div><div><br><blockquote type="cite"><div dir="ltr"><div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p></p>
<p>You can (almost) always crack the system, so - if we should decide to turn off inlining sometimes - however we do this, in each case, there will be a logical break at some position. In my humble opinion, this would cause more confusion than actually solve
problems. There has never been given a guarantee that blocks will be not inlined.</p></div></div></blockquote><div><br></div>Agreed.</div><div><br><blockquote type="cite"><div dir="ltr"><div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr"><p> If you wish to prevent this, the simplest and clearest solution IMO is still</p>
<p><br>
</p>
<p></p>
<div>1 to: 5 do: [:each |</div>
<div> result add: [:object | object + each]</div>
<div>] yourself. </div>
<p></p>
<p><br>
</p>
<p>Best,</p>
<p>Christoph</p>
<p></p>
<div id="Signature">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;">
<div name="divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Eliot Miranda <eliot.miranda@gmail.com><br>
<b>Gesendet:</b> Donnerstag, 26. März 2020 17:20:08<br>
<b>An:</b> The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] Question about inlining | How to access named temps in FullBlockClosure?</font>
<div> </div>
</div>
<div>Hi Marcel,
<div dir="ltr"><br>
<blockquote type="cite">On Mar 26, 2020, at 5:15 AM, Marcel Taeumel <marcel.taeumel@hpi.de> wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
<span style="font-size: 13.3333px">Hi Eliot, hi all!</span>
<div class="mb_sig" style="font-size: 13.3333px"></div>
<div style="font-size: 13.3333px"><br>
</div>
<div style="font-size: 13.3333px">I am having issues with the inlining of #to:do: in combination with decompiling a block and accessing the temps.</div>
<div style="font-size: 13.3333px"><br>
</div>
<div style="font-size: 13.3333px">Here is a piece of code that works as expected:</div>
<div style="font-size: 13.3333px"><br>
</div>
<div style="font-size: 13.3333px">
<div>| result context |</div>
<div>result := OrderedCollection new.</div>
<div><br>
</div>
<div><b>(1 to: 5) do</b>: [:each |</div>
<div><span style="white-space: pre;"></span>result add: [:object | object + each]].<span style="white-space: pre;">
</span></div>
<div><br>
</div>
<div>context := (result at: 3) outerContext.</div>
<div>context namedTempAt: (context tempNames indexOf: 'each').<b> " == 3"</b></div>
</div>
<div style="font-size: 13.3333px"><b><br>
</b></div>
<div style="font-size: 13.3333px">HOWEVER, using #to:do: the result changes because code gets inlined:</div>
<div style="font-size: 13.3333px"><br>
</div>
<div style="font-size: 13.3333px">
<div style="font-size: 13.3333px">| result context |</div>
<div style="font-size: 13.3333px">result := OrderedCollection new.</div>
<div style="font-size: 13.3333px"><br>
</div>
<div style="font-size: 13.3333px"><b>1 to: 5 do</b>: [:each |</div>
<div style="font-size: 13.3333px"><span style="white-space: pre;"></span>result add: [:object | object + each]].<span style="white-space: pre;">
</span></div>
<div style="font-size: 13.3333px"><br>
</div>
<div style="font-size: 13.3333px">context := (result at: 3) outerContext.</div>
<div style="font-size: 13.3333px">context namedTempAt: (context tempNames indexOf: 'each').<b> " == 6"</b></div>
</div>
<div style="font-size: 13.3333px"><b><br>
</b></div>
<div style="font-size: 13.3333px">What is my goal here? I want to unpack the block statement and fill in the temps. <span style="font-size: 13.3333px">For all those [:object | object + each] in "result" I want to collect the strings:</span></div>
<div style="font-size: 13.3333px"><span style="font-size: 13.3333px"><br>
</span></div>
<div style="font-size: 13.3333px">-> 'object + 1'</div>
<div style="font-size: 13.3333px"><span style="font-size: 13.3333px">-> 'object + 2'</span><br>
</div>
<div style="font-size: 13.3333px"><span style="font-size: 13.3333px">-> 'object + 3'</span><span style="font-size: 13.3333px"><br>
</span></div>
<div style="font-size: 13.3333px"><span style="font-size: 13.3333px">-> 'object + 4'</span><span style="font-size: 13.3333px"><br>
</span></div>
<div style="font-size: 13.3333px"><span style="font-size: 13.3333px">-> 'object + 5'</span><span style="font-size: 13.3333px"><br>
</span></div>
<div style="font-size: 13.3333px"><span style="font-size: 13.3333px"><br>
</span></div>
<div style="font-size: 13.3333px"><span style="font-size: 13.3333px">Is there a way to access the values of temps when the block closures are created this way?</span></div>
</div>
</div>
</blockquote>
<div><br>
</div>
<span style="-webkit-text-size-adjust: auto; background-color: rgb(255, 255, 255);">Nice one. So the thing to realize is that, because of inlining, the second example is in fact equivalent to</span>
<div style="-webkit-text-size-adjust: auto;">
<div dir="ltr">
<div id="__MailbirdStyleContent" style="font-size: 10pt; font-family: Arial;">
<div style="font-size: 13.3333px;"><br>
</div>
<div style="font-size: 13.3333px;">| result context each |</div>
<div style="font-size: 13.3333px;">result := OrderedCollection new.</div>
<div style="font-size: 13.3333px;"><br>
</div>
<div style="font-size: 13.3333px;"><b>each := 1.</b></div>
<div style="font-size: 13.3333px;"><b>[ each <= 5 ] whileTrue:</b></div>
<div style="font-size: 13.3333px;"> [ <span style="font-size: 13.3333px;">result add: [:object | object + each]].</span></div>
<div style="font-size: 13.3333px;">
<div dir="ltr">
<div id="__MailbirdStyleContent" style="font-size: 10pt; font-family: Arial;">
<div style="font-size: 13.3333px;">
<div style="font-size: 13.3333px;"><br>
</div>
<div style="font-size: 13.3333px;">context := (result at: 3) outerContext.</div>
<div style="font-size: 13.3333px;">context namedTempAt: (context tempNames indexOf: 'each')<b> "= 6"</b></div>
</div>
</div>
</div>
</div>
<div style="font-size: 13.3333px;"><span style="font-size: 13.3333px;"><br>
</span></div>
<div style="font-size: 13.3333px;"><span style="font-size: 13.3333px;">and when written like this it is clear that the search for the value will end up being as found, 6.</span></div>
<div style="font-size: 13.3333px;"><span style="font-size: 13.3333px;"><br>
</span></div>
<div style="font-size: 13.3333px;"><span style="font-size: 13.3333px;">So then the thing to realize is that the inlining decision is wrong. That in fact the closing over of each (the index variable of the inlined to:do:) within an uninlined inner block means
that the outer block cannot be inlined without breaking the inner block.</span></div>
<div style="font-size: 13.3333px;"><span style="font-size: 13.3333px;"><br>
</span></div>
<div style="font-size: 13.3333px;"><span style="font-size: 13.3333px;">So the next thing to determine is whether the compiler can easily be modified to identify this case and hence prevent inlining in case like these.</span></div>
<div style="font-size: 13.3333px;"><span style="font-size: 13.3333px;"><br>
</span></div>
<div style="font-size: 13.3333px;"><span style="font-size: 13.3333px;">After that we have to assess and find out how many cases in the system (eg in trunk) would no longer be inlined and decide whether the cure is worse than the disease. The issue here is
two fold, the loss of performance due to not inlining, and the slow down to compilation due to the check(s) needed to prevent inlining in this case.</span></div>
<div style="font-size: 13.3333px;"><span style="font-size: 13.3333px;"><br>
</span></div>
<div style="font-size: 13.3333px;"><span style="font-size: 13.3333px;">Why would adding the check potentially cause many to:[by:]do: invocations to no longer be inlined? The check is to find anywhere we see a (non-optimized) block created that closes over an
index variable and is passed as an argument. </span>Because this is a dynamic language we cannot assume anything about the message the block is an argument to; the programmer could redefine an implementation of a method with that selector to capture the block
argument just as your example does. So we have to assume the block could be captured, and hence that the to:[by:]do: in which it occurs cannot be inlined.</div>
<div style="font-size: 13.3333px;"><br>
</div>
<div style="font-size: 13.3333px;">Other Smalltalks have decided to live with the disease. I think that the right decision is *not* to live with the disease, but to fix the inliner, and wait for Scorch to “do the right thing” and inline dynamically. Scorch
can inline precisely because it does indeed find out about the caller, and inline if the caller does not capture the block, and adds the dependency information to enable the optimized version to be discarded if redefinition occurs.</div>
<div style="font-size: 13.3333px;"><br>
</div>
<div style="font-size: 13.3333px;"><span style="font-size: 13.3333px;">The first thing to do is write a test asserting the correct behaviour.</span></div>
<div style="font-size: 13.3333px;"><br>
</div>
<div style="font-size: 13.3333px;">The second thing to do is learn how and where the bytecode compiler decides whether or not to inline to:[by:]do:.</div>
<div style="font-size: 13.3333px;"><br>
</div>
<div style="font-size: 13.3333px;">The third thing to do is to modify that inlining decision to generate correct code for your case.</div>
<div style="font-size: 13.3333px;"><br>
</div>
<div style="font-size: 13.3333px;">The fourth thing to do is then to find out how many methods are affected.</div>
<div style="font-size: 13.3333px;"><br>
</div>
<div style="font-size: 13.3333px;">Finally we can then assess whether we want to live with the disease or not.</div>
<div style="font-size: 13.3333px;"><br>
</div>
</div>
</div>
</div>
<blockquote type="cite">
<div dir="ltr">
<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
<div style="font-size: 13.3333px"><span style="font-size: 13.3333px;">Best,</span></div>
<div style="font-size: 13.3333px"><span style="font-size: 13.3333px">Marcel</span></div>
</div>
</div>
</blockquote>
<br>
<div>Best, Eliot</div>
<div>_,,,^..^,,,_ (phone)</div>
</div>
<span></span><br></div></blockquote></div></body></html>