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