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
