<div dir="ltr">ditto in the Cog branch.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jan 5, 2013 at 7:23 AM, David T. Lewis <span dir="ltr">&lt;<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, Jan 01, 2013 at 03:24:35PM -0500, David T. Lewis wrote:<br>
&gt;<br>
&gt; On Tue, Jan 01, 2013 at 03:47:54PM +0000, <a href="mailto:commits@source.squeak.org">commits@source.squeak.org</a> wrote:<br>
&gt; &gt; Nicolas Cellier uploaded a new version of Kernel to project The Trunk:<br>
&gt; &gt; <a href="http://source.squeak.org/trunk/Kernel-nice.725.mcz" target="_blank">http://source.squeak.org/trunk/Kernel-nice.725.mcz</a><br>
&gt; &gt;<br>
&gt; &gt; ==================== Summary ====================<br>
&gt; &gt;<br>
&gt; &gt; Name: Kernel-nice.725<br>
&gt; &gt; Author: nice<br>
&gt; &gt; Time: 1 January 2013, 4:47:30.911 pm<br>
&gt; &gt; UUID: 52a4994f-63bc-4f71-9f8f-6f2fad460bde<br>
&gt; &gt; Ancestors: Kernel-nice.724<br>
&gt; &gt;<br>
&gt; &gt; Fast-up large integer modulo operations (\\ and rem:)<br>
&gt; &gt;<br>
&gt; &gt; Implementation notes:<br>
&gt; &gt; Quotient and remainder are computed in a single LargeIntegersPlugin primitive (see digitDiv:neg:) so it&#39;s faster to just use it.<br>
&gt; &gt; For LargeInteger with 64 bits or less, LargeInteger primitives (31 32 33) are faster than the plugin (especially in COG) so try them first.<br>
&gt; &gt; This results in a 2x speed up of modulo operations in 4.2.5 VM (whatever bit length), and a 2x speed up in COG VM for bit length &gt; 64.<br>
&gt; &gt; There is a penalty of 15% in COG for #rem: when bit length &lt;= 64 because there is no primitiveRem...<br>
&gt; &gt; Well, I added primitiveRem and it is in both VM branches, but it has no primitive number assigned.<br>
&gt; &gt; If we assign a primitive number (20 ?) we can expect a 5x speed up for rem and bitLength &lt;= 64.<br>
&gt;<br>
&gt; Should we assign primitive number 20 to primitiveRemLargeIntegers? It is in<br>
&gt; the range of numbered primitives allocated for large integer prims, and is<br>
&gt; currently unused in both the interpreter VM and Cog.<br>
&gt;<br>
&gt; I can&#39;t think of any reason not to do this, so someone please speak up if<br>
&gt; it might cause problems.<br>
<br>
</div></div>I added primitiveRemLargeIntegers as primitive 20 in VMMaker, so this will<br>
be available in future builds of the interpreter VM.<br>
<br>
Dave<br>
<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div>