GeezerVison

https://github.com/facebookexperimental/free-threading-benchmarking/actions/runs/39860993693

Based on an analysis of python -c "import re", with help from a script
written with Claude and run under gdb.

The effect of reducing the page size differs by object size.

cc @nascheme

@DinoV @nascheme @mpage
According to the benchmark results, this change reduces memory usage by 3% compared to the baseline, with no performance regression. Although there is no comparison with the default build, the results do confirm a reduction in memory usage.

cc @daanx

@nascheme @DinoV
The results from Tools/gcbench from Thomas show that reducing the page size from 64 KiB to 16 KiB increases GC time by 6–8%, since each collection visits four times as many pages. GC-bound pathological cases are 5–8% slower, while steady-state workloads and pyperformance show no change in total runtime.

Peak RSS is generally unchanged on these large-heap tests, although bigcollect/container shows an 11% increase. That case would be worth a separate follow-up if we decide to merge this PR.

This PR aims to reduce the memory overhead relative to the default build from the current 18% to 15%, as measured by pyperformance. I think we should also compare against the default build using the GC benchmarks to make sure both the performance and memory overheads remain within the guardrails outlined in PEP 779. If both criteria are met, I would like to propose merging this PR.

I’ll share the results once I’ve run the GC benchmarks against the default build.

Even in GC benchmark this tune does not harmful to the current free-threaded build
(I re-oreganize as pyperf style result)

Benchmarks with tag 'pathology': time

Benchmarks with tag 'pathology': peak memory

Benchmarks with tag 'workloads': time

Benchmarks with tag 'workloads': peak memory

Benchmarks with tag 'threads': time

Benchmarks with tag 'threads': peak memory

Overall

• Time geometric mean (21 benchmarks, excluding (†)): FT 64K 1.01x faster, FT 16K 1.01x slower
• Time geometric mean incl. (†) (23): FT 64K 1.02x faster, FT 16K 1.06x faster
• (†) bigbuffers: README says the runs are too short to time; shown but excluded from the main geomean. (*) event_widgets runaway, ext_buffers_malloc: large run-to-run variance.
• Memory usage (23 benchmarks): FT 64K 1.36x, FT 16K 1.38x
• Memory usage without (*) benchmarks (21): FT 64K 1.20x, FT 16K 1.21x
• FT 16K vs FT 64K memory: 1.016x (without (*): 1.006x)

This seems to be a classic time-vs-space tradeoff. Generally, I would lean towards sticking with upstream 64k since it doesn't make a large difference. However, since Donghee did extensive testing and it does seem a small win with no major regressions, this seems safe to change. Another point: if we can port some of the GC optimizations from the default build, doing fewer heap traversals by combining passes, this would likely be a bigger win.

Another point: if we can port some of the GC optimizations from the default build, doing fewer heap traversals by combining passes, this would likely be a bigger win.

Yeah, we should collect which points we could simply port to the free-threaded build from the default build; I will create an issue about this.