I'd rather not like to see hackery like misused pointers in the core, so you can count me as -1 on this.

-1000 here. In a past life (the ABC implementation) we used this and it was a horrible experience. Basically, there were too many places where you had to make sure you didn't have an integer before dereferencing a pointer, and finding the omissions one core dump at a time was a nightmare. --Guido van Rossum (home page: http://www.python.org/~guido/)

...

-1000 here. In a past life (the ABC implementation) we used this and it was a horrible experience. Basically, there were too many places where you had to make sure you didn't have an integer before dereferencing a pointer, and finding the omissions one core dump at a time was a nightmare.

That certainly seems like it would be so, except... doesn't every bit of Python code that's doing anything *other* than accessing ob_type or ob_refcnt have to first check if ob_type is the type that code is looking for anyway?

And, don't the vast majority of accesses to ob_type and ob_refcnt occur inside Python core API macros and functions anyway?

If in addition to Mr. Knight's patch, ob_type and ob_refcnt were renamed so as to break any existing direct access in the core or extension modules, upgrading them to use Py_GETTYPE and Py_GETREF would be straightforward because one would "find the omissions" one *compilation error* at a time.

Further, renaming those fields to something like 'XXXusePy_GETTYPE_instead' would provide a built-in hint that you weren't supposed to use the field directly. :)

An additional trick: make it so that the macros for defining new object types still create an ob_type field, but let PyObject * point to the structure with the XXX fields. Thus, you can only access ob_type directly if you've already cast to a non PyObject * type. (i.e., you've already used an appropriate PyXXX_Check on that variable and would like to use it as a regular object now).

Naturally, the issues of portability and what impact Mr. Knight's approach has on non-integer code would need to be taken into consideration as well, but it seems to me that this approach *could* be made type-safe, at the cost of some initial pain to update the approximately 640 uses of 'ob_type' in the current source base.

Sorry, I'm still not convinced that it's worth to break all the 3rd party extensions that undoubtedly are doing all sorts of things that strictly speaking they shouldn't do. And what about all the extra code generated for Py_DECREF and Py_INCREF calls? These now all contain an extra jump. Horrors! --Guido van Rossum (home page: http://www.python.org/~guido/)

James Y Knight writes:

Investigating the pybench some more, it seems that speedup for many of the tests is because of the shortcut for tagged types in Py_INCREF and Py_DECREF. E.g. with the pybench TupleSlicing test, as written, the speed diff is -39.13%. However, changing the tuple to contain strings instead of integers causes the change to be +0.03%.

This makes me think that perhaps using an inline tagged representation for things like True, False, and single character strings < 256 might be a win as well, even though they don't ever cause memory allocation -- just because of the refcounting. Well, I tried making booleans a tagged types as well: pybench then runs 11% faster than standard python (vs the 7% with just tagged integers).

Interesting!

P.S.: I have also previously experimented with removing refcounting from Python completely, and using the Boehm GC, because I theorized that refcounting could very well be slower than a full conservative GC. It mostly worked (I did not finish, so it did not support destructors or weakrefs), but was not a win, because it was no longer possible to use large block allocation and free list tricks for integers, and thus integer allocation caused a huge slowdown. I might revisit that now. I do realize using Boehm GC has pretty much a negative probability of making it into standard python, though. :)

The last time I mentioned that the Boehm GC didn't help Python much (on comp.lang.lisp) Hans Boehm showed up and claimed that it was because we weren't using it properly :-) Let us know how it goes... Cheers, mwh -- A difference which makes no difference is no difference at all. -- William James (I think. Reference anyone?)

At 01:41 PM 7/16/04 +1200, Greg Ewing wrote:

James Y Knight :

...

The only thing you can do with an arbitrary PyObject * is access its ob_type or ob_refcnt. Anything else will break with objects today.

One other thing that would break is testing whether an object is an integer and then accessing fields of the integer object directly. Not that this seems a likely thing for people to do, though.

I guess we'd need to XXX-ify ob_ival as well, then. There's already a PyInt_AS_LONG macro that should be used for that purpose. So far, the -1000 from Guido makes it seem unlikely this'll get accepted, though. I am sort of curious, though, as to how many extension modules would actually require changes to support this. A bit of grepping through the source of several I use, seems to indicate that it isn't that common to use ob_type, and it's most likely to appear: 1) in the setup of a type object, setting the type's type to type :) (by far the most common, and not a usage that needs to be changed) 2) in the definition of a macro that verifies the type of an extension object 3) in allocation/deallocation routines Only uses 2 and 3 would need to be changed, and they tend to be quite isolated. By contrast, I didn't find any ob_ival uses, and the only place I saw direct use of ob_refcnt was in some Pyrex-generated tp_dealloc code. Of course, my sampling was hardly statistically valid. I imagine the real extensions to check out would be things like SciPy, Numeric, PIL, wxPython, Boost::Python, win32all, PyCrytpo, etc. That is, widely used packages of very large size. If I understand correctly, extensions have to be recompiled to move between Python versions anyway, and compared to some previous C API changes, this one actually seems pretty minor. Extensions like 'kjbuckets' that were written for early 1.x Python versions definitely needed work to make them build with the later 1.x and 2.x versions.

Brian Quinlan wrote: ...

And the lack of portability is a real problem - it means that every code path must be tested twice AND there might be architectures and problems were tagged integers work but it actually makes things slower.

I think it was not the proposal to use tagging on every platform, but just those where it works. Having this as a compile time feature would make it possible to optimize your Python for your purposes. Things get interesting when it comes to compare refcounting cost vs. pointer decoding cost vs. garbage collection cost. I have no idea what the results will be, and I think it is just *great* to try this out, because the effect could be dramatic: If very many tiny, often-used objects are tagged, then very many refcount actions can be saved, and the overall object count shrinks, Boehm GC might become feasible. If we then can write C extensions without having to think of reference counts, code would be simplified quite much, and I would save 80 percent of debugging time. Maybe we have a set of rules which depend on each other: 1) "Tagging is -1000 because of the headaches" 2) "Everything is object and has refcount" 3) "Many tiny objects must be allocated as blocks" 4) "Boehm GC disables bulk allocation of tiny objects" 1) is just a claim which I would not sign, see the post about systematically renaming fields to find all places with the compiler. 1) leads to 2), 2) leads to 3), and this disables using 4). By solving 1), it might be possible to break the whole chain, and I would even accept a slitghly slower result, if the whole system gets *simpler* by dropping refcounts. So whatever is the outcome, I'm happy that somebody took it on to try this out. ciao - chris -- Christian Tismer :^) mailto:tismer@stackless.com Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

Tim Peters wrote:

[Christian Tismer]

...

... Boehm GC might become feasible. If we then can write C extensions without having to think of reference counts, code would be simplified quite much, and I would save 80 percent of debugging time.

There's no escape from gc debugging nightmares at the C level, regardless of gc strategy. With Boehm gc (Bgc) you have to ensure that all live objects are reachable from what Bgc guesses is the current root set, and screwing that up is just as deadly as screwing up refcounts. It's harder to debug, though, because refcounting is very simple to picture, while Bgc is a relatively huge pile of complicated code in its own right. I'm sure Neil Schemenauer still has fond memories of the pleasant days he spent trying to account for Tk crashes last time he tried hooking Bgc to Python <heh>. Bgc has a special entry point to call, to register roots that Bgc can't find on its own -- guess how *you* find out which roots those are? One crash at a time, and in the presence of threads you're damned lucky to get a repeatable test case.

Well, I was about to stick with this answer. Then I saw that Prothon is going a different path: They don't use a Boehm gc, but they make every object indirect, over a global object table, and use generational garbage collection with arenas. I guess this would not lead to problems like stack introspection, finding roots etc., because all objects are in the object table. Of course it is another level of indirection everywhere, with the advantage that object bodies become moveable. I think this is a simple enough gc to shorten the nightmares. No idea how much the performance loss is, or if this is amortized by the missing reference counting? At least an opportunity to try would be nice to have. If not now, we will try it with PyPy, anyway -- ciao - chris -- Christian Tismer :^) mailto:tismer@stackless.com Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

David Abrahams wrote:

Christian Tismer writes:

...

Then I saw that Prothon is going a different path: They don't use a Boehm gc, but they make every object indirect, over a global object table, and use generational garbage collection with arenas. I guess this would not lead to problems like stack introspection, finding roots etc., because all objects are in the object table. Of course it is another level of indirection everywhere, with the advantage that object bodies become moveable.

That would break countless extension modules, though. Today, extensions can count on stable object addresses.

That's ok. I don't think this whole thread is about a real change of Python in the near future. It is about testing alternatives and to study how things change then. Sure, this is all impossible to make compatible. ciao - chris -- Christian Tismer :^) mailto:tismer@stackless.com Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

Greg Ewing wrote:

Christian Tismer :

...

I guess this would not lead to problems like stack introspection, finding roots etc., because all objects are in the object table.

You still need roots to find reachable objects. The object table contains all objects, whether reachable or not.

I was referring to the problems which Tim pointed out. With an explicit object table, I see much less problems. -- Christian Tismer :^) mailto:tismer@stackless.com Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

On Jul 14, 2004, at 12:28 PM, Jeff Epler wrote:

I tried this back in 2002. http://mail.python.org/pipermail/python-dev/2002-August/027685.html

Interesting that I somehow missed that in my search. I had thought surely someone must've tried it already. Ah well. :) But, I'm glad I did it, because I do have somewhat different results. 1) No segfaults or other weird behavior (all tests pass) 2) With tagged integers does actually benchmark faster than without (although, not by all that much). The version of the patch I sent earlier was indeed slightly slower at pystone than standard python. However, I have made a few changes that have since made it faster, instead: 1) made Py_tagged_types a const array. 2) removed inlining of creation of small ints for PyInt_FromLong. Turns out that makes it go slower not faster. Anyhow, current result is a 3% overall speedup of pystone. 35791 pystones/second (standard python 2.3.3), vs. 36900 pystones/second (tagged integers). I also tried running pybench -w 5. Here's the results, compared to standard python 2.3.3. Overall speedup of 7.19%. I must admit I find these results quite puzzling, as I certainly didn't expect it to affect list slicing that much. Also, that Compare* are so much slower seems strange as well. Perhaps there's something that can be done about that. Tests: per run per oper. diff *) ------------------------------------------------------------------------ BuiltinFunctionCalls: 227.75 ms 0.45 us -3.72% BuiltinMethodLookup: 386.30 ms 0.18 us +3.33% CompareFloats: 283.50 ms 0.16 us +57.46% CompareFloatsIntegers: 343.35 ms 0.19 us -1.07% CompareIntegers: 261.90 ms 0.07 us -0.44% CompareInternedStrings: 210.10 ms 0.11 us +19.68% CompareLongs: 244.45 ms 0.14 us +30.65% CompareStrings: 338.05 ms 0.17 us +11.73% CompareUnicode: 265.35 ms 0.18 us +17.70% ConcatStrings: 456.20 ms 0.76 us -3.31% ConcatUnicode: 564.00 ms 0.94 us -2.92% CreateInstances: 300.30 ms 1.79 us -2.52% CreateStringsWithConcat: 178.35 ms 0.22 us +4.54% CreateUnicodeWithConcat: 559.35 ms 0.70 us +3.84% DictCreation: 230.50 ms 0.38 us -12.02% DictWithFloatKeys: 504.20 ms 0.21 us -5.86% DictWithIntegerKeys: 225.10 ms 0.09 us -22.82% DictWithStringKeys: 247.20 ms 0.10 us -7.98% ForLoops: 183.85 ms 4.60 us -18.97% IfThenElse: 211.60 ms 0.08 us -2.78% ListSlicing: 81.70 ms 5.84 us -60.64% NestedForLoops: 141.95 ms 0.09 us -12.38% NormalClassAttribute: 296.05 ms 0.12 us -4.25% NormalInstanceAttribute: 266.15 ms 0.11 us -10.51% PythonFunctionCalls: 336.45 ms 0.51 us -10.05% PythonMethodCalls: 277.80 ms 0.93 us -1.35% Recursion: 233.50 ms 4.67 us -18.99% SecondImport: 191.85 ms 1.92 us +4.44% SecondPackageImport: 205.75 ms 2.06 us +3.03% SecondSubmoduleImport: 255.75 ms 2.56 us +3.67% SimpleComplexArithmetic: 206.70 ms 0.23 us +4.21% SimpleDictManipulation: 172.50 ms 0.14 us -14.22% SimpleFloatArithmetic: 296.15 ms 0.13 us +8.32% SimpleIntFloatArithmetic: 183.85 ms 0.07 us -33.65% SimpleIntegerArithmetic: 182.00 ms 0.07 us -32.62% SimpleListManipulation: 217.50 ms 0.20 us -10.12% SimpleLongArithmetic: 161.70 ms 0.25 us +6.73% SmallLists: 562.85 ms 0.55 us +13.40% SmallTuples: 468.30 ms 0.49 us +15.70% SpecialClassAttribute: 289.00 ms 0.12 us -5.97% SpecialInstanceAttribute: 460.00 ms 0.19 us -1.33% StringMappings: 319.10 ms 0.63 us -0.17% StringPredicates: 297.50 ms 0.27 us -0.77% StringSlicing: 270.00 ms 0.39 us -1.93% TryExcept: 203.20 ms 0.03 us +0.15% TryRaiseExcept: 217.40 ms 3.62 us -28.71% TupleSlicing: 223.55 ms 0.53 us -42.15% UnicodeMappings: 250.10 ms 3.47 us +0.44% UnicodePredicates: 257.60 ms 0.29 us +2.79% UnicodeProperties: 398.55 ms 0.50 us +6.69% UnicodeSlicing: 395.95 ms 0.57 us +1.71% ------------------------------------------------------------------------ Average round time: 15663.00 ms -7.19% For comparison, here's the results from standard python: Tests: per run per oper. overhead ------------------------------------------------------------------------ BuiltinFunctionCalls: 236.55 ms 0.46 us 0.50 ms BuiltinMethodLookup: 373.85 ms 0.18 us 1.00 ms CompareFloats: 180.05 ms 0.10 us 1.00 ms CompareFloatsIntegers: 347.05 ms 0.19 us 1.00 ms CompareIntegers: 263.05 ms 0.07 us 2.00 ms CompareInternedStrings: 175.55 ms 0.09 us 3.50 ms CompareLongs: 187.10 ms 0.10 us 1.00 ms CompareStrings: 302.55 ms 0.15 us 3.50 ms CompareUnicode: 225.45 ms 0.15 us 2.50 ms ConcatStrings: 471.80 ms 0.79 us 1.00 ms ConcatUnicode: 580.95 ms 0.97 us 1.00 ms CreateInstances: 308.05 ms 1.83 us 1.00 ms CreateStringsWithConcat: 170.60 ms 0.21 us 1.00 ms CreateUnicodeWithConcat: 538.65 ms 0.67 us 1.00 ms DictCreation: 262.00 ms 0.44 us 1.00 ms DictWithFloatKeys: 535.60 ms 0.22 us 3.50 ms DictWithIntegerKeys: 291.65 ms 0.12 us 3.50 ms DictWithStringKeys: 268.65 ms 0.11 us 3.00 ms ForLoops: 226.90 ms 5.67 us 0.50 ms IfThenElse: 217.65 ms 0.08 us 2.50 ms ListSlicing: 207.55 ms 14.83 us 0.50 ms NestedForLoops: 162.00 ms 0.11 us 0.00 ms NormalClassAttribute: 309.20 ms 0.13 us 1.50 ms NormalInstanceAttribute: 297.40 ms 0.12 us 1.50 ms PythonFunctionCalls: 374.05 ms 0.57 us 1.00 ms PythonMethodCalls: 281.60 ms 0.94 us 0.50 ms Recursion: 288.25 ms 5.77 us 0.50 ms SecondImport: 183.70 ms 1.84 us 0.50 ms SecondPackageImport: 199.70 ms 2.00 us 0.50 ms SecondSubmoduleImport: 246.70 ms 2.47 us 0.50 ms SimpleComplexArithmetic: 198.35 ms 0.23 us 1.00 ms SimpleDictManipulation: 201.10 ms 0.17 us 0.50 ms SimpleFloatArithmetic: 273.40 ms 0.12 us 2.00 ms SimpleIntFloatArithmetic: 277.10 ms 0.10 us 2.00 ms SimpleIntegerArithmetic: 270.10 ms 0.10 us 2.00 ms SimpleListManipulation: 242.00 ms 0.22 us 1.00 ms SimpleLongArithmetic: 151.50 ms 0.23 us 0.50 ms SmallLists: 496.35 ms 0.49 us 2.50 ms SmallTuples: 404.75 ms 0.42 us 1.50 ms SpecialClassAttribute: 307.35 ms 0.13 us 2.00 ms SpecialInstanceAttribute: 466.20 ms 0.19 us 2.00 ms StringMappings: 319.65 ms 0.63 us 1.50 ms StringPredicates: 299.80 ms 0.27 us 5.00 ms StringSlicing: 275.30 ms 0.39 us 1.50 ms TryExcept: 202.90 ms 0.03 us 3.00 ms TryRaiseExcept: 304.95 ms 5.08 us 1.00 ms TupleSlicing: 386.40 ms 0.92 us 0.50 ms UnicodeMappings: 249.00 ms 3.46 us 1.00 ms UnicodePredicates: 250.60 ms 0.28 us 6.50 ms UnicodeProperties: 373.55 ms 0.47 us 6.50 ms UnicodeSlicing: 389.30 ms 0.56 us 2.00 ms ------------------------------------------------------------------------ Average round time: 16876.00 ms James

Greg Ewing writes:

James Y Knight :

...

On the test that probably puts my change in the most positive light possible: "x = 0; while x < 50000000: x = x + 1", it achieves about a 50% increase in speed. More normal integer-heavy things seem to be at most 20% faster.

And you have to ask yourself -- how integer-heavy does typical Python code get?

Most Python code I write deals with higher-level things most of the time -- strings, lists, dicts, class instances.

It's kinda hard to work seriously with lists and strings without integers :-) This was, at the very least, a worthwhile experiment... Cheers, mwh -- Python enjoys making tradeoffs that drive *someone* crazy <wink>. -- Tim Peters, comp.lang.python