[pypy-dev] 1.4.1 threading

Carl Friedrich Bolz cfbolz at gmx.de
Mon Dec 27 09:31:51 CET 2010

On 12/27/2010 07:00 AM, Dima Tisnek wrote:
> (dan) random binary trees: O(log2(n)) is 7.2 for builtins, though the
> constant factor for locks, etc, might make it worthwhile
> (paolo) non blocking hash maps: memory barriers can be quite costly too
> different options will have to be implemented and tested when we get there,
> speaking on which, is there a test dict load?
> does anyone have some profiling data, what portion of runtime is spent
> reading and writing attributes and globals anyways?
> while we are on the subject, is there a plan to provide different
> levels of sparseness for different levels of name lookup?
> for example globals vs builtins, first needs to be quite sparce so
> that builtins show through well, second hardly, because there's
> nowhere else to look if builtins don't have the name.
> then the tradeoff could be more dynamic, that is frequently accessed
> dicts could be e.g. more sparse and rarely accessed more compact?
> (obviousely more sparse is not always better, e.g. in terms of cpu cache)
> of course "frequently accessed" is not as easy as frequently ran code,
> e.g. here "class A: ...; while 1: A().func()", func lookup occurs in
> different objects, yet it is same logical operation.
> come to think of it, is there any point in polymorphic dicts, e.g.
> attribute access could be imeplemented as a near-perfect compact hash
> map if attribute names change rarely, while regular dict()s are
> expected to change keys often.

All these thoughts go into the wrong direction, imo. The JIT removes 
nearly all dictionary accesses to global dicts, instance and class 
dicts. Even without the JIT, purely interpreting things, there are 
caches that bypass most dict lookups.

The only case where improving dicts would help is for user-defined 
dictionaries, i.e. when you write dicts with curly braces. that is 
basically very hard, because the usage patterns vary widely and a lot of 
work would be necessary to find common uses.


Carl Friedrich

More information about the Pypy-dev mailing list