Mailman 3 June 2007 - Python-ideas

Ideas towards GIL removal
by Greg Ewing 18 Jul '08

18 Jul '08

I've been thinking about some ideas for reducing the amount of refcount adjustment that needs to be done, with a view to making GIL removal easier. 1) Permanent objects In a typical Python program there are many objects that are created at the beginning and exist for the life of the program -- classes, functions, literals, etc. Refcounting these is a waste of effort, since they're never going to go away. So perhaps there could be a way of marking such objects as "permanent" or "immortal". Any refcount operation on a permanent object would be a no-op, so no locking would be needed. This would also have the benefit of eliminating any need to write to the object's memory at all when it's only being read. 2) Objects owned by a thread Python code creates and destroys temporary objects at a high rate -- stack frames, argument tuples, intermediate results, etc. If the code is executed by a thread, those objects are rarely if ever seen outside of that thread. It would be beneficial if refcount operations on such objects could be carried out by the thread that created them without locking. To achieve this, two extra fields could be added to the object header: an "owning thread id" and a "local reference count". (The existing refcount field will be called the "global reference count" in what follows.) An object created by a thread has its owning thread id set to that thread. When adjusting an object's refcount, if the current thread is the object's owning thread, the local refcount is updated without locking. If the object has no owning thread, or belongs to a different thread, the object is locked and the global refcount is updated. The object is considered garbage only when both refcounts drop to zero. Thus, after a decref, both refcounts would need to be checked to see if they are zero. When decrementing the local refcount and it reaches zero, the global refcount can be checked without locking, since a zero will never be written to it until it truly has zero non-local references remaining. I suspect that these two strategies together would eliminate a very large proportion of refcount-related activities requiring locking, perhaps to the point where those remaining are infrequent enough to make GIL removal practical. -- Greg

8 19

Accelerated attr lookups
by Eyal Lotem 28 Jun '07

28 Jun '07

Hi, I have attached a patch at: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739789&group_… A common optimization tip for Python code is to use locals rather than globals. This converts dictionary lookups of (interned) strings to tuple indexing. I have created a patch that achieves this speed benefit "automatically" for all globals and builtins, by adding a feature to dictobjects. Additionally, the idea of this patch is that it puts down the necessary infrastructure to also allow virtually all attribute accesses to also be accelerated in the same way (with some extra work, of course). I have already suggested this before but I got the impression that the spirit of the replies was "talk is cheap, show us the code/benchmarks". So I wrote some code. Getting the changes to work was not easy, and required learning about the nuances of dictobject's, their re-entrancy issues, etc. These changes do slow down dictobjects, but it seems that this slowdown is more than offset by the speed increase of builtins/globals access. Benchmarks: A set of benchmarks that repeatedly perform: A. Global reads B. Global writes C. Builtin reads with little overheads (just repeatedly issuing global/builtin access bytecodes, many times per loop iteration to minimize the loop overhead), yield 30% time decrease (~42% speed increase). Regression tests take ~62 seconds (of user+sys time) with Python2.6 trunk Regression tests take ~65 seconds (of user+sys time) with the patch Regression tests are about ~4.5% slower. (Though Regression tests probably spend their running time on a lot more code than other programs, so are not a good benchmark, which spends more time instantiating function objects, and less time executing them) pystone seems to be improved by about 5%. My conclusions: The LOAD_GLOBAL/STORE_GLOBAL opcodes are considerably faster. Dict accesses or perhaps the general extra activity around seem to be insignificantly slower, or at least cancel out against the speed benefits in the regression tests. The next step I am going to try, is to replace the PyObject_GetAttr call with code that: * Calls PyObject_GetAttr only if GenericGetAttr is not the object's handler, as to allow modifying the behaviour. * Otherwise, remember for each attribute-accessing opcode, the last type from which the attribute was accessed. A single pointer comparison can check if the attribute access is using the same type. In case it does, it can use a stored exported key from the type dictionary [or from an mro cache dictionary for that type, if that is added], rather than a dict lookup. If it yields the same speed benefit, it could make attribute access opcodes up-to 42% faster as well, when used on the same types (which is probably the common case, particularly in inner loops). This will allow, with the combination of __slots__, to eliminate all dict lookups for most instance-side accesses as well. P.S: I discovered a lot of code duplication (and "went along" and duplicated my code in the same spirit), but was wondering if a patch that utilized C's preprocessor heavily to prevent code duplication in CPython's code, and trusting the "inline" keyword to prevent thousands of lines in the same function (ceval.c's opcode switch) would be accepted.

3 3

English builtins for Python
by Steve Howell 21 Jun '07

21 Jun '07

I somewhat tongue-in-cheekly propose to make the first seven most common English words all integral part of the Python language (three already are): source: http://www.world-english.org/english500.htm 1 the: Singletons: the class Logger: # ... 2 of inheritance: class Square of Shape:: # pass 3 to printing: print('hello world') to sys.stdout 4 and already a keyword 5 a introspection: if object is a dict: # ... 6 in already a keyword 7 is already a keyword Then it gets tougher: 8 it 9 you 10 that Top 500 words that are already keywords/builtins/conventions in Python: 27 or 49 each 55 if 189 try 198 self 251 open 254 next Top 500 words that are already keywords in some languages: 25 this 52 do 68 long Top 500 words that should NEVER be keywords: 78 could 81 did 180 men 252 seem 435 oh Words that seem like they'd be part of a programming language, but maybe a bad idea: 74 has 82 my 120 every 148 too ____________________________________________________________________________________ Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. http://farechase.yahoo.com/

9 17

Exporting dict Items for direct lookups of specific keys
by Eyal Lotem 20 Jun '07

20 Jun '07

I believe that it is possible to add a useful feature to dicts, that will enable some interesting performance features in the future. Dict lookups are in general supposed to be O(1) and they are indeed very fast. However, there are several drawbacks: A. O(1) is not always achieved, collisions may still occur B. Some lookups use static "literal" keys, and could benefit from accessing a dict item directly (very fast O(1) _worst_ case, without even a function call when done from the C side). C. B is especially true when dicts are used to hold attributes - in that case literal attribute names, in conjunction with psyco-like type specialization, can help avoid many dict lookups. I won't delve into this in this mail - but this is actually the use-case that I'm after optimizing. There is a possible implementation that can allow a dict to export items with minimal impact on its other performance. Create a new type of PyObject, a PyDictItemObject that will contain a key, value pair. (This will NOT exist for each hash table entry, but only for specifically exported items). Add a bitmap to dicts that has a single bit for every hash table entry. If the entry is marked in the bitmap, then its PyObject* "value" is not a reference to the value object, but to a PyDictItemObject. A new dict method "PyDict_ExportItem" that takes a single argument: key will create a PyDictItemObject, and assign the dict's key to it, and mark that hash-table entry in the bitmap. If PyDict_ExportItem is called when the item is already exported, it will return another reference to the same PyDictItemObject. The value in PyDictItemObject will initially be set to NULL (which means "key not mapped"). Both the PyDictItemObject and PyDict_exportitem should probably not be exported to the Python-side, but PyDictItemObject should probably be a PyObject for refcounting purposes. All the dict methods to get/set values, once they found the correct entry, check the bitmap to see if the entry is marked, and if it is - access the value in the PyDictItemObject instead of the value itself. In addition, if that value is NULL, it represents the key not actually being in the dict (__getitem__ can raise a KeyError there, for example, and __setitem__ can simply use Py_XDECREF and overwrite value with the value). Alternatively to the bitmap, the hash table entry can contain another boolean int -- I am not sure which is preferable in terms of cache-locality, but the bitmap is definitely cheaper, space-wise. This would allow dict users to create an exported item for a key once, and then access that key in real O(1) without function calls. As mentioned before, this can also serve in the future, as the basis for avoiding dict lookups for attribute searches.

3 11

labeled break/continue
by Matt Chisholm 18 Jun '07

18 Jun '07

Hi. I was wondering if there had ever been an official decision on the idea of adding labeled break and continue functionality to Python. I've found a few places where the idea has come up, in the context of named code blocks: http://groups.google.com/group/comp.lang.python/browse_thread/thread/a69662… and in the context of discussing do/while loops and assignments in conditionals: http://groups.google.com/group/comp.lang.python/browse_thread/thread/6da848… Both of those discussions just kind of petered out or changed direction without any conclusion. There's also this Python 2.6 which has a similar syntax (although different semantics) to one of the syntaxes proposed in the first discussion above: http://sourceforge.net/tracker/index.php?func=detail&aid=1714448&group_id=5… I would be willing to help make a case and then write a PEP for labeled break and continue, as long as the community or the BDFL hasn't already decided against it. -matt P.S. My apologies about cross posting; python-ideas seems like a better place to post this, but PEP 1 says to post to python-list.

2 1

alphabets, spelling, grammar, vocabulary, and the evolution of English
by Steve Howell 05 Jun '07

05 Jun '07

This is a linguistic reflection inspired by PEP 3131. English is a language that has undergone a major transformation in the last 200 to 300 years. It used to be spoken mostly on one particular island across the channel from France. Now it's spoken worldwide. Two of the larger populations of English speakers, residents of the UK and residents of the US, live an ocean away from each other. Unlike Python, English never had a PEP process. It naturally evolved. But like Python, English has been promoted, for various reasons, as a worldwide language, mostly successfully. English is also like Python in the sense that it had a mostly fresh start during certain colonizations, but it still had backward compatibility issues. Some observations: 1) US and UK residents can mostly converse with each other. 2) American English has diverged from British English in vocubalary, although many of the differing words are esoteric, or are inherently culturally incompatible, or have synonyms recognized on both sides of the ocean, or are idiomatic expressions. 3) American English differs from British grammar only in pretty non-fundamental areas. American English, despite 200 years of evolution away from its parent, preserves subject-verb-object ordering. Adjectives almost always precede nouns. Differences come down to subtle things like how you deal with collective nouns, etc. 4) Some words are spelled differently between American English and British English, but the spellings are generally mutually understanded by all speakers. (Even on the same side of the ocean, spelling can be ambiguous in English, so variant spellings often arise [more often, than, say, Spanish].) 5) American English and British English still have the exact same alphabet. A to Z. Are there analogies here to be drawn to Python? Thoughts? On AmE and BrE: http://en.wikipedia.org/wiki/American_and_British_English_differences "America and England are two nations divided by a common language." ____________________________________________________________________________________ Don't get soaked. Take a quick peak at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather

1 0

Attribute Docstrings and Annotations
by Ali Sabil 01 Jun '07

01 Jun '07

Hello all, I was looking into function annotations, that are to be introduced in Python3k, and I found this old message sent to this mailing list : http://mail.python.org/pipermail/python-ideas/2007-January/000037.html I would like to restart the discussion of attribute annotation, because in my opinion it can be a very powerful feature. I personally think about using it for SOAP message serialization, or any kind of XML serialization, the Idea would be to annotate various object attribues to be either marshaled as XML Elements or XML Attributes of the current Node that reflects the Object. Thank you, -- Ali

2 1

About list comprehension syntax
by Arnaud Delobelle 01 Jun '07

01 Jun '07

Hi List comprehensions (and generator expressions) come in two 'flavours' at the moment: (1) [f(x) for x in L], which stands for map(f, L). Let's call this a 'map comprehension' (2) [f(x) for x in L if p(x)], which stands for map(f, filter(p, L)). Let's call this a 'map-filter comprehension'. Now if one wants to write simply filter(p, L) as a list comprehension, one has to write: (3) [x for x in L if p(x)]. This could be called a 'filter comprehension'. the 'x for x in L' is not very nice IMHO, but it is often handy to use such expressions over 'filter(...)', eg building the sublist of a given list consisting of all the items of a given type could be written as: filter(lambda x: isinstance(x, FilteringType), heterogeneous_list) or: [x for x in heterogenous_list if isinstance(x, FilteringType)] I still prefer the list comprehension over the lambda/filter combination, but neither feels very satisfying (to me :) (not that one cannot use partial in the filter version) Why not just drop the 'x for' at the start of a 'filter comprehension' (or generator expression)? Thus (3) could be written more simply as: (3') [x in L if p(x)] This is consistent with common mathematical notation: * { f(x) | x \in L } means the set of all f(x) for x in L * { f(x) | x \in L, p(x) } means the set of all f(x) for x in L satisfying predicate p. * { x \in L | p(x) } means the set of all x in L satisfying predicate p. -- Arnaud

7 8