<div dir="ltr">Hi Clément, Hi All,<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 24, 2016 at 5:09 AM, Clément Bera <span dir="ltr"><<a href="mailto:bera.clement@gmail.com" target="_blank">bera.clement@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br><div dir="ltr">Hi,<div><br></div><div>Support for primitive 169 for Object>>#~~ has been in the VM for a while. The default implementation in Squeak 5 uses this primitive for example.</div><div><br></div><div>I've just added today (VMMaker commit 2003) support for inlined #~~ like #== (including JIT support, branch pipelining, etc.). If one puts #~~ in the specialObjectsArray at the location of #blockCopy:, the bytecode compiler generates the special send bytecode for #~~ leading to improved performance and consistency between #== and #~~.</div><div><br></div><div>With today's update, the VM supports 3 inlined operations without any type checks: #==, #~~ and #class. It is possible to disable such optimisations in the bytecode compiler (In Pharo #class inlining is disabled there for example). Eliot would like to add support to disable these operations at VM level as a VM command line parameter too, and we may do it in the future.</div><div><br></div><div>Now this is for the VM support. It's up to the Pharo/Squeak/other community to decide what behavior they want in their runtime for these 3 selectors. </div><div><br></div><div>In my opinion, I believe that #~~ should be consistent with #==, hence they should be both inlined or both sends to primitives. I don't like the current situation in Pharo nor in Squeak. </div><div><br></div><div>Now when we look for solutions, we see that one of #== and #~~ needs to be a primitive (it's essential), hence it makes sense to have both Object>>#== and Object>>#~~ as primitives (with the primitive pragma in the method body). The inlining of #== and #~~ is arguable and I let the community decide what they believe is best for their runtime, though I would rather have the same behavior for both selectors.</div></div></blockquote><div><br></div><div>In addition, for proxies, it makes sense to allow the system to not inline the primitives.  Let me explain.  The primitives for #== and #~~, just like any other primitives, are found by message sends.  However, a set of 32 "special" selectors, which comprise some arithmetic selectors (#+, #- etc) and comparison selectors (#< #<= etc) and some frequent selectors #(at: #next #value #== etc) are subject to inlining with no sends (see Smalltalk specialSelectoers for the full set).</div><div><br></div><div>The first sixteen are arithmetic and comparison, and the interpreter gains performance by implementing these byte codes to test for SmallIntegers and Floats, and performing the arithmetic directly without a send, and for the comparisons, performing the comparison and any immediately following conditional branch.  The JIT performs these optimisations too.  But these short-cuts (static type prediction in the official terminology) are safe because they apply only to SmallInteger and Float.</div><div><br></div><div>Of the next sixteen most are there only to save space in a method's literal frame.  Since the byte code encodes the selector directly there is no need to store the selector in the method's literals.  The implementation of all but two (three if we add #~~ to replace #blockCopy: as mentioned above) of these bytecodes is to fetch the selector from the specialSelectors array and do a normal send.</div><div><br></div><div>#== and #class are handled specially.  These are inlined without doing a send.  The current Opal compiler in Pharo avoids the inlining of #class by not generating the #class special selector bytecode.  Squeak's compiler still issues the special selector bytecode.  Both generate #== by issuing the #== special selector bytecode, and so #== is never sent.  This is not what's desired for applications that use proxies.  It is fine for simple applications that prefer speed.</div><div><br></div><div>One simple thing one can do is prevent inlining for anything other than the arithmetic and comparison operators.  A simple command-line switch, or perhaps better, a flag in the image header, can control whether the VM inlines #class, #== & #~~.  This then allows the compilers to generate the more compact special selector byte codes for these sends, but causes the VM to treat them like the other 13 non-arithmetic special selectors.  Hence they become true sends.  I did this for VisualWorks several years ago and it works well, expect for needing a command-line switch.  The flag in the image header is much more reliable; whether an image should be run with inlining or not is a property of the image, not of a particular VM invocation.</div><div><br></div><div>So I suggest that</div><div>a) I implement the switch as an image header flag, allowing the inlining of #class, #== and #~~ to be turned off (but keeping inlining on by default)</div><div>b) Pharo changes Opal to start issuing the #class special selector send byte code again and turns off inlining of #class, #== and #~~</div><div>c) applications that use proxies (in Cuis, Pharo or Squeak) experiment with the setting and see if logic is improved and report back; Squeak and other dialects can then decide what they want as the default, and indeed certain packages could try and set the flag or at least check that the flag is in the desired state </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Cheers</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 23, 2016 at 2:39 PM, Aliaksei Syrel <span dir="ltr"><<a href="mailto:alex.syrel@gmail.com" target="_blank">alex.syrel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi<br>
<br>
It is been a while...<br>
So, do we want to replace ~~ with a primitive? :)<br>
<br>
Cheers<br>
Alex<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://forum.world.st/About-and-tp3898409p4924391.html" rel="noreferrer" target="_blank">http://forum.world.st/About-an<wbr>d-tp3898409p4924391.html</a><br>
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.<br>
<br>
</blockquote></div><br></div></div>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>