Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 3.13 Gets a JIT

tonybaloney.github.io

Post reply on HN
Print view View original

171–180 of 553 posts

Re: Python 3.13 Gets a JIT

#171

Post by guenthert »

a-french-anon wrote: post #146
guenthert wrote: post #108

Earlier quoted context omitted.

Isn't it the case that Python allows for type specifier (type hints) since 3.5, albeit the CPython interpreter ignores them? The JIT might take advantage of them, which ought to improve performance significantly for some code. That what makes Python flexible is what makes it slow. Restricting the flexibility were possible offers opportunities to improve performance (and allows for tools and humans to spot errors more…

Isn't CL a good counter-example to that "dynamism inherently stunts performances" mantra?

To the contrary. In CL some flexibility was given up (compared to other LISP dialects) in favor of enabling optimizing compilers, e.g. the standard symbols cannot be reassigned (also preserving the sanity of human readers). CL also offers what some now call 'gradual typing', i.e. optional type declarations. And remaining flexibility, e.g. around the OO support, limits how well the compiler can optimize the code.

Re: Python 3.13 Gets a JIT

#172

Post by londons_explore »

blagie wrote: post #65
ageitgey wrote: post #3

For the lazy who just want to know if this makes Python faster yet, this is foundational work to enable later improvements: > The initial benchmarks show something of a 2-9% performance improvement. > I think that whilst the first version of this JIT isn’t going to seriously dent any benchmarks (yet), it opens the door to some huge optimizations and not just ones that benefit the toy benchmark programs in the standar…

From the write-up, I honestly don't understand how this paves the way. I don't see an architectural path from a cut-and-paste JIT to something optimizing. That's the whole point of a cut-and-paste JIT.

> . I don't see an architectural path from a cut-and-paste JIT to something optimizing.

One approach used in V8 is to have a dumb-but-very-fast JIT (ie. this), and keep counters of how often each block of code runs (perhaps actual counters, perhaps using CPU sampling features), and then any block of code running more than a few thousand times run through a far more complex yet slower optimizing jit.

That has the benefit that the 0.2% of your code which uses 95% of the runtime is the only part that has to undergo the expensive optimization passes.

Re: Python 3.13 Gets a JIT

#173

Post by vanderZwan »

nritchie wrote: post #170

At the end of the day, the number of optimizations that even a JIT can do on Python is limited because all variables are boxed (each time the variable is accessed the type of the variable needs to be checked because it could change) and then function dispatches must be chosen based on the type of the variable. Without some mechanism to strictly type variables, the number of optimizations will always be limited.

Per the spec all JS values are boxed too (aside from values in TypedArrays). The implementations managed to work their way around that too for the most part.

Re: Python 3.13 Gets a JIT

#175

Post by johncolanduoni »

nritchie wrote: post #170

At the end of the day, the number of optimizations that even a JIT can do on Python is limited because all variables are boxed (each time the variable is accessed the type of the variable needs to be checked because it could change) and then function dispatches must be chosen based on the type of the variable. Without some mechanism to strictly type variables, the number of optimizations will always be limited.

Couldn’t you say the same for e.g. JavaScript? The variables aren’t typed there either and prototypes are mutable. I could definitely see things being harder with Python which has a lot of tricky metaprogramming available that other interpreted languages don’t but I don’t think it’s as simple as a lack of explicit types.

Re: Python 3.13 Gets a JIT

#176

Post by IshKebab »

bomewish wrote: post #83
Topfi wrote: post #64

Earlier quoted context omitted.

Honestly, 2-9% already seems like a very signficant improvement, especially since as they mention "remember that CPython is already written in C". Whilst it's great to look at the potential for even greater gains by building upon this work, I feel we shouldn't undersell what's been accomplished.

Also recall that a 50% speed improvement in SQLite was caused by 50-100 different optimisations that each eeked out 0.5-1% speedups. On phone now don’t have the ref but it all adds up.

That's true, and Rust compiler speed has seen similar speedups from lots of 1% improvements.

But even if you can get a 2x improvement from lots of 1% improvements (if you work really really hard), you're never going to get a 10x improvement.

Rust is never going to compile remotely as quickly as Go.

Python is never going to be remotely as fast as Rust, C++, Go, Java, C#, Dart, etc.

Re: Python 3.13 Gets a JIT

#177

Post by btown »

nritchie wrote: post #170

At the end of the day, the number of optimizations that even a JIT can do on Python is limited because all variables are boxed (each time the variable is accessed the type of the variable needs to be checked because it could change) and then function dispatches must be chosen based on the type of the variable. Without some mechanism to strictly type variables, the number of optimizations will always be limited.

Can’t the happy path be branch predicted and speculatively executed, though? AFAIK V8 seems to do this: https://web.dev/articles/speed-v8#the_optimizing_compiler

Re: Python 3.13 Gets a JIT

#178

Post by sirsinsalot »

pjmlp wrote: post #145
eesmith wrote: post #62

Earlier quoted context omitted.

I think Python without a JIT in many cases is already fast enough for most cases. I don't do data science.

Sure, for UNIX scripting, for everything else it is plainfully slow. I know Python since version 1.6, and is my scripting language in UNIX like environments, during my time at CERN, I was one of the CMT build infrastructure build engineer on the ATLAS team. It was never been the language I would reach for when not doing OS scripting, and usually when a GNU/Linux GUI application happens to be slow as mollasses, it has…

My teams deploy Python web APIs and yes, it is slow compared to other languages and runtimes.

But on the whole, machines are cheaper than other engineering approaches to scaling.

For us, and many others, fast enough is fast enough.

Re: Python 3.13 Gets a JIT

#179

Post by IshKebab »

cryptos wrote: post #6

I always wondered how Python can be one of the world's most popular languages without anyone (company) stepping up and make the runtime as fast as modern JavaScript runtimes.

Two reasons:

1. Javascript is a less dynamic language than Python and numbers are all float64 which makes it a lot easier to make fast.

2. If you want to run fast code on the web you only have one option: make Javascript faster. (Ok we have WASM now but that didn't exist at the time of the Javascript Speed wars.) If you want to run fast code on your desktop you have a MUCH easier option: don't use Python.

Re: Python 3.13 Gets a JIT

#180

Post by nertirs »

spacechild1 wrote: post #86
Topfi wrote: post #64

Earlier quoted context omitted.

Honestly, 2-9% already seems like a very signficant improvement, especially since as they mention "remember that CPython is already written in C". Whilst it's great to look at the potential for even greater gains by building upon this work, I feel we shouldn't undersell what's been accomplished.

> "remember that CPython is already written in C" What is this supposed to say? Most scripting language interpreters are written in low level languages (or assembly), but that alone doesn't say anything about the performance of the language itself.

This means, that a lot of python libraries like polars or tensorflow are written not in python.

So python programs, that already spend most of its cpu time running these libraries code, won't see much of an impact.

Post reply on HN