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

31–40 of 553 posts

Re: Python 3.13 Gets a JIT

#31

Post by bdd8f1df777b »

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?

Yes, but not so good when the JIT-ed Python can no longer reference those fast C code others have written. Every Python JIT project so far has suffered from incompatibility with some C-base Python extension, and users just go back to the slow interpreter in those cases.

Re: Python 3.13 Gets a JIT

#32

Post by PartiallyTyped »

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.

Meta has actually been doing that — helping improve python's speed — with things like [1,2]

[1] https://peps.python.org/pep-0703/

[2] https://news.ycombinator.com/item?id=36643670

Re: Python 3.13 Gets a JIT

#33

Post by cturner »

irjustin wrote: post #13
jagaerglad wrote: post #11

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

[flagged]

The article will be a confusing read to someone who does not know what a JIT is.

Look at the paper after the heading "What is a JIT?"

The first paragraph moves towards an answer - "compilation design that implies that compilation happens on demand when the code is run the first time" But then it backtracks on this and says that it could mean many things, and gets wishy-washy, and says that python is already a JIT.

The second paragraph says, "What people tend to mean when they say a JIT compiler, is a compiler that emits machine code." What point is the author trying to make here? An Ahead of Time compiler emits machine code. But then it goes on to say that an Ahead of Time compiler also emits machine code. So what is a JIT?

The third paragraph starts talking about about mechanism, which is a distraction from the question it posed above - what is a JIT?

The article talks around points instead of making points.

Re: Python 3.13 Gets a JIT

#34

Post by PartiallyTyped »

fer wrote: post #10
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.

Easy and the number-crunching libs are optimized away in (generally) C.

and FORTRAN.

Re: Python 3.13 Gets a JIT

#35

Post by JodieBenitez »

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.

Re: Python 3.13 Gets a JIT

#36

Post by kragen »

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

Re: Python 3.13 Gets a JIT

#37

Post by pjmlp »

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.

It is a very big deal, as it will finally shift the mentality regarding:

- "C/C++/Fortran libs are Python"

- "Python is too dynamic", while disregarding Smalltalk, Common Lisp, Dylan, SELF, NewtonScript JIT capabilities, all dynamic languages where anything can change at any given moment

Re: Python 3.13 Gets a JIT

#38

Post by kragen »

pansa2 wrote: post #29
yellowstuff wrote: post #24

Earlier quoted context omitted.

There have been several attempts. For example, Google tried to introduce a JIT in 2011 with a project named Unladen Swallow, but that ended up getting abandoned.

Unladen Swallow was massively over-hyped. It was talked about as though Google had a large team writing “V8 for Python”, but IIRC it was really just an internship project.

well, there were a couple of guys working on it

Re: Python 3.13 Gets a JIT

#39

Post by dagw »

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?

But wouldn't it be great if you could just write your libraries in Python

Everybody obviously wants that. The question is are you willing to lose what you have in order to hopefully, eventually, get there. If Python 3 development stopped and Python 4 came out tomorrow and was 5x faster than python 3 and a promise of being 50-100x faster in the future, but you have to rewrite all the libraries that use the C API, it would probably be DOA and kill python. People who want a faster 'almost python' already have several options to choose from, none of which are popular. Or they use Julia.

Post reply on HN