Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 3.15's JIT is now back on track

fidget-spinner.github.io

Post reply on HN
Print view View original

51–60 of 330 posts

Re: Python 3.15's JIT is now back on track

#51

Post by brokencode »

RussianCow wrote: post #35
brokencode wrote: post #31

Earlier quoted context omitted.

Are you forgetting about PyPy, which has existed for almost 2 decades at this point?

That's a completely separate codebase that purposefully breaks backwards compatibility in specific areas to achieve their goals. That's not the same as having a first-class JIT in CPython, the actual Python implementation that ~everyone uses.

Definitely agree that it’s better to have JIT in the mainline Python, but it’s not like there weren’t options if you needed higher performance before.

Including simply implementing the slow parts in C, such as the high performance machine learning ecosystem that exists in Python.

Re: Python 3.15's JIT is now back on track

#53

Post by bawolff »

ecshafer wrote: post #12

What is wrong with the Python code base that makes this so much harder to implement than seemingly all other code bases? Ruby, PHP, JS. They all seemed to add JITs in significantly less time. A Python JIT has been asked for for like 2 decades at this point.

I thought php hasn't shipped jit yet (as in its behind a disabled by default config)

Re: Python 3.15's JIT is now back on track

#54

Post by froobius »

echelon wrote: post #48
0cf8612b2e1e wrote: post #36

Earlier quoted context omitted.

The Python C api leaks its guts. Too much of the internal representation was made available for extensions and now basically any change would be guaranteed to break backwards compatibility with something.

It's a shame that Python 2->3 transition was so painful, because Python could use a few more clean breaks with the past. This would be a potential case for a new major version number.

On the other hand, taking backwards compatibility so seriously is a big part of the massive success of Python

Re: Python 3.15's JIT is now back on track

#55

Post by fridder »

ecshafer wrote: post #12

What is wrong with the Python code base that makes this so much harder to implement than seemingly all other code bases? Ruby, PHP, JS. They all seemed to add JITs in significantly less time. A Python JIT has been asked for for like 2 decades at this point.

For better or for worse they have been very consistent throughout the years that they don't want want to degrade existing performance. It is why the GIL existed for so long

Re: Python 3.15's JIT is now back on track

#56

Post by luhn »

nonameiguess wrote: post #52
fluidcruft wrote: post #13

(what are blueberry, ripley, jones and prometheus?)

The immediate question has been answered, but what about the names? The latter three are obvious references to the Alien universe, but what relationship does blueberry have to them?

I assume Blueberry is a nod to the machine being a Raspberry Pi.

Re: Python 3.15's JIT is now back on track

#57

Post by flykespice »

RussianCow wrote: post #32
stmw wrote: post #20

Earlier quoted context omitted.

Some languages are much harder to compile well to machine code. Some big factors (for any languages) are things like: lack of static types and high "type uncertainty", other dynamic language features, established inefficient extension interfaces that have to be maintained, unusual threading models...

That makes sense if you're comparing with Java or C#, but not Ruby, which is way more dynamic than Python. The more likely reason is that there simply hasn't been that big a push for it. Ruby was dog slow before the JIT and Rails was very popular, so there was a lot of demand and room for improvement. PHP was the primary language used by Facebook for a long time, and they had deep pockets. JS powers the web, so there…

> Python never really had that same level of investment, at least from a performance standpoint.

Or lack of incentive?

Alot of big python projects that does machine learning and data processing offloads the heavy data processing from pure python code to libraries like numpy and pandas that take advantage of C api binding to do native execution.

Re: Python 3.15's JIT is now back on track

#58

Post by IshKebab »

froobius wrote: post #54
echelon wrote: post #48

Earlier quoted context omitted.

It's a shame that Python 2->3 transition was so painful, because Python could use a few more clean breaks with the past. This would be a potential case for a new major version number.

On the other hand, taking backwards compatibility so seriously is a big part of the massive success of Python

Python does not take backwards compatibility very seriously at all. Take a look at all the deprecated APIs.

I would say it's probably worth it to clean up all the junk that Python has accumulated... But it's definitely not very high up the list of languages in terms of backwards compatibility. In fact I'm struggling to think of other languages that are worse. Typescript probably? Certainly Go, C++ and Rust are significantly better.

Re: Python 3.15's JIT is now back on track

#59

Post by SahAssar »

bawolff wrote: post #53
ecshafer wrote: post #12

What is wrong with the Python code base that makes this so much harder to implement than seemingly all other code bases? Ruby, PHP, JS. They all seemed to add JITs in significantly less time. A Python JIT has been asked for for like 2 decades at this point.

I thought php hasn't shipped jit yet (as in its behind a disabled by default config)

PHP 8 shipped with JIT on by default unless I'm mistaken.

Re: Python 3.15's JIT is now back on track

#60

Post by pansa2 »

froobius wrote: post #54
echelon wrote: post #48

Earlier quoted context omitted.

It's a shame that Python 2->3 transition was so painful, because Python could use a few more clean breaks with the past. This would be a potential case for a new major version number.

On the other hand, taking backwards compatibility so seriously is a big part of the massive success of Python

>> Python 2->3 transition

> taking backwards compatibility so seriously

Python’s backward compatibility story still isn’t great compared to things like the Go 1.x compatibility promise, and languages with formal specs like JS and C.

The Python devs still make breaking changes, they’ve just learned not to update the major version number when they do so.

Post reply on HN