bpo-40521: Make dict free lists per-interpreter

[vstinner]

Each interpreter now has its own dict free list:

• Move dict free lists into PyInterpreterState.
• Move PyDict_MAXFREELIST define to pycore_interp.h
• Add _Py_dict_state structure.
• Add tstate parameter to _PyDict_ClearFreeList() and _PyDict_Fini().
• _PyLong_Fini() and _PyFloat_Fini() are now called after
  _PyDict_Fini().
• Remove "#ifdef EXPERIMENTAL_ISOLATED_SUBINTERPRETERS".

https://bugs.python.org/issue40521

[vstinner]

After tuple (commit 69ac6e5) and list (commit 88ec919) and others types (see bpo-40521), it's now the turn of dict to get its free lists moved to PyInterpreterState! FYI when I measured the tuple PR overhead, it was around 1 ns (and create a tuple of 1 item is around 20 ns): see PR #20247.

cc @methane @pablogsal

[vstinner]

With this PR, all free lists cleared by gc.collect() are per-interpreter.

[vstinner]

Before anyone asks, here is a microbenchmark on PyDict_New() to measure the overhead of this PR:

Mean +- std dev: [ref] 10.9 ns +- 0.9 ns -> [patch] 12.8 ns +- 1.0 ns: 1.18x slower (+18%)

The PR adds +1.9 ns per PyDict_New() call.

I used bench_dict.patch which is attached to https://bugs.python.org/issue40521.

UPDATE: please notice that the std dev is around 1 ns which is close to the overhead. These microbenchmark are so small that it is really hard to get a precise measure of timings.

[methane]

@vstinner Would you benchmark without freelist too?
If benefit of the freelist becomes too small, removing it is better than making it per-interpreter.

[vstinner]

@vstinner Would you benchmark without freelist too?

Here you have:

vstinner@apu$ python3 -m pyperf compare_to ref.json patch.json no_freelist.json 
Mean +- std dev: [ref] 10.9 ns +- 0.9 ns -> [patch] 12.8 ns +- 1.0 ns: 1.18x slower (+18%)
Mean +- std dev: [ref] 10.9 ns +- 0.9 ns -> [no_freelist] 18.0 ns +- 1.0 ns: 1.65x slower (+65%)

If benefit of the freelist becomes too small, removing it is better than making it per-interpreter.

Disabling the free list adds +7.1 ns per PyDict_New() call: 1.65x slower. It doesn't sound reasonable to remove free_list in dictobject.c.

[vstinner]

TODO: implement commit bcb1983 for dict free lists. See https://bugs.python.org/issue40887 for the context.

[vstinner]

@methane: So, what do you think?

I rebased my PR on top of the master branch.

TODO: implement commit bcb1983 for dict free lists. See https://bugs.python.org/issue40887 for the context.

Done. In debug mode, trying to use dict free lists after they are finalized now fails with an assertion error.

[methane]

The discussion in the ML didn't go anywhere.
I'm OK to merge this.

[vstinner]

I'm OK to merge this.

Thanks @methane for the review! I'm still interested to attempt to reduce the overhead of this change. See my PR #20767 for example. But so I failed to find a method which has a significant impact on performance.

Again, measuring performance of a function taking around 10 ns is really hard. The machine code changes depending on LTO and/or PGO build modes, compiler flags, etc. And sometimes it's faster, sometimes it's slower...