Add free threading scaling microbenchmarks #125985
Labels
Comments
colesbury
added
type-feature
colesbury
added a commit
to colesbury/cpython
that referenced
this issue
Oct 25, 2024
These consist of a number of short snippets that help identify scaling bottlenecks in the free threaded interpreter. The current bottlenecks are in calling functions in benchmarks that call functions (due to `LOAD_ATTR` not yet using deferred reference counting) and when accessing thread-local data.
colesbury
added a commit
to colesbury/cpython
that referenced
this issue
Oct 28, 2024
colesbury
added a commit
that referenced
this issue
Oct 28, 2024
These consist of a number of short snippets that help identify scaling bottlenecks in the free threaded interpreter. The current bottlenecks are in calling functions in benchmarks that call functions (due to `LOAD_ATTR` not yet using deferred reference counting) and when accessing thread-local data.
picnixz
pushed a commit
to picnixz/cpython
that referenced
this issue
Dec 8, 2024
…125986) These consist of a number of short snippets that help identify scaling bottlenecks in the free threaded interpreter. The current bottlenecks are in calling functions in benchmarks that call functions (due to `LOAD_ATTR` not yet using deferred reference counting) and when accessing thread-local data.
colesbury
added a commit
to colesbury/cpython
that referenced
this issue
Jan 3, 2025
Add a separate benchmark that measures the effect of `_PyObject_LookupSpecial()` on scaling. In the process of cleaning up the scaling benchmarks for inclusion, I unintentionally changed the "cmodule_function" benchmark to pass an `int` to `math.floor()` instead of a `float`, which causes it to use the `_PyObject_LookupSpecial()` code path. `_PyObject_LookupSpecial()` has its own scaling issues that we want to measure separately from calling a function on a C module.
colesbury
added a commit
that referenced
this issue
Jan 3, 2025
Add a separate benchmark that measures the effect of `_PyObject_LookupSpecial()` on scaling. In the process of cleaning up the scaling benchmarks for inclusion, I unintentionally changed the "cmodule_function" benchmark to pass an `int` to `math.floor()` instead of a `float`, which causes it to use the `_PyObject_LookupSpecial()` code path. `_PyObject_LookupSpecial()` has its own scaling issues that we want to measure separately from calling a function on a C module.
WolframAlph
pushed a commit
to WolframAlph/cpython
that referenced
this issue
Jan 4, 2025
…28460) Add a separate benchmark that measures the effect of `_PyObject_LookupSpecial()` on scaling. In the process of cleaning up the scaling benchmarks for inclusion, I unintentionally changed the "cmodule_function" benchmark to pass an `int` to `math.floor()` instead of a `float`, which causes it to use the `_PyObject_LookupSpecial()` code path. `_PyObject_LookupSpecial()` has its own scaling issues that we want to measure separately from calling a function on a C module.
srinivasreddy
pushed a commit
to srinivasreddy/cpython
that referenced
this issue
Jan 8, 2025
…28460) Add a separate benchmark that measures the effect of `_PyObject_LookupSpecial()` on scaling. In the process of cleaning up the scaling benchmarks for inclusion, I unintentionally changed the "cmodule_function" benchmark to pass an `int` to `math.floor()` instead of a `float`, which causes it to use the `_PyObject_LookupSpecial()` code path. `_PyObject_LookupSpecial()` has its own scaling issues that we want to measure separately from calling a function on a C module.
ebonnal
pushed a commit
to ebonnal/cpython
that referenced
this issue
Jan 12, 2025
…125986) These consist of a number of short snippets that help identify scaling bottlenecks in the free threaded interpreter. The current bottlenecks are in calling functions in benchmarks that call functions (due to `LOAD_ATTR` not yet using deferred reference counting) and when accessing thread-local data.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Feature or enhancement
I've been using a simple script to help identify and track scaling bottlenecks in the free threading build. The benchmarks consists of patterns that ought to scale well, but haven't in the past, typically due to reference count contention or lock contention.
I think this is generally useful for people working on free-threading and would like to include it under
Tools, perhaps asTools/ftscalingbench/ftscalingbench.py.Note that this is not intended to be a general multithreading benchmark suite, nor are the benchmarks intended to be representative of real-world workloads. The benchmarks are only intended to help identify and track scaling bottlenecks that occur in basic usage.
Here is the original script, I've since made some modifications:
https://github.com/colesbury/nogil-micro-benchmarks
Linked PRs
cmodule_function()scaling benchmark #128460The text was updated successfully, but these errors were encountered: