<div dir="ltr"><div dir="ltr"><div>Hi Christoph,</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le sam. 7 mars 2020 à 15:01, Thiede, Christoph <<a href="mailto:Christoph.Thiede@student.hpi.uni-potsdam.de">Christoph.Thiede@student.hpi.uni-potsdam.de</a>> a écrit :<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 dir="ltr">
<div id="gmail-m_5752194681427931779divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<div id="gmail-m_5752194681427931779divtagdefaultwrapper" 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" dir="ltr">
<p>Take this as a memo for myself -- of course, it would be great to hear your ideas about the following points!</p>
<p><br>
</p>
<p>Further steps:</p>
<p><br>
</p>
<p></p>
<ul style="margin-bottom:0px;margin-top:0px">
<li>Implement the same return logic for #while(True|False)[:]. This might also require changes in the Compiler.</li><li>
<div>Inline #whileNil(:) implementation as well.<br>
General question: Is there such a thing as "too much inlining"? Would it be desirable to inline #cull: and others? Where do we draw the line between performance and Smalltalk-essential explorability?</div></li></ul></div></div></div></blockquote><div>Yes.</div><div>Those optimizations replace a message send by a sequence of bytecodes.</div><div>Therefore, they hardcode implementation of a method, making it difficult to then override or refine.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div id="gmail-m_5752194681427931779divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr"><div id="gmail-m_5752194681427931779divtagdefaultwrapper" 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" dir="ltr"><ul style="margin-bottom:0px;margin-top:0px"><li><div><span style="font-size:12pt">Implement all these controlling methods in a way that could work without inlining (though slow). At the moment, #whileTrue: refers to itself.<br>
An approach that completely foregos inline code would either need to use recursion (linear complexity) or "thisContext restart" (constant time complexity).</span></div></li></ul></div></div></div></blockquote><div>Well, thisContext restart could possibly work. But then we also want to have critical low level loops fast, so it's a matter of trade offs.</div><div>We are ready to sacrifice a bit of extensibility/genericity for a bit of speed. But only few extensibility for lot of speed!<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 dir="ltr"><div id="gmail-m_5752194681427931779divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr"><div id="gmail-m_5752194681427931779divtagdefaultwrapper" 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" dir="ltr"><ul style="margin-bottom:0px;margin-top:0px"><li>Should we maybe find a way to highlight methods that are inlined? For example, by using a pragma <inlined>. Or rather ask Encoder for it than storing this information in the methods.<br>
<span style="font-size:12pt">Should we warn or forbid the user to overri</span><span style="font-size:12pt">d</span><span style="font-size:12pt">e (or even
</span><span style="font-size:12pt">overwrite</span><span style="font-size:12pt">) such methods?</span>
<ul>
<li>Similar concern: It is dangerous to override #class et al., should we warn here, too?</li></ul></li></ul></div></div></div></blockquote><div>The idea, as the VM becomes faster is rather to remove this kind of optimization.</div><div>We have to care though, because the absence of message sends (like with == and class) also make some group of operations atomic (un-preemptible) and is currently exploited by some implementation of the classes for concurrent processes (Levente and Eliot are the primary experts in this area).</div><div>With the advent of Scorch (adaptive optimizer of Sista VM), we shall certainly re-consider some of the trade offs...<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 dir="ltr"><div id="gmail-m_5752194681427931779divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr"><div id="gmail-m_5752194681427931779divtagdefaultwrapper" 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" dir="ltr">Best,</div>
<div id="gmail-m_5752194681427931779divtagdefaultwrapper" 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" dir="ltr">
Christoph<br>
<br>
<div style="color:rgb(0,0,0)">
<div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_5752194681427931779x_divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>Von:</b> Squeak-dev <<a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" target="_blank">squeak-dev-bounces@lists.squeakfoundation.org</a>> im Auftrag von <a href="mailto:commits@source.squeak.org" target="_blank">commits@source.squeak.org</a> <<a href="mailto:commits@source.squeak.org" target="_blank">commits@source.squeak.org</a>><br>
<b>Gesendet:</b> Dienstag, 3. März 2020 22:38 Uhr<br>
<b>An:</b> <a href="mailto:squeak-dev@lists.squeakfoundation.org" target="_blank">squeak-dev@lists.squeakfoundation.org</a>; <a href="mailto:packages@lists.squeakfoundation.org" target="_blank">packages@lists.squeakfoundation.org</a><br>
<b>Betreff:</b> [squeak-dev] The Trunk: Kernel-ct.1295.mcz</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt">
<div>Nicolas Cellier uploaded a new version of Kernel to project The Trunk:<br>
<a href="http://source.squeak.org/trunk/Kernel-ct.1295.mcz" target="_blank">http://source.squeak.org/trunk/Kernel-ct.1295.mcz</a><br>
<br>
==================== Summary ====================<br>
<br>
Name: Kernel-ct.1295<br>
Author: ct<br>
Time: 24 January 2020, 5:20:51.814415 pm<br>
UUID: 18ea3b5d-ee42-2944-9d01-aa48e43207a7<br>
Ancestors: Kernel-nice.1292<br>
<br>
Extends BlockClosure >> #whileNil: by returning the final non-nil value. Adds #whileNil analogous to #whileTrue and #whileFalse.<br>
<br>
[Project uiManager chooseFrom: #(foo bar) values: #(Foo Bar)] whileNil.<br>
<br>
[Project uiManager chooseFrom: #(foo bar) values: #(Foo Bar)] whileNil: [self inform: 'You have to decide!']<br>
<br>
=============== Diff against Kernel-nice.1292 ===============<br>
<br>
Item was added:<br>
+ ----- Method: BlockClosure>>whileNil (in category 'controlling') -----<br>
+ whileNil<br>
+ "Unlike #whileTrue/False this is not compiled inline."<br>
+ | result |<br>
+ [(result := self value) isNil] whileTrue.<br>
+ ^ result<br>
+ !<br>
<br>
Item was changed:<br>
----- Method: BlockClosure>>whileNil: (in category 'controlling') -----<br>
whileNil: aBlock <br>
"Unlike #whileTrue/False: this is not compiled inline."<br>
+ | result |<br>
+ [(result := self value) isNil] whileTrue: [aBlock value].<br>
+ ^ result<br>
- ^ [self value isNil] whileTrue: [aBlock value]<br>
!<br>
<br>
<br>
</div>
</span></font></div>
</div>
</div>
</div>
<br>
</blockquote></div></div>