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

41–50 of 553 posts

Re: Python 3.13 Gets a JIT

#41

Post by pjmlp »

kragen wrote: post #36
cqqxo4zV46cp wrote: post #16

Unfortunate to see a couple of comments here drive-by pulling out the “x% faster” stat whilst minimising the context. This is a big deal and it’s effectively a given that this’ll pave the way for further enhancements.

maybe, maybe not. time will tell. ahead-of-time compilation is even better known for improving performance and yet perl's compile-to-c backend turned out to fail to do that

Ahead-of-time compilation is a bad solution for dynamic languages, so that is an expected outcome for Perl.

The base line should be how heavily dynamic languages like my favourite set, Smalltalk, Common Lisp, Dylan, SELF, NewtonScript, ended up gaining from JIT, versus the original interpreters, while being in the genesis of many relevant papers for JIT research.

Re: Python 3.13 Gets a JIT

#42

Post by kragen »

pjmlp wrote: post #41
kragen wrote: post #36

Earlier quoted context omitted.

maybe, maybe not. time will tell. ahead-of-time compilation is even better known for improving performance and yet perl's compile-to-c backend turned out to fail to do that

Ahead-of-time compilation is a bad solution for dynamic languages, so that is an expected outcome for Perl. The base line should be how heavily dynamic languages like my favourite set, Smalltalk, Common Lisp, Dylan, SELF, NewtonScript, ended up gaining from JIT, versus the original interpreters, while being in the genesis of many relevant papers for JIT research.

when i wrote ur-scheme one of the surprising things i learned from it was that ahead-of-time compilation worked amazingly well for scheme. scheme is ruthlessly monomorphic but i was still doing a type check on every primitive argument

i didn't realize they ever jitted newtonscript

Re: Python 3.13 Gets a JIT

#43

Post by cube2222 »

kragen wrote: post #36
cqqxo4zV46cp wrote: post #16

Unfortunate to see a couple of comments here drive-by pulling out the “x% faster” stat whilst minimising the context. This is a big deal and it’s effectively a given that this’ll pave the way for further enhancements.

maybe, maybe not. time will tell. ahead-of-time compilation is even better known for improving performance and yet perl's compile-to-c backend turned out to fail to do that

> ahead-of-time compilation is even better known for improving performance

Not necessarily, not for dynamic languages.

With very dynamic languages you can make only very limited assumptions about e.g. function argument types, which lead you to compiled functions that have to handle any possible case.

A JIT compiler can notice that the given function is almost always (or always) used to operate on a pair of integers, and do a vastly superior specialized compilation, with guards to fallback on the generic one. With extensive inlining, you can also deduplicate a lot of the guards.

Re: Python 3.13 Gets a JIT

#44

Post by ephimetheus »

est31 wrote: post #15
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.

Python is already fast where it matters: often, it is just used to integrate existing C/C++ libraries like numpy or pytorch. It is more an integration language than one where you write your heavy algorithms in. For JS, during the time that it received its JITs, there was no cross platform native code equivalent like wasm yet. JS had to compete with plugins written in C/C++ however. There was also competition between…

I think usually the term “browser wars” refers to the time when Netscape and Microsoft were struggling for dominance, which concluded in 2001.

JavaScript JITs only emerged around 2008 with SpiderMonkey’s TraceMonkey, JavaScriptCore’s SquirrelFish Extreme, and V8’s original JIT.

Re: Python 3.13 Gets a JIT

#45

Post by pjmlp »

jagaerglad wrote: post #11

Can someone explain what a JIT compiler means in the case of an interpreted language?

Basically a JIT (Just In Time), is also known as a dynamic compiler.

It is an approach that traces back to original Lisp and BASIC systems, among others lesser kwown ones.

The compiler is part of the language runtime, and code gets dynamically compiled into native code.

Why is this a good approach?

It allows for experiences that are much harder to implement in languages that tradicionally compile straight to native code like C (note there are C interpreters).

So you can have an interpreter like experience, and code gets compiled to native code before execution on the REPL, either straight away, or after the execution gets beyond a specific threshold.

Additionally, since dynamic languages per definition can change all the time, a JIT can profit from code instrumentation, and generate machine code that takes into account the types actually being used, something that an AOT approach for a dynamic language cannot predit, thus optimizations are hardly an option in most cases.

Re: Python 3.13 Gets a JIT

#46

Post by el_oni »

AndrewDucker wrote: post #23
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.

Always interested in replies to this kind of comment, which basically boil down to "Python is so slow that we have to write any important code in C. And this is somehow a good thing." I mean, it's great that you can write some of your code in C. But wouldn't it be great if you could just write your libraries in Python and have them still be really fast?

it depends what speed is most important to you.

When i was a scientist, speed was getting the code written during my break, and if it took all afternoon to run that's fine because i was in the lab anyway.

Even as i moved more into the software engineer direction, and started profiling code more, most of the bottlenecks come from things like "creating objects on every incovation rather than pooling them", "blocking IO", "using a bad algorithm" or "using the wrong datasctructure for the task". problems that exist in every language, though "bad algorithm" or "using the wrong datasctructure" might matter less in a faster language you're still leaving performance on the table.

> "Python is so slow that we have to write any important code in C. And this is somehow a good thing."

The good thing is that python has a very vibrant ecosystem filled with great libraries, so we don't have to write it in C, because somebody else has. We can just benefit from that when the situation calls for it

Re: Python 3.13 Gets a JIT

#47

Post by JodieBenitez »

AndrewDucker wrote: post #23
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.

Always interested in replies to this kind of comment, which basically boil down to "Python is so slow that we have to write any important code in C. And this is somehow a good thing." I mean, it's great that you can write some of your code in C. But wouldn't it be great if you could just write your libraries in Python and have them still be really fast?

Between writing C code and writing Python code, there is also Cython.

But sure, I'm all for removing build steps and avoiding yet another layer.

Re: Python 3.13 Gets a JIT

#48

Post by dannymi »

AndrewDucker wrote: post #23
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.

Always interested in replies to this kind of comment, which basically boil down to "Python is so slow that we have to write any important code in C. And this is somehow a good thing." I mean, it's great that you can write some of your code in C. But wouldn't it be great if you could just write your libraries in Python and have them still be really fast?

>I mean, it's great that you can write some of your code in C. But wouldn't it be great if you could just write your libraries in Python and have them still be really fast?

That really depends.

To make the issue clear, let's think about a similar situation:

bash is nice because you can plug together inputs and outputs of different sub-executables (like grep, sed and so on) and have a big "functional" pipeline deliver the final result.

Your idea would be "wouldn't it be great if you could just write your libraries in bash and have them still be really fast?". Not if you make bash into C, tanking productivity. And definitely not if that new bash can't run the old grep anymore (which is what usually is implied by the proposal in the case of Python).

Also, I'm fine with not writing my search engines, databases and matrix multiplication algorithm implementations in bash, really. So are most other people, I suspect.

Also, many proposals would weaken Python-the-language so it's not as expressive anymore. But I want it to stay as dynamic as it is. It's nice as a scripting language about 30 levels above bash.

As always, there are tradeoffs. Also with this proposal there will be tradeoffs. Are the tradeoffs worth it or not?

For the record, rewriting BLAS in Python (or anything else), even if the result was faster (!), would be a phenomenally bad idea. It would just introduce bugs, waste everyone's time, essentially be a fork of BLAS. There's no upside I can see that justifies it.

Re: Python 3.13 Gets a JIT

#49

Post by jampekka »

JodieBenitez wrote: post #35
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.

Because it's already fast enough for most of us ? Anecdote, but I've had my share of slow things in Javascript that are not slow in Python. Try to generate a SHA256 checksum for a big file in the browser... Good to see progress anyways.

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.

Re: Python 3.13 Gets a JIT

#50

Post by pjmlp »

kragen wrote: post #42
pjmlp wrote: post #41

Earlier quoted context omitted.

Ahead-of-time compilation is a bad solution for dynamic languages, so that is an expected outcome for Perl. The base line should be how heavily dynamic languages like my favourite set, Smalltalk, Common Lisp, Dylan, SELF, NewtonScript, ended up gaining from JIT, versus the original interpreters, while being in the genesis of many relevant papers for JIT research.

when i wrote ur-scheme one of the surprising things i learned from it was that ahead-of-time compilation worked amazingly well for scheme. scheme is ruthlessly monomorphic but i was still doing a type check on every primitive argument i didn't realize they ever jitted newtonscript

NewtonScript 2.0 introduced a mechanism to manually JIT code, functions marked as native get compiled into machine code.

Had the Newton not been canceled, probably there would be an evolution from that support.

See "Compiling Functions for Speed"

https://www.newted.org/download/manuals/NewtonToolkitUsersGu...

Post reply on HN