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

501–510 of 553 posts

Re: Python 3.13 Gets a JIT

#501

Post by im3w1l »

nextaccountic wrote: post #493
eyegor wrote: post #481

Earlier quoted context omitted.

In my experience, pypy works with basically everything these days. I remember having some struggles with a weird fortran based extension module a few years ago, but it might work now too. Most c extension modules should work in pypy, there's just a performance hit depending on how they're built (cffi is the most compatible). https://doc.pypy.org/en/latest/faq.html#do-c-extension-modul...

The point of using C extensions is to have better performance. Python is already slow in general; code that use such extensions typically depend on this performance to not be unbearable (such as data science) People wanting to use Pypy usually do so because they want better performance. Having a performance hit while using pypy is disconcerting. I was speculating that in the future, C extensions in pypy would be fast…

I get what you are saying, but normally this wouldn't matter too much right? You will have a small number of calls into the C-extension that together do a lot of work. So as a percentage the ffi-overhead is small.

Re: Python 3.13 Gets a JIT

#502

Post by acdha »

Sohcahtoa82 wrote: post #413
acdha wrote: post #397

Earlier quoted context omitted.

Just wait until you see what the enterprise Java developers passing around with type Object and encoded XML blobs. Type checking is really useful but it can be defeated in any language if you don’t have a healthy technical culture.

Is that why I see much object serialization/deserialization in Java? They're trying to pass data between layers of middleware, but Java has very strict typing, and the middleware doesn't know what kind of object it will get, so it has to do tons of type introspection and reflection to do anything with the data?

There are multiple causes but a lot of the nastiest code I’ve seen did suggest “I don’t have time to update those other layers”, along with the very common misperception that you’re working on a huge shared service for the ages and need everything to be as generic and customizable as possible.

Re: Python 3.13 Gets a JIT

#503

Post by davidkpiano »

giancarlostoro wrote: post #314
vanderZwan wrote: post #82

I think it's really cool that Haoran Xu and Fredrik Kjolstad's copy-and-patch technique[0] is catching on, I remember discovering it through Xu's blog posts about his LuaJIT remake project[1][2], where he intends to apply these techniques to Lua (and I probably found those through a post here). I was just blown away by how they "recycled" all these battle-tested techniques and technologies, and used it to synthesize…

Reminds me of David K who is local to me in Florida, or was, last I spoke to him. He has been a Finite State Machine advocate for ages, and its a well known concept, but you'd be surprised how useful they can be. He pushes it for front-end a lot, and even implemented a Tic Tac Toe sample using it. https://twitter.com/DavidKPiano

Oh hey it's me!

Re: Python 3.13 Gets a JIT

#504

Post by vanderZwan »

fuzztester wrote: post #477
twbarr wrote: post #372

Earlier quoted context omitted.

Ultimately, most good ideas were first implemented by Fabrice Bellard.

Heard of him; he's done a lot of stuff. So is he the Bourbaki of software? https://en.m.wikipedia.org/wiki/Nicolas_Bourbaki

While I'm sure some people theorize that Fabrice Bellard is actually a pseudonym of a collective of 10x programmers, he is as far as I know just one person.

Re: Python 3.13 Gets a JIT

#505

Post by frou_dh »

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!

I think it's more an issue of framing sometimes causing confusion, i.e. the ultimate trajectory is probably "crushingly slow → slow" rather than fastness coming in to it.

(h/t https://news.ycombinator.com/item?id=35906158)

Re: Python 3.13 Gets a JIT

#506

Post by klibertp »

systems wrote: post #292
dbrueck wrote: post #262

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…

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

Such devs are increasingly rare and, in some domains, almost nonexistent. For example, Kotlin borrowed a lot of nice features from Scala and Groovy, yet 99% of Kotlin code I've seen professionally never touched those features. Kotlin on Android seems to be overwhelmingly written by barely (or not at all) re-trained Java devs; moreover, those who never learned anything more recent than 1.8 (at least they know what lambdas are.)

In short, it's not about the language; it's about the people who use that language. Wishing a language to vanish is misguided - it wouldn't change anything. The people would just switch to the next language and would still program in the same style. You can write Fortran in every language - this is as true today as it was back in the 70s, but the percentage of people who can't be bothered to stop writing Fortran (metaphorically, in more literal meaning their first language, whatever it was) even after changing to another language got much higher. IMO due to the changes in how programming as a trade is perceived in society... but that's perhaps a rant for another time :)

Re: Python 3.13 Gets a JIT

#508

Post by BeetleB »

aktenlage wrote: post #419
chalst wrote: post #381

Earlier quoted context omitted.

5.5% compounded over 5 years is a bit over 30%: not a huge amount but an easily noticeable speed-up. What were you thinking of when you typed “significantly faster”?

Compunding a decrease works differently than an increase. If something gets 10% faster twice it actually got 19% faster. In other words, the runtime is 90% of 90%, i.e. 81%.

> If something gets 10% faster twice it actually got 19% faster

21%, not 19%.

It is 1.1 * 1.1 = 1.21

You are right in the opposite direction. If it got 10% slower, then it is 0.9 * 0.9 = 0.81 = 19% slower

Re: Python 3.13 Gets a JIT

#509

Post by BeetleB »

treyd wrote: post #440
pletnes wrote: post #221

Earlier quoted context omitted.

Microsoft are paying core devs to work on it full time, for one.

Which is strange considering how bad the tooling to use Python on Windows is. There's a few workflows where people have gone down the beaten path before (Conda, etc.), but outside of that you have to just pretend you're on Linux and use the cygwin toolchains and even that doesn't always work so well. Better support on Linux was a top 5 reason for me making the switch to using it full time when I went off to college,…

Not sure what you mean. I use Python for Windows all the time at work, and on Linux at home. I've not noticed any meaningful difference in my workflow.

Re: Python 3.13 Gets a JIT

#510

Post by bastawhiz »

eslaught wrote: post #479
bastawhiz wrote: post #386

Earlier quoted context omitted.

PyPy was released 17 years ago Jython was released 22 years ago IronPython was released 17 years ago To date, no Python implementation has managed to hit all three: 1. Stay compatible with any recent, modern CPython version 2. Maintain performance for general-purpose usage (it's fast enough without a warmup, and doesn't need to be heavily parallelized to see a performance benefit) 3. Stayed alive Which, frankly, is k…

Isn't PyPy up to 3.10 by now? At least that's what Homebrew reports to me. PyPy seems pretty alive, all things considered, and for my code bases I've seen pretty dramatic speedups on the order of 2-5x. That's basically a no brainer unless I'm doing something with incompatible C extensions, which I think is the real Achilles heel of all of these alternative implementations.

PyPy has definitely had the most success of all other implementations, but it still has a painful warmup period for many workloads. I can't imagine it's an effective option for anyone to install as the default Python implementation on their laptop, for instance. And for many, many years, it had almost no modern Python support (but I'm of course very glad to see it's slowly catching up).

It is encouraging for PyPy to see some influx of money in recent years. But I will continue to patiently wait for it to hit enough of a sweet spot of performance vs usability vs compatibility to see real adoption.

Post reply on HN