<div dir="ltr">Hi Ben,<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 7, 2016 at 4:40 PM, Ben Coman <span dir="ltr">&lt;<a href="mailto:btc@openinworld.com" target="_blank">btc@openinworld.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 Fri, Jan 8, 2016 at 2:51 AM, Eliot Miranda &lt;<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>&gt; wrote:<br>
&gt; Hi Ben,<br>
&gt;<br>
&gt; On Thu, Jan 7, 2016 at 10:39 AM, Ben Coman &lt;<a href="mailto:btc@openinworld.com">btc@openinworld.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Fri, Jan 8, 2016 at 1:20 AM, Eliot Miranda &lt;<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>&gt;<br>
&gt;&gt; wrote:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; and here&#39;s a version with a better class comment<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On Thu, Jan 7, 2016 at 9:12 AM, Eliot Miranda &lt;<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>&gt;<br>
&gt;&gt; &gt; wrote:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Hi Denis, Hi Clément,  Hi Frank,<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; On Thu, Jan 7, 2016 at 5:34 AM, Clément Bera &lt;<a href="mailto:bera.clement@gmail.com">bera.clement@gmail.com</a>&gt;<br>
&gt;&gt; &gt;&gt; wrote:<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; Hello,<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; Eliot, please, you told me you had the code and Denis is interested.<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; It uses 3 primitives for performance.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Forgive the delay.  I thought it proper to ask permission since the<br>
&gt;&gt; &gt;&gt; code was written while I was at Qwaq. I&#39;m attaching the code in a fairly raw<br>
&gt;&gt; &gt;&gt; state, see the attached.  The code is MIT, but copyright 3DICC.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; It is a plugin replacement for Squeak&#39;s Mutex, and with a little<br>
&gt;&gt; &gt;&gt; ingenuity could be a replacement for Squeak&#39;s Monitor.  It is quicker<br>
&gt;&gt; &gt;&gt; because it uses three new primitives to manage entering a critical section<br>
&gt;&gt; &gt;&gt; and setting the owner, exiting the critical section and releasing the owner,<br>
&gt;&gt; &gt;&gt; and testing if a critical section, entering if the section is unowned.  The<br>
&gt;&gt; &gt;&gt; use of the primitives means fewer block activations and ensure: blocks in<br>
&gt;&gt; &gt;&gt; entering and exiting the critical section, and that&#39;s the actual cause of<br>
&gt;&gt; &gt;&gt; the speed-up.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; You can benchmark the code as is.  Here are some results on 32-bit<br>
&gt;&gt; &gt;&gt; Spur, on my 2.2GHz Core i7<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; {Mutex new. Monitor new. CriticalSection new} collect:<br>
&gt;&gt; &gt;&gt; [:cs| | n |<br>
&gt;&gt; &gt;&gt; n := 0.<br>
&gt;&gt; &gt;&gt; [cs critical: [n := n + 1]. cs critical: [n := n + 1]. cs critical: [n<br>
&gt;&gt; &gt;&gt; := n + 1]. cs critical: [n := n + 1]. cs critical: [n := n + 1].<br>
&gt;&gt; &gt;&gt; cs critical: [n := n - 1]. cs critical: [n := n - 1]. cs critical: [n<br>
&gt;&gt; &gt;&gt; := n - 1]. cs critical: [n := n - 1]. cs critical: [n := n - 1].<br>
&gt;&gt; &gt;&gt; n ] bench]<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; {Mutex new. Monitor new. CriticalSection new} collect:<br>
&gt;&gt; &gt;&gt; [:cs| | n |<br>
&gt;&gt; &gt;&gt; n := 0.<br>
&gt;&gt; &gt;&gt; cs class name, &#39; -&gt; &#39;,<br>
&gt;&gt; &gt;&gt; [cs critical: [n := n + 1]. cs critical: [n := n + 1]. cs critical: [n<br>
&gt;&gt; &gt;&gt; := n + 1]. cs critical: [n := n + 1]. cs critical: [n := n + 1].<br>
&gt;&gt; &gt;&gt; cs critical: [n := n - 1]. cs critical: [n := n - 1]. cs critical: [n<br>
&gt;&gt; &gt;&gt; := n - 1]. cs critical: [n := n - 1]. cs critical: [n := n - 1].<br>
&gt;&gt; &gt;&gt; n ] bench]<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; #( &#39;Mutex -&gt; 440,000 per second. 2.27 microseconds per run.&#39;<br>
&gt;&gt; &gt;&gt; &#39;Monitor -&gt; 688,000 per second. 1.45 microseconds per run.&#39;<br>
&gt;&gt; &gt;&gt; &#39;CriticalSection -&gt; 1,110,000 per second. 900 nanoseconds per run.&#39;)<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; This is great Eliot. Thank you and 3DICC.  After loading the changeset<br>
&gt;&gt; into Pharo-50515 (32 bit Spur) I get the following results on my<br>
&gt;&gt; laptop i5-2520M @ 2.50GHz<br>
&gt;&gt;<br>
&gt;&gt; #(&#39;Mutex -&gt; 254,047 per second&#39;<br>
&gt;&gt;  &#39;Monitor -&gt; 450,442 per second&#39;<br>
&gt;&gt;  &#39;CriticalSection -&gt; 683,393 per second&#39;)<br>
&gt;&gt;<br>
&gt;&gt; In a fresh Image &quot;Mutex allInstances basicInspect&quot; lists just two<br>
&gt;&gt; mutexes...<br>
&gt;&gt; 1. NetNameResolver--&gt;ResolverMutex<br>
&gt;&gt; 2. ThreadSafeTranscript--&gt;accessSemaphore<br>
&gt;<br>
&gt;<br>
&gt; I hate myself for getting distracted but I&#39;m finding this is un.  One can<br>
&gt; migrate to the new representation using normal Monticello loads by<br>
&gt;<br>
&gt; In the first version redefine Mutex and Monitor to subclass LinkedList and<br>
&gt; have their owner/ownerProcess inst var first (actually third after firstLink<br>
&gt; &amp; lastLink), and add the primitives.<br>
&gt;<br>
&gt; In the next version check that all Mutex and Monitor instanes are unowned<br>
&gt; and then redefine to discard excess inst vars<br>
&gt;<br>
&gt; Let me test this before committing, and see that all tests are ok.<br>
<br>
</div></div>Should Mutex and Monitor both directly subclass LinkedList and<br>
duplicate the primitives in each?<br>
<br>
Or should they both subclass CriticalSection which subclasses<br>
LinkedList so the primitives are only defined once?<br></blockquote><div><br></div><div>That&#39;s a good idea.  Feel free to change the code, but test that the Monticello load handles this case properly first :-).  Actually, given that the default state of all the Mutex and Monitor instances in the image is unowned (owner process is nil) then it&#39;ll just work anyway.  If we do that, we must make sure to include the ICC copyright in CriticalSection&#39;s class comment, and can eliminate it from the primitives.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What effect would using the primitives from the superclass have on<br>
performance? If any, I&#39;d vote to optimise for duplication rather than<br>
&quot;nice&quot; design, but our comments should document this.<br></blockquote><div><br></div><div>Likely in the noise.  The inline cacheing machinery in the VM is far cheaper than the real overheads here which are in block creation, process switch, interpreter primitive invocation.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
cheers -ben<br>
<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>