# PEP 744: JIT Compilation **URL:** \ **Category:** PEPs\ **Created:** [April 12, 2024, 12:33am UTC](https://discuss.python.org/t/pep-744-jit-compilation/50756 "2024-04-12T00:33:50Z")\ **Posts on this page:** 19\ **Page:** 3
**Author:** ![hroncok](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hroncok/32/18696_2.png) [@hroncok](https://discuss.python.org/u/hroncok)\ **Post date:** [May 10, 2024, 8:47am UTC](https://discuss.python.org/t/pep-744-jit-compilation/50756/44 "2024-05-10T08:47:03Z")
Has this happened in time for b1? ---
**Author:** ![brandtbucher](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brandtbucher/32/22862_2.png) [@brandtbucher](https://discuss.python.org/u/brandtbucher)\ **Post date:** [May 10, 2024, 2:48pm UTC](https://discuss.python.org/t/pep-744-jit-compilation/50756/45 "2024-05-10T14:48:58Z")
Yep, all of these build options (and the environment variable) are available on the tagged release: [gh-118335: Configure Tier 2 interpreter at build time by gvanrossum · Pull Request #118339 · python/cpython (github.com)](https://github.com/python/cpython/pull/118339) ---
**Author:** ![hroncok](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hroncok/32/18696_2.png) [@hroncok](https://discuss.python.org/u/hroncok)\ **Post date:** [May 10, 2024, 3:56pm UTC](https://discuss.python.org/t/pep-744-jit-compilation/50756/46 "2024-05-10T15:56:52Z")
This is as far as I got in the Fedora package by adding `--enable-experimental-jit=yes-off`: ```python ... python3.13 /builddir/build/BUILD/Python-3.13.0b1/Tools/jit/build.py x86_64-redhat-linux-gnu --debug ============================================================== JIT support for x86_64-redhat-linux-gnu is still experimental! Please report any issues you encounter. ============================================================== python3.13 /builddir/build/BUILD/Python-3.13.0b1/Tools/jit/build.py x86_64-redhat-linux-gnu --debug ============================================================== JIT support for x86_64-redhat-linux-gnu is still experimental! Please report any issues you encounter. ============================================================== gcc -c -fno-strict-overflow -Wsign-compare -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -DDYNAMIC_ANNOTATIONS_ENABLED=1 -fexceptions -fcf-protection -fexceptions -fcf-protection -fexceptions -fcf-protection -O0 -Wno-cpp -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -D_GNU_SOURCE -fPIC -fwrapv -D_Py_TIER2=3 -D_Py_JIT -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -g -std=c11 -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes -Werror=implicit-function-declaration -fvisibility=hidden -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -D_GNU_SOURCE -fPIC -fwrapv -O0 -Wno-cpp -I/builddir/build/BUILD/Python-3.13.0b1/Include/internal -I/builddir/build/BUILD/Python-3.13.0b1/Include/internal/mimalloc -IObjects -IInclude -IPython -I. -I/builddir/build/BUILD/Python-3.13.0b1/Include -fPIC -DPy_BUILD_CORE -o Python/jit.o /builddir/build/BUILD/Python-3.13.0b1/Python/jit.c In file included from /builddir/build/BUILD/Python-3.13.0b1/Python/jit.c:392: ./jit_stencils.h: In function ‘emit__DELETE_DEREF’: ./jit_stencils.h:15433:39: error: ‘_PyCriticalSection_BeginSlow’ undeclared (first use in this function) 15433 | patch_64(data + 0xf0, (uintptr_t)&_PyCriticalSection_BeginSlow); | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~./jit_stencils.h:15433:39: note: each undeclared identifier is reported only once for each function it appears in ./jit_stencils.h:15435:40: error: ‘_PyCriticalSection_Resume’ undeclared (first use in this function) 15435 | patch_64(data + 0x100, (uintptr_t)&_PyCriticalSection_Resume); | ^ ~~~~~~~~~~~~~~~~~~~~~~~~./jit_stencils.h: In function ‘emit__LOAD_DEREF’: ./jit_stencils.h:29402:39: error: ‘_PyCriticalSection_BeginSlow’ undeclared (first use in this function) 29402 | patch_64(data + 0xb0, (uintptr_t)&_PyCriticalSection_BeginSlow); | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~./jit_stencils.h:29405:39: error: ‘_PyCriticalSection_Resume’ undeclared (first use in this function) 29405 | patch_64(data + 0xc8, (uintptr_t)&_PyCriticalSection_Resume); | ^ ~~~~~~~~~~~~~~~~~~~~~~~~./jit_stencils.h: In function ‘emit__LOAD_FROM_DICT_OR_DEREF’: ./jit_stencils.h:31160:40: error: ‘_PyCriticalSection_BeginSlow’ undeclared (first use in this function) 31160 | patch_64(data + 0x1d8, (uintptr_t)&_PyCriticalSection_BeginSlow); | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~./jit_stencils.h:31163:40: error: ‘_PyCriticalSection_Resume’ undeclared (first use in this function) 31163 | patch_64(data + 0x1f0, (uintptr_t)&_PyCriticalSection_Resume); | ^ ~~~~~~~~~~~~~~~~~~~~~~~~./jit_stencils.h: In function ‘emit__STORE_DEREF’: ./jit_stencils.h:38406:39: error: ‘_PyCriticalSection_BeginSlow’ undeclared (first use in this function) ./jit_stencils.h:38408:39: error: ‘_PyCriticalSection_Resume’ undeclared (first use in this function) make: *** [Makefile:3018: Python/jit.o] Error 1 ``` ---
**Author:** ![brandtbucher](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brandtbucher/32/22862_2.png) [@brandtbucher](https://discuss.python.org/u/brandtbucher)\ **Post date:** [May 10, 2024, 5:35pm UTC](https://discuss.python.org/t/pep-744-jit-compilation/50756/47 "2024-05-10T17:35:54Z")
It looks like you’re trying to build with `--disable-gil` too, which is something we hadn’t really tested yet. That issue is being tracked [here](https://github.com/python/cpython/issues/118844). Does the build succeed on normal, non-free-threaded builds? ---
**Author:** ![hroncok](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hroncok/32/18696_2.png) [@hroncok](https://discuss.python.org/u/hroncok)\ **Post date:** [May 10, 2024, 10:30pm UTC](https://discuss.python.org/t/pep-744-jit-compilation/50756/48 "2024-05-10T22:30:23Z")
When I only pass `--enable-experimental-jit=yes-off` to the non-free-threaded builds, I get: ```python python3.13 /builddir/build/BUILD/Python-3.13.0b1/Tools/jit/build.py x86_64-redhat-linux-gnu --debug ============================================================== JIT support for x86_64-redhat-linux-gnu is still experimental! Please report any issues you encounter. ============================================================== python3.13 /builddir/build/BUILD/Python-3.13.0b1/Tools/jit/build.py x86_64-redhat-linux-gnu --debug ============================================================== JIT support for x86_64-redhat-linux-gnu is still experimental! Please report any issues you encounter. ============================================================== gcc -c -fno-strict-overflow -Wsign-compare -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -DDYNAMIC_ANNOTATIONS_ENABLED=1 -fcf-protection -fexceptions -fcf-protection -fexceptions -fcf-protection -fexceptions -O0 -Wno-cpp -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -D_GNU_SOURCE -fPIC -fwrapv -D_Py_TIER2=3 -D_Py_JIT -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -g -std=c11 -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes -Werror=implicit-function-declaration -fvisibility=hidden -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -D_GNU_SOURCE -fPIC -fwrapv -O0 -Wno-cpp -I/builddir/build/BUILD/Python-3.13.0b1/Include/internal -I/builddir/build/BUILD/Python-3.13.0b1/Include/internal/mimalloc -IObjects -IInclude -IPython -I. -I/builddir/build/BUILD/Python-3.13.0b1/Include -fPIC -DPy_BUILD_CORE -o Python/jit.o /builddir/build/BUILD/Python-3.13.0b1/Python/jit.c /builddir/build/BUILD/Python-3.13.0b1/Python/jit.c: In function ‘emit__MATCH_MAPPING’: /builddir/build/BUILD/Python-3.13.0b1/Python/jit.c:395:1: error: expected expression before ‘int’ 395 | int | ^~~ /builddir/build/BUILD/Python-3.13.0b1/Python/jit.c:479:1: error: expected declaration or statement at end of input 479 | } | ^ In file included from /builddir/build/BUILD/Python-3.13.0b1/Python/jit.c:392: ./jit_stencils.h:30254:25: warning: unused variable ‘data_body’ [-Wunused-variable] 30254 | const unsigned char data_body[24] = { | ^ ~~~~~~~~./jit_stencils.h:30241:25: warning: unused variable ‘code_body’ [-Wunused-variable] 30241 | const unsigned char code_body[53] = { | ^ ~~~~~~~~ /builddir/build/BUILD/Python-3.13.0b1/Python/jit.c: At top level: /builddir/build/BUILD/Python-3.13.0b1/Python/jit.c:87:1: warning: ‘mark_executable’ defined but not used [-Wunused-function] 87 | mark_executable(unsigned char *memory, size_t size) | ^ ~~~~~~~~~~~~~~ /builddir/build/BUILD/Python-3.13.0b1/Python/jit.c:70:1: warning: ‘jit_free’ defined but not used [-Wunused-function] 70 | jit_free(unsigned char *memory, size_t size) | ^ ~~~~~~~ /builddir/build/BUILD/Python-3.13.0b1/Python/jit.c:49:1: warning: ‘jit_alloc’ defined but not used [-Wunused-function] 49 | jit_alloc(size_t size) | ^ ~~~~~~~~ make: *** [Makefile:3018: Python/jit.o] Error 1 ``` ---
**Author:** ![brandtbucher](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brandtbucher/32/22862_2.png) [@brandtbucher](https://discuss.python.org/u/brandtbucher)\ **Post date:** [May 10, 2024, 11:10pm UTC](https://discuss.python.org/t/pep-744-jit-compilation/50756/49 "2024-05-10T23:10:22Z")
Hm, odd. Do you mind [opening an issue](https://github.com/python/cpython/issues/new?assignees=&labels=type-bug&projects=&template=bug.yml), and tagging me? I’m also curious if there is some sort of invalid syntax in the generated `jit_stencils.h` file around the definition of `emit__MATCH_MAPPING`. I’m also noticing now that the command-line to generate the JIT (and warning banner) are printed twice. That should only be running once per build, so I wonder if it’s a copy-paste error in your post, or if several builds are happening at once for some reason. If so, they could be stepping on each other and maybe truncating the generated file. ---
**Author:** ![hroncok](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hroncok/32/18696_2.png) [@hroncok](https://discuss.python.org/u/hroncok)\ **Post date:** [May 11, 2024, 8:21am UTC](https://discuss.python.org/t/pep-744-jit-compilation/50756/50 "2024-05-11T08:21:53Z")
I can attach a full log for inspection when I open the issue. ---
**Author:** ![hroncok](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hroncok/32/18696_2.png) [@hroncok](https://discuss.python.org/u/hroncok)\ **Post date:** [May 11, 2024, 9:21am UTC](https://discuss.python.org/t/pep-744-jit-compilation/50756/51 "2024-05-11T09:21:14Z")
> > > \# Bug report > > \### Bug description: > > As discussed in https://discuss.python.org/t…/pep-744-jit-compilation/50756/42 and further with @brandtbucher, I've tried to change the Fedora's Python 3.13 package to utilize \`--enable-experimental-jit=yes-off\`. > > As a starting point, I took the 3.13.0b1-1 package from: > > https://src.fedoraproject.org/rpms/python3.13/blob/1c24374362/f/python3.13.spec > > And I changed: > > \`\`\`diff > diff --git a/python3.13.spec b/python3.13.spec > index 4bfe050..68b357d 100644 > \--- a/python3.13.spec > +++ b/python3.13.spec > @@ -304,6 +304,9 @@ BuildRequires: tcl-devel > BuildRequires: tk-devel > BuildRequires: tzdata > > +BuildRequires: clang \>= 18 > +BuildRequires: llvm \>= 18 > + > %if %{with valgrind} > BuildRequires: valgrind-devel > %endif > @@ -920,12 +923,12 @@ BuildPython() { > # option produces too many warnings when compiling at the O0 optimization level. > # See also: https://bugzilla.redhat.com/show\_bug.cgi?id=1818857 > BuildPython debug \\ > \- "--without-ensurepip --with-pydebug" \\ > + "--without-ensurepip --with-pydebug --enable-experimental-jit=yes-off" \\ > "%{optflags\_debug}" > %endif # with debug\_build > > BuildPython optimized \\ > \- "--without-ensurepip %{optimizations\_flag}" \\ > + "--without-ensurepip --enable-experimental-jit=yes-off %{optimizations\_flag}" \\ > "%{optflags\_optimized}" > > %if %{with freethreading\_build} && %{with debug\_build} > \`\`\` > > That means I added \`--enable-experimental-jit=yes-off\` to the debug and optimized non-free-threaded builds and some extra build dependencies. > > Running the build in Fedora Rawhide (41) chroot resulted in this error during the debug build (which happens first): > > \`\`\` > python3.13 /builddir/build/BUILD/Python-3.13.0b1/Tools/jit/build.py x86\_64-redhat-linux-gnu --debug > ============================================================== > JIT support for x86\_64-redhat-linux-gnu is still experimental! > Please report any issues you encounter. > ============================================================== > python3.13 /builddir/build/BUILD/Python-3.13.0b1/Tools/jit/build.py x86\_64-redhat-linux-gnu --debug > ============================================================== > JIT support for x86\_64-redhat-linux-gnu is still experimental! > Please report any issues you encounter. > ============================================================== > gcc -c -fno-strict-overflow -Wsign-compare -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -DDYNAMIC\_ANNOTATIONS\_ENABLED=1 -fcf-protection -fexceptions -fcf-protection -fexceptions -fcf-protection -fexceptions -O0 -Wno-cpp -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U\_FORTIFY\_SOURCE,-D\_FORTIFY\_SOURCE=3 -Wp,-D\_GLIBCXX\_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -D\_GNU\_SOURCE -fPIC -fwrapv -D\_Py\_TIER2=3 -D\_Py\_JIT -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -g -std=c11 -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes -Werror=implicit-function-declaration -fvisibility=hidden -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U\_FORTIFY\_SOURCE,-D\_FORTIFY\_SOURCE=3 -Wp,-D\_GLIBCXX\_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -D\_GNU\_SOURCE -fPIC -fwrapv -O0 -Wno-cpp -I/builddir/build/BUILD/Python-3.13.0b1/Include/internal -I/builddir/build/BUILD/Python-3.13.0b1/Include/internal/mimalloc -IObjects -IInclude -IPython -I. -I/builddir/build/BUILD/Python-3.13.0b1/Include -fPIC -DPy\_BUILD\_CORE -o Python/jit.o /builddir/build/BUILD/Python-3.13.0b1/Python/jit.c > /builddir/build/BUILD/Python-3.13.0b1/Python/jit.c: In function ‘emit\_\_MATCH\_MAPPING’: > /builddir/build/BUILD/Python-3.13.0b1/Python/jit.c:395:1: error: expected expression before ‘int’ > 395 | int > | ^~~ > /builddir/build/BUILD/Python-3.13.0b1/Python/jit.c:479:1: error: expected declaration or statement at end of input > 479 | } > | ^ > In file included from /builddir/build/BUILD/Python-3.13.0b1/Python/jit.c:392: > ./jit\_stencils.h:30254:25: warning: unused variable ‘data\_body’ \[-Wunused-variable\] > 30254 | const unsigned char data\_body\[24\] = { > | ^ ~~~~~~~~ > ./jit\_stencils.h:30241:25: warning: unused variable ‘code\_body’ \[-Wunused-variable\] > 30241 | const unsigned char code\_body\[53\] = { > | ^ ~~~~~~~~ > /builddir/build/BUILD/Python-3.13.0b1/Python/jit.c: At top level: > /builddir/build/BUILD/Python-3.13.0b1/Python/jit.c:87:1: warning: ‘mark\_executable’ defined but not used \[-Wunused-function\] > 87 | mark\_executable(unsigned char \*memory, size\_t size) > | ^ ~~~~~~~~~~~~~~ > /builddir/build/BUILD/Python-3.13.0b1/Python/jit.c:70:1: warning: ‘jit\_free’ defined but not used \[-Wunused-function\] > 70 | jit\_free(unsigned char \*memory, size\_t size) > | ^ ~~~~~~~ > /builddir/build/BUILD/Python-3.13.0b1/Python/jit.c:49:1: warning: ‘jit\_alloc’ defined but not used \[-Wunused-function\] > 49 | jit\_alloc(size\_t size) > | ^ ~~~~~~~~ > make: \*\*\* \[Makefile:3018: Python/jit.o\] Error 1 > make: \*\*\* Waiting for unfinished jobs.... > \`\`\` > > Full logs: > > \- \[installed\_pkgs.log\](https://github.com/python/cpython/files/15282290/installed\_pkgs.log.txt) > \- \[build.log\](https://github.com/python/cpython/files/15282292/build.log.txt) > > > @brandtbucher suggested that "perhaps several builds are happening at once for some reason. If so, they could be stepping on each other and maybe truncating the generated file." > > Anyway, here is the generated \[jit\_stencils.h\](https://github.com/python/cpython/files/15282301/jit\_stencils.h.txt) file as it was present after the failure. > > > \### CPython versions tested on: > > 3.13 > > \### Operating systems tested on: > > Linux ---
**Author:** ![hroncok](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hroncok/32/18696_2.png) [@hroncok](https://discuss.python.org/u/hroncok)\ **Post date:** [May 20, 2024, 9:16am UTC](https://discuss.python.org/t/pep-744-jit-compilation/50756/52 "2024-05-20T09:16:17Z")
Hello again. Possibly a silly question: What is the best way to verify the JIT is there? Calling a function several times and looking at the bytecode? Or is there some `sys` etc. attribute I can observe? ---
**Author:** ![brandtbucher](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brandtbucher/32/22862_2.png) [@brandtbucher](https://discuss.python.org/u/brandtbucher)\ **Post date:** [May 20, 2024, 6:14pm UTC](https://discuss.python.org/t/pep-744-jit-compilation/50756/53 "2024-05-20T18:14:49Z")
Great question. Honestly, the JIT may be a bit _too_ transparent right now, so there aren’t really any great APIs for this yet. If you want to know if a `configure`-based build enabled the JIT, you can use `"_Py_JIT" in sysconfig.get_config_var("PY_CORE_CFLAGS")`. If you want to know if a specific _function_ contains jitted code, this is currently what we do in internal tests: ```py import _opcode import types def is_jitted(f: types.FunctionType) -> bool: for i in range(0, len(f. __code__.co_code), 2): try: _opcode.get_executor(f. __code__ , i) except RuntimeError: # This isn't a JIT build: return False except ValueError: # No executor found: continue return True return False ``` Here’s an example: ```pycon >>> def fibonacci(n): ... a, b = 0, 1 ... for _ in range(n): ... a, b = b, a + b ... return a ... >>> is_jitted(fibonacci) False >>> fibonacci(100) 354224848179261915075 >>> is_jitted(fibonacci) True ``` This should help if you’re just curious, but if you’d like more robust/efficient APIs in `sys` or `dis`, then please open an issue letting us know what sort of functionality would be most useful to you! ---
**Author:** ![hroncok](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hroncok/32/18696_2.png) [@hroncok](https://discuss.python.org/u/hroncok)\ **Post date:** [May 21, 2024, 7:22am UTC](https://discuss.python.org/t/pep-744-jit-compilation/50756/54 "2024-05-21T07:22:08Z")
Thanks. I just needed to verify if my changes to the Fedora package actually work as intended (JIT disabled by default, enabled with the environment variable). I can use the example provided for a manual test. A higher-level function/check might be easier for a smoke CI test, but it’s not required for Fedora. ---
**Author:** ![savannahostrowski](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/savannahostrowski/32/25496_2.png) [@savannahostrowski](https://discuss.python.org/u/savannahostrowski)\ **Post date:** [June 18, 2024, 1:36am UTC](https://discuss.python.org/t/pep-744-jit-compilation/50756/56 "2024-06-18T01:36:24Z")
In light of the discussion, we’re going to work on updating/revising the PEP. While I start to compile the themes raised here, I also wanted to check in and see if there were any additional or new points that folks would like to see clarified that were not already mentioned. ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [July 10, 2024, 9:43pm UTC](https://discuss.python.org/t/pep-744-jit-compilation/50756/57 "2024-07-10T21:43:39Z")
Split this topic on July 10, 2024, 9:43pm UTC 24 posts were split to a new topic: [JIT performance possibilities](https://discuss.python.org/t/jit-performance-possibilities/57859) ---
**Author:** ![system](https://us1.discourse-cdn.com/flex002/uploads/python1/original/1X/3aff56846ebe57781a163dfc748fd1417119d8ab.png) [@system](https://discuss.python.org/u/system)\ **Post date:** [July 10, 2024, 12:43pm UTC](https://discuss.python.org/t/pep-744-jit-compilation/50756/81 "2024-07-10T12:43:20Z")
Closed on July 10, 2024, 12:43pm UTC This topic is temporarily closed for at least 4 hours due to a large number of community flags. ---
**Author:** ![system](https://us1.discourse-cdn.com/flex002/uploads/python1/original/1X/3aff56846ebe57781a163dfc748fd1417119d8ab.png) [@system](https://discuss.python.org/u/system)\ **Post date:** [July 11, 2024, 12:44am UTC](https://discuss.python.org/t/pep-744-jit-compilation/50756/82 "2024-07-11T00:44:40Z")
Opened on July 11, 2024, 12:44am UTC This topic was automatically opened after 12 hours. ---
**Author:** ![hroncok](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hroncok/32/18696_2.png) [@hroncok](https://discuss.python.org/u/hroncok)\ **Post date:** [March 28, 2025, 11:42am UTC](https://discuss.python.org/t/pep-744-jit-compilation/50756/83 "2025-03-28T11:42:17Z")
> [@brandtbucher](#): > > If you want to know if a specific _function_ contains jitted code, this is currently what we do in internal tests: Is it possible that this no longer works on Python 3.14? ---
**Author:** ![brandtbucher](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brandtbucher/32/22862_2.png) [@brandtbucher](https://discuss.python.org/u/brandtbucher)\ **Post date:** [April 8, 2025, 9:46pm UTC](https://discuss.python.org/t/pep-744-jit-compilation/50756/84 "2025-04-08T21:46:44Z")
The mechanism still works for detecting whether JIT code exists, yeah. However, in 3.14 we increased the JIT warmup threshold from 16 loops to 4096, so code will need to run a bit longer to be compiled: ```py >>> def fibonacci(n): ... a, b = 0, 1 ... for _ in range(n): ... a, b = b, a + b ... return a ... >>> is_jitted(fibonacci) False >>> fibonacci(4096) 4612001732280431247456445708563614127173224997617390534215059226137357133453956236072775985077061637311848907129417864574275423997101439882308358166652317363373656716074141072814493065517475413688262677419077617088948496309673353922704120725679705669386361748442871720790233981292904246541321855474289727005675146240418903692583131115962989146454578739972233255840007113102596686397958930124518885822059783685448190039658062872691964066428723178769322339485834664335313247796472730324095846596733944704930052412653763777113749102514483039561246866695780115646150369678333299122486379683222039167477498691611996122878629556831081616202064636498715093853352203252703786287926199052408354498825123496861419106453928530148716831934981264321286848387438601077819789292236505514653845305057927646386419899455438488952785050077521931600327064840520442470066917947 >>> is_jitted(fibonacci) True ``` In general, this value shouldn’t be relied on. But realistically, 16 (the 3.13 behavior) is about the most aggressive value we’d ever use, and 4096 (the 3.14 behavior) is about the least aggressive value we’d ever use. Likely we’ll settle on something between them once the JIT is able to handle more edge-cases in ~3.15. ---
**Author:** ![mixen56](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mixen56/32/31090_2.png) [@mixen56](https://discuss.python.org/u/mixen56)\ **Post date:** [September 20, 2025, 5:58pm UTC](https://discuss.python.org/t/pep-744-jit-compilation/50756/85 "2025-09-20T17:58:16Z")
@brandtbucher Are you planning increase jit performance via inner functions specialization and condition removing? For example: - `_Py_Dealloc` (`Py_DECREF`) maybe transformed from dynamic function calling to calling specailized object function; - `cfunction_vectorcall_NOARGS` → call required function inline. Function `_PyObject_MakeTpCall` have a lot of conditions which maybe cut by jit; - `PyFloat_FromDouble` may have two possible uops: - ```python PyObject * PyFloat_FromDouble(double fval) { PyFloatObject *op = _Py_FREELIST_POP(PyFloatObject, floats); if (op == NULL) { op = PyObject_Malloc(sizeof(PyFloatObject)); if (!op) { return PyErr_NoMemory(); } _PyObject_Init((PyObject*)op, &PyFloat_Type); } op->ob_fval = fval; return (PyObject *) op; } ``` - ```python PyObject * PyFloat_FromDouble(double fval) { PyFloatObject *op = _Py_FREELIST_POP(PyFloatObject, floats); op->ob_fval = fval; return (PyObject *) op; } ``` - `long_add` (`_BINARY_OP_ADD_INT`) - convert to uops `LONG_ADD_BOTH_COMPACT`, `LONG_ADD_X_SUB`, `LONG_ADD_X_ADD`; There are a lot of examples in source code. I found [JIT Planning for 3.15 and 3.16 · Issue #139038 · python/cpython · GitHub](https://github.com/python/cpython/issues/139038), but no specifics about specialization there. And the second question, are you planning tier3 jit with more aggressive optimizations and codegen at fly? Like ion in spidermonkey. Maybe this tier3 compiler will be llvm-based? ---
**Author:** ![kj0](https://avatars.discourse-cdn.com/v4/letter/k/db5fbb/32.png) [@kj0](https://discuss.python.org/u/kj0)\ **Post date:** [September 21, 2025, 9:44am UTC](https://discuss.python.org/t/pep-744-jit-compilation/50756/86 "2025-09-21T09:44:52Z")
@mixen56 We already do some of what you said, and have plans for some of them. > `_Py_Dealloc` (`Py_DECREF`) maybe transformed from dynamic function calling to calling specailized object function; This is already done in limited form. See [Eliminate redundant refcounting in the JIT · Issue #134584 · python/cpython · GitHub](https://github.com/python/cpython/issues/134584). It’s currently blocked on reigster allocation. > cfunction\_vectorcall\_NOARGS We haven’t done that yet, but that seems doable. > `PyFloat_FromDouble` may have two possible uops Or even better, just unbox them and avoid the freelist/allocation altogether. I’m not sure what you mean by the long\_add one. > And the second question, are you planning tier3 jit with more aggressive optimizations and codegen at fly? Like ion in spidermonkey. Maybe this tier3 compiler will be llvm-based? This is still up in the air. [Previous page](https://discuss.python.org/t/pep-744-jit-compilation/50756.md?page=2)