Mailman 3 August 2001 - Python-Dev

optimizing non-local object access
by Martin v. Loewis 10 Aug '01

10 Aug '01

[Martin] > Would that catch changes like [accessing __dict__] [Jeremy] > It would because __dict__ wouldn't be a dictionary [Guido] > In 2.2, if you don't use __getitem__ for access-by-number, you could > subclass dictionary and add a separate set of APIs to access the > variables by number (and to assign numbers to them in the first > place). Then it would still behave like a real dictionary enough to > be usable for the PyDict_* C API functions. But then, changes that happen through PyDict_SetItem would not be tracked for the dlict objects, would they (assuming that the dlict objects keep an additional array per dictionary which needs to be updated)? Regards, Martin

1 0

optimizing non-local object access
by Martin v. Loewis 09 Aug '01

09 Aug '01

> I think we hook in at the tp_getattr(o) level. Module objects can > detect rebindings there and do whatever bookkeeping is necessary to > keep references to its name consistent. I think this is the right > approach for either technique we're discussing. Would that catch changes like math.__dict__['sin'] = math.cos ?? Regards, Martin

4 4

Re: [Python-Dev] optimizing non-local object access
by Samuele Pedroni 09 Aug '01

09 Aug '01

[Jeremy Hylton] > I've been thinking about the same issues in my spare time. I > certainly think the interpreter could be made faster by assuming that > most bindings are static most of the time. Python has many places > where bindings can change unexpectedly, but most of the time they > don't change. > > My worry about your approach is that the track-object opcodes could > add a lot of expense for objects only used once or twice. If the > function uses math.sin inside a loop, it's an obvious win. If it uses > it only once, it's not so clear. I agree, and I wonder whether it is not going to explode (in term of effort and resources) down a call graph. > The other approach I had been thinking about, which may have made it > into my pre-PEP post a few months ago, is to store module globals in a > table that can be accessed like fast locals. Any reference to another > module would use the fast globals table. For references to global > names in another module, the calling module could lookup the offset of > that name in the defining module's fast globals. > I rembemer I liked it. > I have been thinking some about how to make a similar strategy work > for instances. I think we could apply some lessons from the Self > compiler and recompile generic bytecodes ("load the 'foo' attribute") > into more specific bytecodes ("load slot 12"). But this is more > speculation than anything else. Some considerations about this: Python vs. Smalltalk vs. Self Smalltalk classes have rigid sets of slots, single inheritance and all slot are private (protected?), so I imagine it is easy to number them. In Self the set of slots of an object is also fixed (there are specific reflective methods to modify the set of slots) and also which are mutable etc. OTOH Self has dynamic inheritance (something like the mutable __bases__ in Python). To deal with all this it uses customization (different version of a single method are lazily compiled against the various concrete structural variations of objects that inherit it) and assume that things found up in the inheritance tree are constant but guards itself about their changes Python is even less rigid than Self and there is not an explicit notion of the set of slots that goes with an object. So to achieve some improvement in slot access speed may be necessary to: - set more rigid rules on slots (but then that's not Python anymore) - find a way to detect some conservative approximation of the set of slots of a concrete class - use customization (consumes memory) so you can exploit a fixed layout for the approximated slots - use plain dictionary lookup for the slots missed that way Not impossible, not trivial and surely a thing that will pollute code clarity, OTOH whith this kind of optimizations in place, even just at the interp level, effective native compilation is not that far ... regards, Samuele Pedroni.

5 8

Common runtime sociology
by Paul Prescod 09 Aug '01

09 Aug '01

It is my gut feeling that the only way to get to a common runtime (if it is possible at all) is to take the development out of the hands of any language group and put it in a trusted third party's hands. If any language group feels like its concerns are going to get second-class attention, they'll go back and focus on their own implementation. So that's just my feeling...if the goal of some people is really to have the different languages share implementation then the technical issues are secondary to the project organization and leadership. -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook

8 10

optimizing non-local object access
by Skip Montanaro 09 Aug '01

09 Aug '01

I had a thought last night about optimizing access to globals in other modules (e.g. "math.sin" or "string.uppercase"). I think it could actually work to speed up all non-local object access. The nice thing about module globals is that for the most part they are "almost constant". Once a module is imported, it's rare that its global name bindings actually change. I think it might suffice to create a notification system that allows an executing frame to register its interest in changes to a module's name bindings. Let me make this idea concrete with an example. Suppose I have the following code: import math def sinseq(n): l = [] for i in xrange(n): l.append(math.sin(i)) return l "math.sin" requires a global lookup and an attribute access each pass through the loop. Let's add an entry to the fastlocals array for it and an entry to the local names called "math.sin". The byte code compiler generates a LOAD_FAST instruction anywhere math.sin is accessed, and at the first point where it should be "live" (i.e., at the beginning of the function) it simply inserts a TRACK_OBJECT instruction with that slot in fastlocals as one argument and the "math.sin" slot in the local names as the other. When "math.sin" goes out of scope (i.e., at the end of the function), it inserts an UNTRACK_OBJECT instruction with "math.sin" as its argument. The same can be done for "l.append" and xrange. The bytecode for the above function would look something like: TRACK_OBJECT math.sin TRACK_OBJECT xrange >> 0 BUILD_LIST 0 ('\000', '\000') 3 STORE_FAST 1 (l) TRACK_OBJECT l.append 6 SETUP_LOOP 44 (to 53) 9 LOAD_FAST xrange 12 LOAD_FAST 0 (n) 15 CALL_FUNCTION 1 ('\001', '\000') 18 LOAD_CONST 1 (0) 21 FOR_LOOP 28 (to 52) 24 STORE_FAST 2 (i) 27 LOAD_FAST l.append LOAD_FAST math.sin 39 LOAD_FAST 2 (i) 42 CALL_FUNCTION 1 ('\001', '\000') 45 CALL_FUNCTION 1 ('\001', '\000') 48 POP_TOP 49 JUMP_ABSOLUTE 21 ('\025', '\000') >> 52 POP_BLOCK >> 53 LOAD_FAST 1 (l) UNTRACK_OBJECT l.append UNTRACK_OBJECT xrange UNTRACK_OBJECT math.sin 56 RETURN_VALUE TRACK_OBJECT and UNTRACK_OBJECT are responsible for registering and unregistering interest in an object. TRACK_OBJECT also caches the corresponding object in the fastlocals array. <wave what="hands"> I think most or all of the work can be handled by PyObject_SetAttr and/or PyDict_SetItem. It seems to me that its greatest benefit would be to short circuit access to global variables in other modules. For the most part, these don't change once an import is completed, so you'd effectively be converting access to these objects into local variables, but you could use it to track all non-local variables or attributes. </wave> stepping-behind-the-egg-proof-screen-ly y'rs, Skip

3 6

Re: [Python-Dev] optimizing non-local object access
by Samuele Pedroni 09 Aug '01

09 Aug '01

> SP> - find a way to detect some conservative approximation of the > SP> set of slots of a concrete class > > I think this can be done with better compiler support. > The simplest thing would be to detect all 'attr' that appear in the body of the methods of a class statements in 'self.attr' form. Class construction at run-time will take the union of this together with the information computed for base classes Why at runtime? It avoids the trouble of poor-man-to-full-fledged type-inference for the compiler. It would be reasonably effective and at most would require the programmer to put a self.myFavoriteAttr = None in __init__. > SP> - use customization (consumes memory) so you can exploit a fixed > SP> layout for the approximated slots > SP> - use plain dictionary lookup for the slots missed that way > > Right Clearly this should be played two-hands with method dispatch. > > SP> Not impossible, not trivial and surely a thing that will pollute > SP> code clarity, OTOH whith this kind of optimizations in place, > SP> even just at the interp level, effective native compilation is > SP> not that far ... > > It is a lot of work for instances, so I've been considering it > separately from the module globals issue. But I think it is > possible. Short of native-code, I wonder if we can extend the Python > VM with opcodes that take advantage of slots. It is indeed a good idea, but the problem is that customising without native compilation can have a very poor compilation-time vs. runtime speedup ratio. OTOH we could customize only hot-spots. But I think is worth trying if we ever get at it. > I'm not sure how > closely this idea is related to Pysco. AFAIK it would be complementary, Armin Rigo pointed out that in principle Psyco can layout objects at will, but I remarked that is way of dealing with code comsumes a lot of memory so it is workable only if applied only to hot spots, and then we pay for conversion when non-Pysco code calls Psyco code. Psyco is doing some sort of customization (a generalisation of that), a layout for instances that can be exploited in term of speed under customization is a good thing for Psyco too IMHO. > Imagine we didn't special case ints in BINARY_ADD. If you're doing > mostly string addition, it's just slowing you down anyway :-). > Instead, a function that expected to see ints would check the types of > the relevant args. > > def f(x): > return 2*x > > would become something like: > > def f(x): > if isinstance(x, int): > return 2 * x_as_int > else: > return 2 * x > > where the int branch could use opcodes that knew that x was an integer > and could call its __add__ method directly. AFAIK this is somehow what Psyco does, I have not checked the code but my understanding is that it goes a hard way to do this kind of thing specifically when they can give you something. Customization would mean the following: class A: def __init__(self, a=2): self.a = a def double(self): self.a*=2 class B: def __init__(self, b=3): self.b = b def inc(self): self.b+=1 class C(A,B): def __init__(self,a,b): A.__init__(a) B.__init__(b) def mul(self): return a*b under customization if both instances of A and C are used and in both cases double is used there will be two versions of double to choose from, one that expect self to be of concrete class A and one that expect it to be of concrete class C. Both these versions can be constructed knowing the exact place of the slot a in the objects. It works clearly best with good pure single dispatch oo code ;). In any case both a more static layout for slots and some way to add hooks that count how many times a code object is invoked, would be a good start point for a lot of possible nice experiments. regards, Samuele.

1 0

Re: [Python-Dev] Parrot -- should life imitate satire?
by Dan Sugalski 09 Aug '01

09 Aug '01

At 11:35 PM 8/7/2001 +0200, Samuele Pedroni wrote: >The intention of my last meassage was not to shut down discussion with a >pessimistic argument, I was just trying to pin down the potential problems, >maybe the tone was a bit bitter... Nope, not at all--I do intend to reply. (The tone was fine, BTW) The Real World just got in the way, as it has this annoying tendency to do. :) As a quick response (this is from memory, so if it makes no sense don't be surprised), the current Parrot design's adequate for heavy OO, but could be a lot better. I'm working on that, and as soon as I've a better under-the-hood design I'll drop a note and everyone can savage it as appropriate. (And the more the better, honestly) FWIW I've thrown the first partial draft of the Parrot assembly language spec out to the wolves. URL and details available to the interested. Dan --------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan(a)sidhe.org have teddy bears and even teddy bears get drunk

4 5

opcode dispatch - switch vs. function pointers
by Skip Montanaro 09 Aug '01

09 Aug '01

Popped over to the language-dev archive at ActiveState and came across this interesting post about opcode dispatch: http://aspn.activestate.com/ASPN/Mail/Message/language-dev/724204 I think I'm going to experiment a little with dispatch via function pointers in the Rattlesnake (once I get something that more-or-less works). Skip

1 0

"not an acceptable base type"?
by Skip Montanaro 08 Aug '01

08 Aug '01

Are strings not yet subclassable or do I just need to "cvs up"? >>> class string(str): ... pass ... Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: type 'str' is not an acceptable base type >>> "".__class__ == str 1 Thx, Skip

3 4

Re: [Python-Dev] PEP 264 (was RE: [Python-checkins] CVS: python/nondist/peps pep-0264.txt,NONE,1.1 pep-0000.txt,1.113,1.114)
by Michael Hudson 08 Aug '01

08 Aug '01

Instant response, without that tedious-prone-to-problem-spotting thinking: nice idea! "Tim Peters" <tim.one(a)home.com> writes: > [Guido, checking in > Michael Hudson's "Future statements in simulated shells". > PEP > ] > > ... > > Paul Prescod has reasonably complained about the choice of a > > bitfield as the fourth argument to compile(), claiming it is > > obscure and unpythonic. > > I've got a happy idea! __future__.py is a real std module, and e.g. > > __future__.nested_scopes > __future__.generators > __future__.division > > are honest-to-gosh Python objects, of class __future__._Feature. That's the > perfect place to store feature-specific magic flag bits. So, e.g., I'm > picturing > > compile(s1, s2, s3, __future__.generators.getflag()) Or just __future__.generators.compile_flag presumably? > and > > flags = 0 > for fname in list_of_feature_names: > flags |= getattr(__future__, fname).getflag() > compile(s1, s2, s3, flags) > > etc. For that matter, list-of-feature-strings -> flag_bits could be > added as a utility function to __future__.py. It's Python -- > there's nothing you can't do with this in 5 seconds <wink>. "list_of_feature_names" might as well be spelt "__future__.__all__", I'd have thought. There's still the icky issue of PyEval_MergeCompilerFlags to consider. The fact that each future statement has two bits assigned to in - the PyCF_* ones in pythonrun.h and the CO_* ones in compile.h that allow __builtin__.compile to inherit the behaviour of surrounding code - seems nasty. We could just mandate that CO_FOO == PyCF_FOO << 12 Or add another flag to code objects. Or do something else. The possibility of fiddling with __future__.py had completely escaped my mind - so thanks for pointing me at that! Cheers, M. -- If you don't use emacs, you're a pathetic, mewling, masochistic weakling and I can't be bothered to convert you. -- Ron Echeverri

1 0