Skip to content
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

gh-118335: Configure Tier 2 interpreter at build time #118339

Merged
merged 42 commits into from May 1, 2024

Conversation

gvanrossum
Copy link
Member

@gvanrossum gvanrossum commented Apr 27, 2024

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.

@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 some PyUnstable APIs that will only exist when _Py_TIER2 is defined. Thoughts?

EDIT: In particular, we could arguably keep offering PyUnstable_{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 in ENTER_EXECUTOR too. (Possibly in both cases the key issue is that GOTO_TIER_TWO(executor) assumes JIT or Tier 2 IR.)

EDIT 2: Another consideration is whether we'd still want the runtime -Xuops flag and the PYTHON_UOPS env var, when enabled at build time. Or perhaps at least PYTHON_UOPS=0 to disable at runtime (which is a simple change in pylifecycle.c). I'd use that when debugging tests with PYTHON_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/

@gvanrossum
Copy link
Member Author

gvanrossum commented Apr 27, 2024

WASI build is failing, just like it did before when I had an option to disable Tier 2.

I'm away from my Windows laptop so I can't debug the Windows JIT failures yet -- this seems to be in test_opcache.TestRacesDoNotCrash.test_store_attr_with_hint.

@gvanrossum
Copy link
Member Author

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.

@gvanrossum
Copy link
Member Author

Benchmark says 1% faster (in Tier 1 mode).

@gvanrossum
Copy link
Member Author

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 _Py_TIER2 never getting set in a place where it was tested).

It doesn't work. I'm giving up.

This reverts commit 877a005.
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
Copy link
Contributor

@mdboom mdboom left a 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.

@gvanrossum
Copy link
Member Author

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.)

@brandtbucher
Copy link
Member

@brandtbucher Do you have time to review this?

Yep, looking at it now.

Copy link
Member

@brandtbucher brandtbucher left a 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.

Doc/whatsnew/3.13.rst Outdated Show resolved Hide resolved
Doc/whatsnew/3.13.rst Show resolved Hide resolved
Doc/whatsnew/3.13.rst Outdated Show resolved Hide resolved
Lib/test/support/__init__.py Outdated Show resolved Hide resolved
Tools/jit/README.md Show resolved Hide resolved
Python/pylifecycle.c Show resolved Hide resolved
Python/instrumentation.c Show resolved Hide resolved
Python/bytecodes.c Outdated Show resolved Hide resolved
Modules/_opcode.c Outdated Show resolved Hide resolved
@gvanrossum
Copy link
Member Author

@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 --enable-experimental-jit=yes-off. I think this has no repercussions for your new-flags branch of the benchmarking repo, but you may want to double-check.

Copy link
Member

@brandtbucher brandtbucher left a 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!

@gvanrossum
Copy link
Member Author

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:

  • --experimental-jit
  • --experimental-jit-off (build JIT, but default off)
  • --experimental-interpreter
  • --experimental-interpreter-off (undocumented, for Mark :-)

@gvanrossum gvanrossum merged commit 7d83f7b into python:main May 1, 2024
61 checks passed
@gvanrossum gvanrossum deleted the tier2-flag branch May 1, 2024 01:26
gvanrossum added a commit to gvanrossum/cpython that referenced this pull request May 1, 2024
gvanrossum added a commit that referenced this pull request May 1, 2024
…118493)

Also patch up news blurb for gh-118339
(add warning that PYTHON_UOPS is now PYTHON_JIT).
SonicField pushed a commit to SonicField/cpython that referenced this pull request May 8, 2024
…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.
SonicField pushed a commit to SonicField/cpython that referenced this pull request May 8, 2024
…abled (python#118493)

Also patch up news blurb for pythongh-118339
(add warning that PYTHON_UOPS is now PYTHON_JIT).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants