GeezerVison

@skirpichev Would you like to provide benchmark enhancement for this change?

Oops, I just forgot to post one. Description updated.

Please share the pyperformance benchmark results.
I'm not sure how often complex types are used in real-world workloads.
Microbenchmarks like this might suggest adding every built-in type to the freelist, but I don't think that's what we want.
Most of the types we've added so far are commonly used in loop-based operations.

cc @Fidget-Spinner @encukou @eendebakpt

Please share the pyperformance benchmark results.

Well, it shouldn't be affected. This collection has no benchmarks for complex math at all:

$ git grep _E '[0-9.][jJ]|cmath|complex' pyperformance/data-files/benchmarks/||echo Oops
Oops

I'm not sure how often complex types are used in real-world workloads.

Probably less than floats, but not too much.

AFAICS, real-world workloads that don't use complex numbers will pay the price of:

• two unused words of memory
• the maintenance burden of a (I assume!) standard and unsurprising use of _Py_freelist

In applications that do use complex numbers, is it likely that they need to create/destroy them quickly?
IMO, an educated guess is enough to answer that, and if we've established that this is what freelists help with... I'd just trust Sergey here.

To review this I'll need to teach myself about Python's freelists; I can do that next week.

IMO, an educated guess is enough to answer that, and if we've established that this is what freelists help with... I'd just trust Sergey here.

I believe that we use pyperformance benchmark as the real world proxy. So if there is no benchmark for it, I am unsure. At least someone needs to share the benchmark for this. If not, people will add new PR for other built-in types with a microbenchmark, which would not be worth adding. We need criteria for this.

two unused words of memory

Yes, just a new empty _Py_freelists.

In applications that do use complex numbers, is it likely that they need to create/destroy them quickly?

That happens in every arithmetic operation.

Here is a benchmark with a simple sin() implementation:

# bench2.py
def mysin(z):
    i, lasts, s, fact, num, sign = 1, 0, z, 1, z, 1
    while s != lasts:
        lasts = s
        i += 2
        fact *= i*(i-1)
        num *= z*z
        sign *= -1
        s += num/fact*sign
    return s
import pyperf
runner = pyperf.Runner()
runner.bench_func('mysin(1j)', mysin, 1j)
runner.bench_func('mysin(1+1j)', mysin, 1+1j)

To review this I'll need to teach myself about Python's freelists

You are not alone, this is new for me as well :D IIUC (see help topic), this technique is not something, allowed for external C extensions.

If not, people will add new PR for other built-in types with a microbenchmark

I doubt we have too much built-in types. Being a built-in type is a sign from the real world too ;-)

I see this as a PR that speeds up complex numbers, not “X% of Python's real-world usage”. And that's fine.

We need criteria for this.

Why shouldn't the criteria be “any small builtin type where typical usage needs many instances”?

If not, people will add new PR for other built-in types with a microbenchmark, which would not be worth adding.

Why not? What would be the downside of all such built-in types using freelists?

Why shouldn't the criteria be “any small builtin type where typical usage needs many instances”?
Why not? What would be the downside of all such built-in types using freelists?

Then why don’t we just register all built-in objects to the freelist? I think our primary focus is on keeping maintenance costs low. Once we add complex to the freelist, we’ll need to maintain it anyway.

We already have over 20 object types registered. If we’re going to add more, shouldn’t we also consider a more manageable way to maintain them?

We take a similar approach when deciding not to add a fast path, if the benefit isn’t significant enough, we skip it. From what I’ve observed, most recent optimizations are based on pyperformance results.

That said, if you still think we should add this, please go ahead. I just wanted to share my concern about adding it by default. Once an object is added to the freelist, it will usually see some benefit, but we should still weigh that against the maintenance burden.

We already have over 20 object types registered. If we’re going to add more, shouldn’t we also consider a more manageable way to maintain them?

We already have an API for that, the _Py_freelist API which is being used in this PR, no? What do you mean by "a more manageable way to maintain them"?

We already have an API for that, the _Py_freelist API which is being used in this PR, no? What do you mean by "a more manageable way to maintain them"?

I thought of managing the list of types and generating the pycore_freelist_state.h with a Python script. but it looks like not simple, though.

I thought of managing the list of types and generating the pycore_freelist_state.h with a Python script. but it looks like not simple, though.

Oh ok, I see. I'm not sure that it's worth it. This list evolves rarely and IMO the maintenance cost is low.

From what I’ve observed, most recent optimizations are based on pyperformance results.

But pyperformance can't measure any performance changes in the Python core type, complex. Is that a bug or a feature?

But pyperformance can't measure any performance changes in the Python core type, complex. Is that a bug or a feature?

In the past, we observed many optimization enhancements for the binary operation, especially for the int or float types.
More worth optimization would be lowering the opcodes at the JIT optimzation what Ken Jin and Brandt is doing :)

we observed many optimization enhancements for the binary operation, especially for the int or float types.

This is possible for complex type as well, but it's another story.