<div dir="ltr"><div>Hi,</div><div><br></div>Backward compatibility is no problem Eliot.<div><br></div><div>First you can compile a VM with both the existing MiscPrimitivePlugin and the new plugins/numbered primitives so all images work fine.</div><div>Second all MiscPrimitives are optional, so once MiscPrimitivePlugin support is dropped, everything is backward/forward compatible.</div><div><br></div><div>Ok so it's decided.</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 22, 2017 at 9:17 PM, Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-12-22 17:49 GMT+01:00 Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div dir="auto"><div>Hi Clément, Hi All,<br><br></div><div><br>On Dec 22, 2017, at 2:28 AM, Clément Bera <<a href="mailto:bera.clement@gmail.com" target="_blank">bera.clement@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span></span></div></blockquote><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div dir="ltr">Hi all,<div><br></div><div>As I said earlier I am on my way through a student project (cc'ed) to re-write/split/kill MiscPrimitive plugin. The plugin is composed of:</div><div>- 2 Bitmap primitives</div><div>- 1 Sound primitive.</div><div>- 6 ByteObject primitives</div><div><br></div><div>I will discuss here what is plan for each category of primitives. I would like comments and Eliot's approval before moving forward with the student project.</div></div></div></div></div></blockquote><div><br></div>IMO you should definitely go ahead. There is s backwards compatibility issue so it would be good to coordinate with a major release and maybe we can still support older images with some name hack in the vm which continues to recognize the '<span style="background-color:rgba(255,255,255,0)">MiscPrimitivePlugin'</span> name in primitive pragmas, mapping to the correct name.<div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><br></div><div><b>2 Bitmap primitives</b><br></div><div><br></div><div>Those are the compress and uncompress Bitmap primitives. Tim suggested that we move the primitive to the BitBlt plugin (hence converting from SmartSyntax to Slang). I think this is the right thing to do. Agreed ?</div></div></div></div></div></blockquote><div><br></div><div>+1</div><div><br></div>IIRC, Tim Rowledge wrote a primitive that uses smart syntax in <span style="background-color:rgba(255,255,255,0)">the BitBlt plugin (BirBltSimulation) and so you don't have to use pure slang.  You can at least use the smart syntax signature mechanism.  I think this means that it is wrong to say that the translated primitives are written in smart syntax.  They are written in a pure Smalltalk syntax that is different again from the syntax use to write primitives under SmartSyntaxPlugin (how confusing!! :-) )</span></div><div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><b>1 Sound primitive</b></div><div><br></div><div>This primitive can simply be moved to the SoundGenerator plugin. SoundGenerator is also built using SmartSyntax. Agreed ?</div></div></div></div></div></blockquote><div><br></div>+1</div><div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><b>6 ByteObject primitives</b></div><div><br></div><div><u>1. translate: aString from: start  to: stop  table: table</u></div><div><br></div><div>This primitive seems to be unused. I suggest we move it from a primitive to plain Smalltalk code.</div></div></div></div></div></blockquote><div><br></div>+1</div><div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><u>2. stringHash: aString initialHash: speciesHash</u></div><div><br></div><div>Since we now have hashMultiply as a primitive, the stringHash primitive is now faster for very small strings with a Smalltalk version using hashMultiply, and slower (2x) on medium to large strings. I suggest we move it to plain Smalltalk code.</div></div></div></div></div></blockquote><div><br></div>+1.  And I've already suggested we sample a subset of elements for large strings, so we could beat the primitive if, say, we sampled no more than some large number of characters for very large strings.</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><u>3. findFirstInString, indexOfAscii, findSubString</u></div><div><br></div><div>For these 3 primitives we can either add a ByteStringPlugin or add them as numbered primitive. </div></div></div></div></blockquote><div><br></div>Whatever you do it would be really nice not to break vm backward compatibility/image forward compatibility.  Otherwise this should be coordinated with a major release and we should provide a file in for older images.</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><div><u>4. compare: string1 with: string2 collated: order</u><br></div><div><br></div><div>This primitive is really important for performance, there are production application spending a huge amount of times for string equality. I suggest that we move this one to a numbered primitive that takes 2 or 3 parameters, the order being optional, and to rewrite the version without order (i.e. the version used by String>>#=, String>>#>, String>>#>=, etc.) in the JIT (numbered primitives are required for that).</div></div></div></div></div></blockquote><div><br></div>+1.  Do you imagine the primitive being polymorphic in element widths (being able to compare an n byte string with an m byte string)?  There are only 8 combinations.</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><div>Alternatively we can add a numbered String>>#= numbered primitive and put the compare primitive in a ByteStringPrimitive.</div></div></div></div></div></blockquote><div><br></div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><br></div><div><u>5. String concatenation</u></div><div><br></div><div>I would suggest to add in addition ByteString>>#, as a primitive. String concatenation is really important performance wise and that will ease deforestation (i.e. removing the allocation of temporary byte strings) in the Sista JIT which is quite difficult right now. </div></div></div></div></blockquote><div><br></div>Sure, but it might be better to investigate tree strings with O(1) concatenation.  Mapping tree strings to flat strings would then occur in primitive failure code of primitives expecting flat strings.  IIUC JavaScript VMs use tree strings right?</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><br></div><div><b>Conclusion</b></div><div><br></div><div><div>The main question is do we want 1 numbered primitive and 3-5 primitives in a small ByteStringPlugin, or do we want 3-5 numbered primitive. I don't mind either.</div></div></div></div></div></blockquote><div><br></div>The main question here is what the backward compatibility story is.  What you're proposing will break backwards compatibility meaning older Spur images will not be able to run on new VMs.  That's ok only if we coordinate these changes with a major release.</div><div><br></div><div>There's a smaller intermediate step which is to eliminate the Smalltalk syntax for <span style="background-color:rgba(255,255,255,0)">MiscPrimitivePlugin and simply rewrite it using traditional smart syntax slang as methods on MiscPrimitivePlugin.  Perhaps we could add some mechanism to invoke jitted versions of these primitives for the performance critical ones, but it sounds like a lot of work.</span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">To be clear, Clément, I like the conceptual clarity of your proposal, and would be fully behind if we're if not for backward compatibility.  It would be preferable to me if we can add some hack to use your new scheme but still run older images unchanged.  This hack can then be discarded some time in the future.  I don't want to have to maintain legacy VMs :-)</span></div><div><br></div></div></blockquote><div><br></div><div>Hi Eliot,</div><div>Aren't all these primitives optional?</div><div>Running an old image on a new VM woud fail to find primitives and fallback to Smalltalk (slang) code.<br><div>That would mean that we don't have to maintain any compatibility at all (old image + new VM would just be slower).</div><div>New image would require new VM, but we could also add fallback code to make the primitives optional.<br></div><div><br></div></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="auto"><div><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><div><br></div><div>I looked at the performance on the Sista VM, but there is still quite some work to make all of those efficient and in production. Recently other VMs (especially V8) decided to loose some peak performance in exchange for better baseline performance since many applications they were running were spending only 15-20% of the time in optimised code and 80-85% in baseline code, so primitive performance is a big deal no matter what we have in the future.</div></div></div></div></div></blockquote><div><br></div>+1</div><div><br></div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail-m_4665054462576919286gmail-m_-3258753772808591866m_-612103856050492836gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Clément Béra<div><a href="https://clementbera.wordpress.com/" target="_blank">https://clementbera.wordpress.<wbr>com/</a><br></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;line-height:16px;background-color:rgb(255,255,255)">Bâtiment B 40, avenue Halley 59650 </span><i style="font-weight:bold;font-style:normal;font-family:arial,sans-serif;line-height:16px;background-color:rgb(255,255,255)">Villeneuve d'Ascq</i></div></div></div></div></div></div></div></div></div></div></div></div>
</div>
</blockquote></div></div><br></blockquote></div><br></div></div>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><span style="font-size:12.8px">Clément Béra</span><div style="font-size:12.8px">Pharo consortium engineer</div><div style="font-size:12.8px"><a href="https://clementbera.wordpress.com/" target="_blank">https://clementbera.wordpress.com/</a><br></div><div style="font-size:12.8px"><span style="line-height:16px">Bâtiment B 40, avenue Halley 59650 </span><span style="font-weight:bold;line-height:16px">Villeneuve d'Ascq</span></div></div></div>
</div></div></div>