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

451–460 of 553 posts

Re: Python 3.13 Gets a JIT

#451

Post by ElectronCharge »

dehrmann wrote: post #307
eigenvalue wrote: post #230

Earlier quoted context omitted.

It’s because the total dollars of capitalized software deployed in the world using Python has absolutely exploded from AI stuff. Just like how the total dollars of business conducted on the web was a big driver of JS performance earlier.

But all the AI heavy lifting is done in native code.

That is the exact value proposition of Mojo.

Pythonesque (sane) syntax, great AOTC language features, great performance, memory safety, excellent Python interoperability. What’s not to like?

If you think of something, contact Modular…

Re: Python 3.13 Gets a JIT

#452

Post by kragen »

lispm wrote: post #421
kragen wrote: post #416

Earlier quoted context omitted.

are there any cl implementations that use jit? there are a lot of cl implementations so i assumed there must be one

ABCL runs on the JVM. It generates JVM byte code, which then can be JIT compiled by the JVM. CLISP has a byte code machine, for which a JIT can be used. There might be others.

thank you! i didn't know clisp had a jit compiler, and i certainly should have thought of abcl, and also you mentioned them in your other comment in https://news.ycombinator.com/item?id=38933091

how much of a performance boost does abcl get from the hotspot jit compared to, say, interpreted clisp

Re: Python 3.13 Gets a JIT

#453

Post by hughdbrown »

Qem wrote: post #361
technocratius wrote: post #342

Earlier quoted context omitted.

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.

.9 * x = 0.5

x ln 0.9 = ln 0.5

x = ln 0.5 / ln 0.9

x = 6.5788

So decreasing runtime by 10% 6.5788 times results in the code running in half the original time.

Re: Python 3.13 Gets a JIT

#454

Post by [deleted] »

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!

[deleted]

Re: Python 3.13 Gets a JIT

#455

Post by seabrookmx »

crabbone wrote: post #245
DeathArrow wrote: post #239

If JIT is a good thing for Python, why don't just compile to Java or .NET bytecode and use their already optimized infrastructure?

Given how many Microsoft employees today steer the Python decision making process, I'm sure in not so distant future, we might see a new CLR-based Python implementation. Maybe Microsoft don't know yet how to sell this thing, or maybe they are just boiling the frog. Time will tell. But I'm pretty sure your question will be repeated as soon as people will get used to the idea of Python on JIT.

It exists, was created by microsoft employees, and is referenced in the article: https://www.trypyjion.com/

Re: Python 3.13 Gets a JIT

#456

Post by seabrookmx »

DeathArrow wrote: post #239

If JIT is a good thing for Python, why don't just compile to Java or .NET bytecode and use their already optimized infrastructure?

This is referenced in the article:

> The big downside with a “full” JIT is that the process of compiling once into IL and then again into machine code is slow. Not only is it slow, but it is memory intensive.

Re: Python 3.13 Gets a JIT

#457

Post by ummonk »

moomin wrote: post #442
ummonk wrote: post #429

Earlier quoted context omitted.

Not if “faster” refers to computation rate rather than runtime, in which case it becomes 100/81 i.e. 23% faster.

Yes, but I’ve literally never heard anyone say that.

You've never seen anyone say "x% faster" where x is a number larger than 100? I find that hard to believe.

Re: Python 3.13 Gets a JIT

#458

Post by paulddraper »

hartator wrote: post #369
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...

That link is pretty clear that it's a non-realistic benchmark that results in a Python 3 slowdown. (And there are many benchmarks that are faster in Python 3.)

Re: Python 3.13 Gets a JIT

#459

Post by paulddraper »

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!

It's not the size of the improvement that's regrettable, it's the absolute performance after the improvement.

No one is disappointed by V8's 6-8% improvement with Maglev. [1]

Because V8 is (for a scripting language) insanely fast.

And Python is not, unfortunately.

[1] https://v8.dev/blog/holiday-season-2023

Re: Python 3.13 Gets a JIT

#460

Post by paulddraper »

bb88 wrote: post #378
nextaccountic wrote: post #376

Earlier quoted context omitted.

This is happening mostly because Guido left, right? The take that CPython should be a reference implementation and thus slow always aggravated me (because, see, no other implementation can compete because every package depends on CPython kirks, in such a way that we're now removing the GIL of CPython rather than migrating to Pypy for example)

Guido is still involved, but he's no longer the BDFL.

> no longer the BDFL

the irony :/

Post reply on HN