Live data from Hacker News

Python 3.13 Gets a JIT

tonybaloney.github.io

371–380 of 553 posts

Re: Python 3.13 Gets a JIT

#371
post #338

Why has it taken so much longer for CPython to get a JIT than, say, PyPy? I would imagine the latter has far less engineering effort and funding put into it.

For the longest time, CPython was deliberately optimized for simplicity. That's a perfectly reasonable choice: it's easier to reason about, easier for new maintainers to learn it, easier to alter, easier to fix when it breaks, etc. Also, CPUs are pretty good at running simple code very quickly. It's only fairly recently that there's been critical mass of people who thought that performance trumps simplicity, and even…

> It's only fairly recently that there's been critical mass of people who thought that performance trumps simplicity

This definitely wasn't true, from the user perspective. And, I'm not even convinced it's some "critical mass" of developers. These changes aren't coming from some mass of developers, there's coming from a few experts that had a clear plan, backed by the sanity of the huge disconnect that languages are actually meant for users of the language, not the developers of the language.

Re: Python 3.13 Gets a JIT

#372

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…

Copy and patch is a variant of QEMU's original "dyngen" backend by Fabrice Bellard[1][2], with more help from the compiler to avoid the maintainability issues that ultimately led QEMU to use a custom code generator. [1] https://www.usenix.org/legacy/event/usenix05/tech/freenix/fu... [2] https://review.gerrithub.io/plugins/gitiles/spdk/qemu/+/5a24...

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

Re: Python 3.13 Gets a JIT

#373
post #334
post #17

Honestly I don't understand the pessimistic view here. I think every release since Microsoft started funding python has increased high single digit best case performance. Rather than focussing on the raw number compare to python 3.5 or so. It's still getting significantly faster. If they keep doing this steady pace they are slowly saving the planet!

Julia is my source of pessimism. Julia is super fast once it's warmed up, but before it gets there, it's painfully slow. They seem to be making progress on this, but it's been gradual. I understand that Java had similar growing pains, but it's better now. Combined with the boondoggle of py3, I'm worried for the future of my beloved language as it enters another phase of transformation.

Would you say of the latest release (v1.10) that Julia is painfully slow until it gets “warmed up”? If so, what exactly does this mean?

Re: Python 3.13 Gets a JIT

#374
post #65

Earlier quoted context omitted.

From the write-up, I honestly don't understand how this paves the way. I don't see an architectural path from a cut-and-paste JIT to something optimizing. That's the whole point of a cut-and-paste JIT.

Isn't it the case that Python allows for type specifier (type hints) since 3.5, albeit the CPython interpreter ignores them? The JIT might take advantage of them, which ought to improve performance significantly for some code. That what makes Python flexible is what makes it slow. Restricting the flexibility were possible offers opportunities to improve performance (and allows for tools and humans to spot errors more…

Sort of! But also not really. If you want to get into this, I wrote a post about this: https://bernsteinbear.com/blog/typed-python/

Re: Python 3.13 Gets a JIT

#375
post #66

Earlier quoted context omitted.

Teaching. So many colleges/unis I know teach "Introduction to Programming" with Python these days, especially to non-CS students/pupils.

I think python is very well suited to people who do computation in Excel spreadsheets. For actual CS students, I'd rather see something like scheme be a first language (but maybe I'm just an old person)

Its even in Excel nowadays!!

Re: Python 3.13 Gets a JIT

#376

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!

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)

Re: Python 3.13 Gets a JIT

#377
post #334

Earlier quoted context omitted.

Julia is my source of pessimism. Julia is super fast once it's warmed up, but before it gets there, it's painfully slow. They seem to be making progress on this, but it's been gradual. I understand that Java had similar growing pains, but it's better now. Combined with the boondoggle of py3, I'm worried for the future of my beloved language as it enters another phase of transformation.

Would you say of the latest release (v1.10) that Julia is painfully slow until it gets “warmed up”? If so, what exactly does this mean?

I'm not that up to date on the language, it's been a few years since I did anything nontrivial with it because the experience was so poor. And while that might not seem fair to Julia, it's my honest experience: my concern isn't a pissing match between Julia and the world, it's that bad JIT experience is a huge turnoff and I'm worried about Python's future as it goes down this road.

Re: Python 3.13 Gets a JIT

#378

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!

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)

Guido is still involved, but he's no longer the BDFL.

Re: Python 3.13 Gets a JIT

#379
post #377

Earlier quoted context omitted.

Would you say of the latest release (v1.10) that Julia is painfully slow until it gets “warmed up”? If so, what exactly does this mean?

I'm not that up to date on the language, it's been a few years since I did anything nontrivial with it because the experience was so poor. And while that might not seem fair to Julia, it's my honest experience: my concern isn't a pissing match between Julia and the world, it's that bad JIT experience is a huge turnoff and I'm worried about Python's future as it goes down this road.

There has been so much progress in Julia’s startup performance in the past “few years” that someone’s qualitative impressions from several major releases before the current one are of limited relevance.

Re: Python 3.13 Gets a JIT

#380
post #371

Earlier quoted context omitted.

For the longest time, CPython was deliberately optimized for simplicity. That's a perfectly reasonable choice: it's easier to reason about, easier for new maintainers to learn it, easier to alter, easier to fix when it breaks, etc. Also, CPUs are pretty good at running simple code very quickly. It's only fairly recently that there's been critical mass of people who thought that performance trumps simplicity, and even…

> It's only fairly recently that there's been critical mass of people who thought that performance trumps simplicity This definitely wasn't true, from the user perspective. And, I'm not even convinced it's some "critical mass" of developers. These changes aren't coming from some mass of developers, there's coming from a few experts that had a clear plan, backed by the sanity of the huge disconnect that languages are…

critical mass of cpython devs
Post reply on HN