-
-
Notifications
You must be signed in to change notification settings - Fork 32k
gh-118335: Configure Tier 2 interpreter at build time #118339
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…pt _testinternalcapi
There's also this failure (a hang in test_multiprocessing, apparently): https://github.com/python/cpython/actions/runs/8857124270/job/24324215355?pr=118339 PS. I've updated the discussion in the initial comment. |
Benchmark says 1% faster (in Tier 1 mode). |
Looks like Windows JIT builds now pass. WASI build still fails. I wonder if there's something in the WASI build similar to the Windows problem (which had to do with |
It doesn't work. I'm giving up. This reverts commit 877a005.
…l-jit=XXX There's more to do.
The value is a bitflag: - 0: off - 1: JIT, on by default - 3: JIT, off by default (not yet implemented, requires fiddling pystate.c) - 4: tier 2 interpreter, on by default
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This may already be on your radar, but a reminder to also update the Windows build.bat
script to support this 4-way option.
WASI bliss at last. @brandtbucher Do you have time to review this? @mdboom I peeked at your new-flags branch in the benchmarking repo. We lose the ability to benchmark Tier 2 on Windows (for now) -- is that reflected in the diff there? (As an only occasional user of the UI there I rely on the script to let me know if I've selected an impossible combination.) |
Yep, looking at it now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for taking the time to tackle this. Performing the surgery after-the-fact definitely seems like a tricky task.
Misc/NEWS.d/next/Core and Builtins/2024-04-26-14-06-18.gh-issue-118335.SRFsxO.rst
Outdated
Show resolved
Hide resolved
@brandtbucher I believe I've done everything from your review that I gave a thumbs up, and for everything else I stated a reason. @mdboom -- At Brandt's suggestion I've shortened the "default off" flag to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@brandtbucher I believe I've done everything from your review that I gave a thumbs up, and for everything else I stated a reason.
Yep!
Apparently makes the CI fuzzer unhappy. This reverts commit 3c919bb.
Okay, I've got the Windows flag stuff sorted out. It's a little different from Unix, because you apparently can't say "--experimental-jit=yes-off" while also supporting "--experimental-jit"; it treats the "=" as a space. Rather than becoming a .BAT file CLI parsing expert I chose the following option names:
|
…18339) The code for Tier 2 is now only compiled when configured with `--enable-experimental-jit[=yes|interpreter]`. We drop support for `PYTHON_UOPS` and -`Xuops`, but you can disable the interpreter or JIT at runtime by setting `PYTHON_JIT=0`. You can also build it without enabling it by default using `--enable-experimental-jit=yes-off`; enable with `PYTHON_JIT=1`. On Windows, the `build.bat` script supports `--experimental-jit`, `--experimental-jit-off`, `--experimental-interpreter`. In the C code, `_Py_JIT` is defined as before when the JIT is enabled; the new variable `_Py_TIER2` is defined when the JIT *or* the interpreter is enabled. It is actually a bitmask: 1: JIT; 2: default-off; 4: interpreter.
…abled (python#118493) Also patch up news blurb for pythongh-118339 (add warning that PYTHON_UOPS is now PYTHON_JIT).
The code for Tier 2 is now only compiled when configured with
--enable-experimental-jit[=yes|interpreter]
. We drop support forPYTHON_UOPS
and -Xuops
, but you can disable the interpreter or JIT at runtime by settingPYTHON_JIT=0
. You can also build it without enabling it by default using--enable-experimental-jit=yes-off
; enable withPYTHON_JIT=1
.@mdboom See note in issue about benchmarking setup.
@markshannon An alternative approach would be to keep the APIs but make them always fail. In particular, there are somePyUnstable
APIs that will only exist when_Py_TIER2
is defined. Thoughts?EDIT: In particular, we could arguably keep offeringPyUnstable_{Get,Set}Optimizer
, so 3rd parties could create and activate their own optimizers, like in your original design (which I cannot find back -- you had something where 3rd parties could register optimizations and parameters indicating the cost and benefit, or something). However, the rest of the optimizer machinery is now dependent on executors (starting with_PyOptimizer_Optimize
, ). If we wanted to keep supporting both optimizers and executors, we'd have to do something different inENTER_EXECUTOR
too. (Possibly in both cases the key issue is thatGOTO_TIER_TWO(executor)
assumes JIT or Tier 2 IR.)EDIT 2: Another consideration is whether we'd still want the runtime-Xuops
flag and thePYTHON_UOPS
env var, when enabled at build time. Or perhaps at leastPYTHON_UOPS=0
to disable at runtime (which is a simple change in pylifecycle.c). I'd use that when debugging tests withPYTHON_LLTRACE=N
, since the debug output from the test infrastructure might overwhelm that for the test proper.Yet another option would be to leave everything as it was, except change the default with the build-time flag.📚 Documentation preview 📚: https://cpython-previews--118339.org.readthedocs.build/