Indeed - great to see some of the thought going into this area of the project :)<div><br></div><div>If I make any progress on the actual HW I'll be sure to let you know.<div><br></div><div>Liam<br><br><div class="gmail_quote">
On Tue, Apr 5, 2011 at 1:51 PM, Dima Tisnek <span dir="ltr"><<a href="mailto:dimaqq@gmail.com">dimaqq@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Armin, thanks for pointing me in the right direction.<br>
<br>
If minimark.py docstring is up to date, looks like it will do close to<br>
the right thing on arm5/9.<br>
<br>
Some of the older arms don't have L2 cache, I'm not sure what<br>
/proc/cpuinfo reports in this case, perhaps L1 cache size or nothing.<br>
It seems if the cache line is missing in cpuinfo, get_L2cache_linux2<br>
would return maxint (ouch memory) or, if kernel prints 0 there, then 0<br>
(ouch cpu), or if -1 gets in the way, default nursery size, which is<br>
256 bytes (ouch cpu again). If anyone tries to run pypy under QEMU in<br>
system mode, results might be very very odd!<br>
<br>
Modern arm processors have L2 cache from 256KB to 1MB, thus the<br>
expected minimum threshold is 1MB to 4MB, seems reasonable enough, as<br>
importing a decent set of python standard library is around that.<br>
<br>
I'm sure Liam is pleased :P<br>
<font color="#888888"><br>
d.<br>
</font><div><div></div><div class="h5"><br>
On 5 April 2011 13:00, Armin Rigo <<a href="mailto:arigo@tunes.org">arigo@tunes.org</a>> wrote:<br>
> Hi Dima,<br>
><br>
> On Tue, Apr 5, 2011 at 9:52 PM, Dima Tisnek <<a href="mailto:dimaqq@gmail.com">dimaqq@gmail.com</a>> wrote:<br>
>> What I mean<br>
>> to say is that there's gotta be a more clever way where gc thresholds<br>
>> depend on e.g. size of working set or rate of new allocations or<br>
>> something yet smarter.<br>
><br>
> Yes, it does in PyPy; we do a full collection when the total amount of<br>
> data reaches 1.82 times (by default) the amount of live data at the<br>
> end of the previous collection, with additional tweaks to improve<br>
> performance in various cases -- and one such tweak is to set the<br>
> minimum threshold to 16MB (actually, now I think it is not fixed to<br>
> 16MB but it depends on the amount of L2 cache). It was all reached by<br>
> various benchmarks on various desktop machines, including the minimum<br>
> threshold. You can see the various thresholds and their defaults at<br>
> the start of pypy/rpython/memory/gc/minimark.py (and that's only if<br>
> you are using minimark, our default GC).<br>
><br>
> Of course all the numbers -- and even half of the algorithms -- are<br>
> going to be bogus if you start to think about very different machines.<br>
> That's what I meant when I said that there is open work to do, and<br>
> you or anyone with an interest in the area (and corresponding<br>
> hardware) is welcome to attack it.<br>
><br>
><br>
> A bientôt,<br>
><br>
> Armin<br>
><br>
</div></div></blockquote></div><br></div></div>