You can read all about the progress we’ve made in the 3.15 What’s New. I’m pretty proud of the progress we’ve made as a team on the JIT over the last cycle.
I’d be interested to learn more about what type of workload you’re running. The JIT is still experimental, and gains vary quite a bit depending on workload.
@savannahostrowski can you expand on one bit at the beginning of that page?
Does that statement imply the JIT and the tail calling interpreter are incompatible? Said another way, does that statement mean “JIT w/ tail call vs just tail call” or “JIT w/o tail call vs tail call?”
I configured and built with both the JIT and tail call interpreter enabled. All tests pass, so it appears the combination is supported in some fashion. I saw no obvious warnings in the configure output.
This is really cool. Can I suggest that the y-axis label be changed to something like “speed difference”[1]? The labels at the axis endpoints, plus the 5% goal line, make clear that negative numbers mean better. But the y-axis says “performance difference”. Performance is a positive thing; more/better performance means lower time.
or the axis flipped so that the goal is +5% ↩︎
You could open an issue or PR on the GitHub: GitHub - savannahostrowski/doesjitgobrrr: A performance dashboard tracking CPython's JIT vs. Interpreter benchmarks. · GitHub
The TC interpreter and JIT are compatible. It just means it’s JIT w/ TC vs just TC. The configuration is as such due to the default compilers used on different platforms. macOS uses recent clang, which we now distribute with TC, while Linux typically uses GCC, which does not yet support all the requires for TC (though GCC 16 will).
I’m a native English speaker and to me “promise” means it’s something to be delivered which is almost guaranteed, although technically the promise may not be legally binding. A legally binding promise is written up to be a “contract”. We have another English word called “goal” which is a deliverable not written in stone.
Sorry if I sidetracked things, but different English speakers may have different ideas of what “promise” means. I wish we had more standardization in English.
I look forward to you helping improve the speed of Python. That said, my biggest slowdown in my programs are database calls (getting information from a database) because I do that 1000s of times in each program. And Python cannot fix that. Azure is slow, keep your expectations low. Each SELECT statement takes 3-4 seconds, and I’m only getting records from one table at a time, there are no JOINs or complex criteria.
The JIT is specifically designed to help with loops. So once you have that data the loops over it should be faster with the JIT than without it. Nothing anyone in the CPython team does will improve network transmission times or DB performance. This is to improve what we do with the data that comes back from those things.
Thanks. It would be nice if the news item was updated to be more explicit.
The problem with the benchmark test in my opinion is that it doesn’t paint a realistic picture of performance of real world code. In my experience, pypy3 is about 3 to 4 times faster than CPython.
One area CPython outperforms Pypy3 is multiprocessing Pools. Maybe it’s just the way I handle them, but I find CPython is much faster with Pools.
What I’ve also noticed is Pypy3 tends to use a lot more memory than CPython, especially with long run processes.
I parse a lot of binary streams, and Python3.14 tends to perform better as my data gets larger.I wanted to ask the CPython guys, is that by design?