Live data from Hacker News

Python 3.13 Gets a JIT

tonybaloney.github.io

301–310 of 553 posts

Re: Python 3.13 Gets a JIT

#301

Earlier quoted context omitted.

Python's SHA256 is written in C. And I'd quess Web Crypto API for JS is in the same ballbark. SHA256 in pure Python would be unusably slow. In Javascript it would be at least usably slow. Javascript is fast. Browsers are fast.

Have you tried to generate a SHA256 checksum for a file in the browser, no matter what crypto lib or api is available to you ? Have you tried to generate it using Python standard lib ? I did, and doing it in the browser was so bad that it was unusable. I suspect that it's not the crypto that's slow but the file reading. But anyway... > SHA256 in pure Python would be unusably slow None would do that because: > Python'…

> Have you tried to generate a SHA256 checksum for a file in the browser

Have you tried to do this in Python?

A Node comparison would be more appropriate.

Re: Python 3.13 Gets a JIT

#304

Earlier quoted context omitted.

To each his own, but the things you list are largely subjective/inaccurate, and there are many, many, many developers who use Python because they enjoy it and like it a lot.

Python is a very widely used language, and like any popular thing, yes many many many like it , and many many many dislike it .. it is that big, python can be disliked by a million developer and still be a lot more liked than disliked but i also think that its true that python is not and have not been for a while considered as a modern or technically advanced language the hype currently is for typed or gradually type…

> devs passionate about programming languages, python is a relic they hope vanish

Statements like this are obviously untrue for large numbers of people, so I'm not sure of the point you're trying to make.

But certainly it's true that there are both objective and subjective reasons for using a particular tool, so I hope you are in a position to use the tools that you prefer the most. Have a great day!

Re: Python 3.13 Gets a JIT

#305
post #263

> At the moment, the JIT is only used if the function contains the JUMP_BACKWARD opcode which is used in the while statement but that will change in the future. Isn't this the main reason why it's only a 2-9% improvement? Not much Python code uses the while statement in my experience.

[deleted]

Re: Python 3.13 Gets a JIT

#306
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.

I really wouldn't mind Python being faster than it is and I really didn't mind at all getting an practically free ~30% performance increase just by updating to 3.11. There's tons of applications which just passively benefit from these optimizations. Sure, you might argue "but you shouldn't have written that parser or that UI handling a couple thousand items in Python" but lots of people do and did just that.

I wouldn't mind either.

Do you agree with me that Python is already fast enough for most cases, even without a JIT?

If not, how would a 30% boost improve things enough to change the balance?

Re: Python 3.13 Gets a JIT

#307
post #200

The last two-ish years have been insane for Python performance. Something clicked with the core team and they obviously made this a serious goal of theirs and the last few years have been incredible to see.

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.

Re: Python 3.13 Gets a JIT

#308
post #294

Earlier quoted context omitted.

Does it matter? Trains are never going to beat jets in pure speed. But in certain scenarios, trains make a lot more sense to use than jets, and in those scenarios, it is usually preferable having a 150 mph train to a 75 mph train. Looking at the world of railways, high-speed rail has attracted a lot more paying customers than legacy railways, even though it doesn't even try to achieve flight-like speeds. Same with pr…

What is the programming analogy here? Two decades ago, you could (as e.g. Paul Graham did at the time) argue that dynamically typed languages can get your ideas to market faster so you become viable and figure out optimization later. It's been a long time since that argument held. Almost every dynamic programming language still under active development is adding some form of gradual typing because the maintainability…

I cut my teeth on C/C++, and I still develop the same stuff faster in Python, with which I have less overall experience by almost 18 years. Python is also much easier to learn than, say, Rust, or the current standard of C++ which is a veritable and intimidating behemoth.

In many domains, it doesn't really matter if the resulting program runs in 0.01 seconds or 0.1 seconds, because the dominant time cost will be in user input, DB connection etc. anyway. But it matters if you can crank out your basic model in a week vs. two.

Re: Python 3.13 Gets a JIT

#309

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.

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.

Re: Python 3.13 Gets a JIT

#310

Earlier quoted context omitted.

A Python web service my team maintains, running at a higher request rate and with lower CPU and RAM requirements than most of the Java services I see around us, would like a word with you.

How many requests per second are we talking, ballpark, and what's the workload?

~5k requests/second for the Python service, we tend to go for small instances for redundancy so that's across a few dozen nodes. The workload comparison is unfair to the Java service, if I'm honest :). But we're running Python on single vCPU containers with 2G RAM, and the Java service instances are a lot larger than that.

Flask, gunicorn, low single digit millisecond latency. Definitely optimised for latency over throughput, but not so much that we've replatformed it onto something that's actually designed for low latency :P. Callers all cache heavily with a fairly high hit ratio for interactive callers and a relatively low hit ratio for batch callers.

Post reply on HN