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

361–370 of 553 posts

Re: Python 3.13 Gets a JIT

#361

Post by Qem »

technocratius wrote: post #342
EmilStenstrom wrote: post #332

It's interesting to see these 2-9% improvements from version to version. They are always talked about with disappointment, as if they are too small, but they also keep coming, with each version being faster than the previous one. I prefer a steady 10% per version over breaking things because you are hoping for bigger numbers. Those percentages add up!

Well I think they even multiply, making it even better news!

log(2)÷log(1.1) ~= 7.27, so in principle sustained 10% improvements could double performance every 7 releases. But at some point we're bound to face diminishing returns.

Re: Python 3.13 Gets a JIT

#362

Post by oskarkk »

hangonhn wrote: post #296
Iridescent_ wrote: post #60

Wasn't CPython supposed to remain very simple in its codebase, with the heavy optimization left for other implementations to tackle? I seem to remember hearing as much a few years back.

Does Python even have a language specification? I've been told that CPython IS the specification. I don't know if this is still true. In the Java world there is a specification and a set of tests to test for conformation so it's easier to have alternative implementations of the JVM. If what I said is correct, then I can see how the optimized alternative implementation idea is less likely to happen.

Well, for Python the language reference in the docs[0] is the specification, and many things there are described as CPython implementation details. Like: "CPython implementation detail: For CPython, id(x) is the memory address where x is stored." And as another example, dicts remembering insertion order was CPython's implementation detail in 3.6, but from 3.7 it's part of the language.

[0] https://docs.python.org/3/reference/index.html

Re: Python 3.13 Gets a JIT

#363

Post by recursivecaveat »

hangonhn wrote: post #296
Iridescent_ wrote: post #60

Wasn't CPython supposed to remain very simple in its codebase, with the heavy optimization left for other implementations to tackle? I seem to remember hearing as much a few years back.

Does Python even have a language specification? I've been told that CPython IS the specification. I don't know if this is still true. In the Java world there is a specification and a set of tests to test for conformation so it's easier to have alternative implementations of the JVM. If what I said is correct, then I can see how the optimized alternative implementation idea is less likely to happen.

There is a pretty detailed reference that distinguishes between cpython implementation details and language features at least. There was a jvm python implementation even. The problem is more that a lot of the libraries that everyone wants to use are very dependent on cpython's ffi which bleeds a lot of internals.

Re: Python 3.13 Gets a JIT

#364

Post by dagw »

Pxtl wrote: post #225
dagw wrote: post #26

Earlier quoted context omitted.

anyone (company) stepping up and make the runtime as fast as modern JavaScript runtimes. There are a lot of faster python runtimes out there. Both Google and Instagram/Meta have done a lot of work on this, mostly to solve internal problems they've been having with python performance. Microsoft has also done work on parallel python. There's PyPy and Pythran and no doubt several others. However none of these attempts h…

Node.js and Python 3 came out at around the same time. Python had their chance to tell all the "mission critical legacy code" that it was time to make hard changes.

As much as I would have loved to see some more 'extreme' improvements to python, given how the python community reacted to the relatively minor changes that python 3 brought, anything more extreme would very likely have caused a Perl 6 style situation and quite possibly have killed the language.

Re: Python 3.13 Gets a JIT

#366

Post by ynik »

Iridescent_ wrote: post #60

Wasn't CPython supposed to remain very simple in its codebase, with the heavy optimization left for other implementations to tackle? I seem to remember hearing as much a few years back.

The problem is that: * CPython is slow, making extension modules written in C(++) very attractive * The CPython extension API exposes many implementation details * Making use of those implementation details helps those extension modules be even faster

This resulted in a situation where the ecosystem is locked-in to those implementation details: CPython can't change many aspects of its own implementation without breaking the ecosystem; and other implementations are forced to introduce complex and slow emulation layers if they want to be compatible with existing CPython extension modules.

The end result is that alternative implementations are not viable in practice, as most existing libraries don't work without their CPython extension modules -- users of alternative implementations are essentially stuck in their own tiny ecosystem and cannot make use of the large existing (C)Python ecosystem.

CPython at least is in a position where they can push a breaking change to the extension API and most libraries will be forced to adapt. But there's very little incentive for library authors to add separate code paths for other Python implementations, so I don't think other implementations can become viable until CPython cleans up their API.

Re: Python 3.13 Gets a JIT

#367

Post by janalsncm »

HDThoreaun wrote: post #341
dron57 wrote: post #309

Earlier quoted context omitted.

AI heavy lifting isn't just model training. There's about a million data pipelines and processes before the training data gets loaded into a PyTorch tensor.

also done in native code

From personal experience, no. I ended up writing rust bindings to call from python that turned minutes of loading into seconds.

Re: Python 3.13 Gets a JIT

#368

Post by VagabundoP »

Joker_vD wrote: post #183
guenthert wrote: post #171

Earlier quoted context omitted.

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.

But type declarations in Python are not required to be correct, are they? You are allowed to write def twice(x: int) -> int: return x + x print(twice("nope")) and it should print "nopenope". Right?

The Python language server in Visual Studio Code will catch this if type checking is turned on, but by default, in CPython, that code will just work.

Re: Python 3.13 Gets a JIT

#369

Post by hartator »

EmilStenstrom wrote: post #332

It's interesting to see these 2-9% improvements from version to version. They are always talked about with disappointment, as if they are too small, but they also keep coming, with each version being faster than the previous one. I prefer a steady 10% per version over breaking things because you are hoping for bigger numbers. Those percentages add up!

Because it took 10 years to have Python 3 being as fast as Python 2 while being more strict. 2-9% means it will be another 10 years to have Python 3 being significantly faster.

Ref: https://mail.python.org/pipermail/python-dev/2016-November/1...

Re: Python 3.13 Gets a JIT

#370

Post by janalsncm »

Sohcahtoa82 wrote: post #335
poncho_romero wrote: post #325

Earlier quoted context omitted.

What languages do you think it could realistically eat (that it hasn’t already)?

I'd love to see it eat JavaScript and Java for back-end code. But I doubt that's going to ever happen.

I like python but I would never choose it for anything more than trivial on the backend. I want to know what types are being passed around from one middleware function to the next. Yes python has annotations but that’s not enough.
Post reply on HN