<br><br><div class="gmail_quote">On Sun, Mar 27, 2011 at 8:53 PM, <a href="mailto:hyarion@iinet.net.au">hyarion@iinet.net.au</a> <span dir="ltr">&lt;<a href="mailto:hyarion@iinet.net.au">hyarion@iinet.net.au</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
On Fri Mar 25 21:41 , Armin Rigo ┬ásent:<br>
<div class="im"><br>
&gt;Hi,<br>
&gt;<br>
&gt;On Fri, Mar 18, 2011 at 1:44 AM, <a href="mailto:hyarion@iinet.net.au">hyarion@iinet.net.au</a><br>
&gt;<a href="mailto:hyarion@iinet.net.au">hyarion@iinet.net.au</a>&gt; wrote:<br>
&gt;&gt; (...) Wrapping each bytecode in an STM<br>
&gt;&gt; transaction would give you an as-if-serial execution order, again with no<br>
guarantees<br>
&gt;&gt; about which order. You get transaction overheads instead of lock/unlock<br>
overheads,<br>
&gt;&gt; but some STM systems can be quite efficient for short transactions that rarely<br>
&gt;&gt; conflict.<br>
&gt;<br>
&gt;Yes, I also thought about this as one of the solutions that would &quot;fit<br>
&gt;the model&quot; of PyPy by not needing changes all over the place.<br>
&gt;However, I am unsure that the performance of STM is good enough for<br>
&gt;that application so far. ┬áMaybe I&#39;m wrong, but I fear (a priori, with<br>
&gt;no precise experience) that it would be really too slow to wrap *all*<br>
&gt;memory reads and writes with the STM machinery.<br>
<br>
</div>Yeah, I suppose to get the performance I&#39;m thinking of you probably need to know<br>
what you&#39;re sharing (and for it not to be everything). You wouldn&#39;t need all memory<br>
reads and writes to be transactional, just ones to interpreter-level values that are<br>
mutable and shared between threads, and ones to things that represent app-level<br>
shareable values.<br>
<br>
The STM system I worked on was for a declarative language with immutable data. In<br>
that context it turns out the system only had to be careful when retrieving<br>
references from STM; what the reference points to could still be used as normal non-<br>
shared data. In a language like Python I guess almost any bit of memory could<br>
potentially be (or later become) a shared value that another thread could be using.<br>
<br>
What&#39;s the &quot;success-rate&quot; of the JIT&#39;s malloc-removal like? You could omit the<br>
transactional overhead for those values. Would that get close enough for the<br>
important 20% of code? You could probably do some other jiggery-pokery under the<br>
hood to minimise the amount of data protected by STM overhead too.<br>
<br>
If I had more time I&#39;d love to look at this sort of thing.<br>
<br>
-- Ben<br>
<div><div></div><div class="h5">_______________________________________________<br>
<a href="mailto:pypy-dev@codespeak.net">pypy-dev@codespeak.net</a><br>
<a href="http://codespeak.net/mailman/listinfo/pypy-dev" target="_blank">http://codespeak.net/mailman/listinfo/pypy-dev</a><br>
</div></div></blockquote></div><br><a href="https://bitbucket.org/pypy/extradoc/raw/63e4617062b2/talk/pepm2011/bolz-allocation-removal.pdf">https://bitbucket.org/pypy/extradoc/raw/63e4617062b2/talk/pepm2011/bolz-allocation-removal.pdf</a> has info on the success rate of allocation removal.<br>
<br>Alex<br clear="all"><br>-- <br>&quot;I disapprove of what you say, but I will defend to the death your right to say it.&quot; -- Evelyn Beatrice Hall (summarizing Voltaire)<br>&quot;The people&#39;s good is the highest law.&quot; -- Cicero<br>
<br>