At 11:11 PM 4/15/04 -0700, Paul Prescod wrote:

I think the idea is more that you could skip the 'Py_INCREF(Py_None)', which is a fairly common prelude to 'return Py_None'. You'd set their refcounts to the maximum possible value, and the deallocation function would simply reset the refcount to maximum again.

I'm not sure, however, that this would be common enough to be helpful. It seems to me Py_INCREF should effectively translate to only a single machine instruction or two. I mean, it's just incrementing an integer whose address is known at compile time.

Hi,

pje wrote:

I don't think it would matter much performance-wise. A quick scan does not reveal a single Py_INCREF(Py_None) in any hot code section. But with more than 800 occurences it would reduce the code size a bit (5-10K). So that alone is not a good reason to throw it out.

Checking for Py_None in Py_DECREF is counter-productive because that would need another branch. The existing branch is always taken with Py_None since the refcount never goes zero. I.e. this is not an issue.

But let's look at the general case. Here's a common fragment of inlined x86 code for Py_DECREF:

mov -something(%ebp),%esi ; odep %esi mov (%esi),%eax ; idep %esi, odep %eax dec %eax ; idep %eax, odep %eax test %eax,%eax ; [idep %eax], odep flags mov %eax,(%esi) ; [idep %eax %esi] jne .L1 ; idep flags, predict

sub $0xc,%esp mov 0x4(%esi),%eax push %esi call *0x18(%eax) add $0x10,%esp .L1:

There are at least 2 to 3 data dependencies that are hard to untangle. Tough luck.

The other problem is branch prediction. I've done a little analysis with gcov on ceval.c and found that the situation is not that bad. The Py_DECREF occurences that account for 90% of the time are almost exclusively 0/100 or 100/0 cases. The remaining 10% have a few 30/70 or 50/50 cases. The folded and weighted average is around 4/96. The branch misprediction penalty accounts for less than 0.1% of the runtime.

But the deallocation itself is costly. On average the deallocator is called 15% of the time (I checked ceval.c only). This is a lot and accounts for up to 5% of the runtime (this is based on an overall profile). My guess is that allocation is a bit cheaper, but adds another 2-3%. I think tuples are the worst offender (again only a good guess from my profiling experiments).

To summarize: I think we can optimize the GC a little more (have not done an in-depth analysis yet), but we really should focus on making Python less malloc-happy. Suggestions welcome!

Bye, Mike

Hi,

Aahz wrote:

I'm very well aware of the tradeoffs between refcounting and pure GC schemes. I do not suggest that we change CPython's approach. And I do not intend to start another refcount-vs-GC flamewar. You've got me wrong.

Also please check the thread -- I never suggested modifying anything about Py_None. I just presented a short quantitative analysis that it's useless to do so (the thread you referenced contains another good reason).

What I meant with 'less malloc-happy' is that we should try to reduce the number of allocations/deallocations for internal (!) objects (I'm not talking about objects explicitly managed by the application). Many of them have a very short time-to-live. I guess some of them could be recycled or even optimized away.

E.g. global profiling indicates that tuple allocation/deallocation has a noticeable effect on performance. There are probably other objects that have prohibitive setup/teardown cost (but are less pronounced on allocation costs).

But since this is only #4 on my list I have not given it a closer look. That's why I said 'suggestions welcome'.

Bye, Mike

Maybe something like this:

# ifdef __GCC__

# define constant_p(x) __builtin_constant_p(x)

# else

# define constant_p(x) 0

# endif

# define Py_INCREF(x) \

if( ! constant_p(x) || (x != Py_None && x != other immortals)) \
    actual Py_INCREF body(x)

this should allow the compiler, by constant propagation, to skip actual Py_INCREF body when it sees Py_INCREF(Py_None) and when it's Py_INCREF(nonconstant) to have no test for equality with the immortal values.

does this actually work? I didn't check. I think that on some important systems there may be no equivalent to gcc's __builtin_constant_p(), and that Py_None is not a compile-time constant (cough DLLs cough)

Jeff