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

461–470 of 553 posts

Re: Python 3.13 Gets a JIT

#461

Post by paulddraper »

mg wrote: post #90

I love Python and use it for everything other than web development. One reason is performance. So if Python has a faster future ahead of it: Hurray! The other reason is that the Python ecosystem moved away from stateless requests like CGI or mod_php use and now is completely set on long running processes. Does this still mean you have to restart your local web application after any change you made to it? I heard that…

> That seems pretty expensive in terms of resource consumption.

As opposed to CGI?

Re: Python 3.13 Gets a JIT

#464

Post by klyrs »

leephillips wrote: post #392
klyrs wrote: post #383

Earlier quoted context omitted.

You're making this about Julia despite my repeated statements to the contrary. Please reread what I've written, you aren't responding to the actual point I've made twice now. A reminder: I'm talking specifically about my outlook on the future of Python, vis a vis my historical experience with how other JIT languages have developed. If you wanted to rebut this, you'd need to argue that Julia has always been awesome an…

> I'm talking specifically about my outlook on the future of Python, vis a vis my historical experience with how other JIT languages have developed. But your assessment of the other language you mentioned is several years out of date and made largely irrelevant by the fast pace of progress. Therefore your conclusions about the probable future of Python, which may be correct, nevertheless do not follow.

I was sharing feelings and opinions, when you refer to my "conclusions" you're speaking to elements of the empty set. I get that you're a big Julia evangelist, but if you hope to reach people, you must learn to listen.

How long did it take Julia to solve its warmup issue? The language is about 12, and I last tried in earnest two years ago. So, a decade, give or take? You speak from the top of a mountain, and you say the view is nice. Sitting at the base of a similar mountain, it's the journey that I dread, because Python's recent long-term journeys have been pretty rough. And I'm just not convinced that the destination is so great.

Re: Python 3.13 Gets a JIT

#465

Post by peterfirefly »

jpfr wrote: post #393
cbmuser wrote: post #280

Earlier quoted context omitted.

»LuaJIT is undoubtedly a "full" JIT compiler.« Yes, and it's practically unmaintained. Pull requests to add support for various architectures have remained largely unanswered, including RISC-V.

The commit history looks pretty active... https://github.com/LuaJIT/LuaJIT/commits/v2.1/

Mike Pall is back in monster mode!

Re: Python 3.13 Gets a JIT

#466

Post by nextaccountic »

remram wrote: post #448
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)

Pypy actually works really well. It could probably get even farther if people knew about it more. Test your packages on Pypy, people.

The only trouble is C packages, which are really really common, right? So you have a performance hit or something (or so I heard)

I guess that now the GIL is going away, pypy will become better at handling packages with native code like numpy

Re: Python 3.13 Gets a JIT

#467

Post by yla92 »

swingingFlyFish wrote: post #299
mg wrote: post #90

I love Python and use it for everything other than web development. One reason is performance. So if Python has a faster future ahead of it: Hurray! The other reason is that the Python ecosystem moved away from stateless requests like CGI or mod_php use and now is completely set on long running processes. Does this still mean you have to restart your local web application after any change you made to it? I heard that…

Python is amazing and shines for Web development. I'd recommend taking a look at https://www.tornadoweb.org/en/stable/index.html . I use this in production on my pet project at https://www.meecal.co/ . Put Nginx in front and you're golden. Definitely take a look, it's come a long way from ten years ago.

Love Tornado and use them for everything backend at 99.co

Re: Python 3.13 Gets a JIT

#468

Post by MBCook »

t43562 wrote: post #343

I wish the money could be spent on PyPy but pypy has its problems - you don't get a big boost on small programs that run often because the warmup time isn't that fabulous. For larger programs like you sometimes it some incredibly complicated incompatibility problem. For me bitbake was one of those - could REALLY benefit from pypy but didn't work properly and I couldn't fix it. If this works more reliably or has a fas…

Isn’t that similar to JS? My understanding was modern JS runtimes had something like this:

interpreted -> basic JIT -> fancy JIT

The interpreter gets you going fast. The basic JIT is extremely fast to compile but not the most performant. If the code can be JITed it quickly will be.

From there the engine can find hotspots or functions that get run a lot and use the fancy JIT on them in the background. That means the slow compile doesn’t block things but when the result can be swapped in performance can take a big jump.

At any point the engine can drop down to the interpreter if an assumption is violated (someone passes a string where they had always used numbers before) or a function is redefined.

It wouldn’t surprise me if something like that appeared as an option in Python over time to get the best of both worlds.

Re: Python 3.13 Gets a JIT

#469

Post by rattray »

paulddraper wrote: post #459
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

What are some good stats/benchmarks on the rough order of magnitude of python vs js perf these days?

Re: Python 3.13 Gets a JIT

#470

Post by squeaky-clean »

ummonk wrote: post #457
moomin wrote: post #442

Earlier quoted context omitted.

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.

Not for a programming language because it's extremely rare for the computation rate to increase, rather than the work being done to compute something decrease.

If you've rewritten something to better use cachelines, removed saturating memory bandwidth, etc then sure you've increased The computation rate. But that's rarely how these language specific optimizations occur.

Post reply on HN