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

161–170 of 553 posts

Re: Python 3.13 Gets a JIT

#161

Post by pas »

nyanpasu64 wrote: post #67
est31 wrote: post #15

Earlier quoted context omitted.

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…

Having recently implemented parallel image rendering in corrscope ( https://github.com/corrscope/corrscope/pull/450 ), I can say that friends don't let friends write performance-critical code in Python. Depending on prebuilt C++ libraries hampers flexibility (eg. you can't customize the memory management or rasterization pipeline of matplotlib). Python's GIL inhibits parallelism within a process, and the workaround o…

> Depending on prebuilt C++ libraries hampers flexibility (eg. you can't customize the memory management or rasterization pipeline of matplotlib).

But what is the counterfactual? Implementing the whole thing in Python? It seems much more work than forking/fixing matplotlib.

Re: Python 3.13 Gets a JIT

#162

Post by pas »

jampekka wrote: post #138
masklinn wrote: post #116

Earlier quoted context omitted.

It absolutely is relevant to the "python is slow reee" nonsense tho, which is the subject. Python-the-language being slow is not relevant for a lot of the users, because even if they don't know they use Python mostly as a convenient interface to huge piles of native code which does the actual work. And as noted upthread that's a significant part of the uptake of Python in scientific fields, and why pypy despite the h…

Python is slow, reee. This is a major problem in scientific fields. Currently there are sort of "two tiers" of scientific programmers: ones who write the fast binary libraries and ones that use these from Python (until they encounter e.g. having to loop and they are SOL). This is known as the two language problem. It arises from Python being slow to run and compiled languages being bad to write. Julia tries to solve…

The major problem in scientific fields is not this, but the amount of incompetence and the race-to-the-bottom environment which enables it. Grant organizations don't demand rigor and efficiency, they demand shiny papers. And that's what we get. With god awful code and very questionable scientific value.

Re: Python 3.13 Gets a JIT

#163

Post by moffkalast »

japanman185 wrote: post #52
pjmlp wrote: post #37

Earlier quoted context omitted.

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

Disregarding the fact that python is an awful programming language for anthing other than jupyter notebooks

Ah I'd say the exact opposite, python in general is pretty good but jupyter sucks because the syntax isn't compatible with regular python and I avoid it like the plague.

Re: Python 3.13 Gets a JIT

#164

Post by lifthrasiir »

formerly_proven wrote: post #150
lifthrasiir wrote: post #91

Earlier quoted context omitted.

An important context here is that the same code was reused for interpreter and JIT implementations (that's a main selling point for copy-and-patch JIT). In the other words, this 2--9% improvement mostly represents the core interpreter overhead that JIT should significant reduce. It was even possible that JIT itself might have no performance impact by itself, so this result is actually very encouraging; any future opc…

Copy&patch seems not much worse than compiling pure Python with Cython, which roughly corresponds to "just call whatever CPython API functions the bytecode interpreter would call for this bunch of Python", so that's roughly a baseline for how much overhead you get from the interpeter bit.

There is no reason to use copy-and-patch JIT if that were the case, because the good old threaded interpreter would have been fine. There are other optimization works in parallel with this JIT effort, including finer-grained micro operations (uops) that can replace usual opcodes at higher tiers. Uops themselves can be used without JIT, but the interpreter overhead is proportional to the number of (u)ops executed and would be too large for uops. The hope is that copy-and-patch JIT combined with uops have to be much faster than threaded code.

Re: Python 3.13 Gets a JIT

#165

Post by andrewaylett »

pjmlp wrote: post #145
eesmith wrote: post #62

Earlier quoted context omitted.

I think Python without a JIT in many cases is already fast enough for most cases. I don't do data science.

Sure, for UNIX scripting, for everything else it is plainfully slow. I know Python since version 1.6, and is my scripting language in UNIX like environments, during my time at CERN, I was one of the CMT build infrastructure build engineer on the ATLAS team. It was never been the language I would reach for when not doing OS scripting, and usually when a GNU/Linux GUI application happens to be slow as mollasses, it has…

A Python web service my team maintains, running at a higher request rate and with lower CPU and RAM requirements than most of the Java services I see around us, would like a word with you.

Re: Python 3.13 Gets a JIT

#166

Post by BiteCode_dev »

mg wrote: post #90

I love Python and use it for everything other than web development. One reason is performance. So if Python has a faster future ahead of it: Hurray! The other reason is that the Python ecosystem moved away from stateless requests like CGI or mod_php use and now is completely set on long running processes. Does this still mean you have to restart your local web application after any change you made to it? I heard that…

In dev, this is handled mostly by the OS with things like inotify, so it has little perf impact.

In prod, you don't do it. Deployment implies sending a signal like HUP to your app, so that it reloads the code gracefully.

All in all, everybody is moving to thid, even php. This allows for persitent connexion, function memoization, delegation to threadpools, etc

Re: Python 3.13 Gets a JIT

#167

Post by vanderZwan »

kragen wrote: post #128
vanderZwan wrote: post #123

Earlier quoted context omitted.

> fucking cpython is allocating its integers on the heap and motherfucking reference-counting them And here I thought that it was shocking to learn that v8 allocates doubles on the heap recently. (I mean, I'm not a compiler writer, I have no idea how hard it would be to avoid this, but it feels like mandatory boxed floats would hurt performance a lot)

nanboxing as used in spidermonkey ( https://piotrduperas.com/posts/nan-boxing ) is a possible alternative, but i think v8 works pretty hard to not use floats, and i don't think local-variable or temporary floats end up on the heap in v8 the way they do in cpython. i'm not that familiar with v8 tho (but i'm pretty sure it doesn't refcount things)

> i think v8 works pretty hard to not use floats

Correct, to the point where at work a colleague and I actually have looked into how to force using floats even if we initiate objects with a small-integer number (the idea being that ensuring our objects having the correct hidden class the first time might help the JIT, and avoids wasting time on integer-to-float promotion in tight loops). Via trial and error in Node we figured that using -0 as a number literal works, but (say) 1.0 does not.

> i don't think local-variable or temporary floats end up on the heap in v8 the way they do in cpython

This would also make sense - v8 already uses pools to re-use common temporary object shapes in general IIRC, I see no reason why it wouldn't do at least that with heap-allocated doubles too.

Re: Python 3.13 Gets a JIT

#168

Post by kragen »

vanderZwan wrote: post #167
kragen wrote: post #128

Earlier quoted context omitted.

nanboxing as used in spidermonkey ( https://piotrduperas.com/posts/nan-boxing ) is a possible alternative, but i think v8 works pretty hard to not use floats, and i don't think local-variable or temporary floats end up on the heap in v8 the way they do in cpython. i'm not that familiar with v8 tho (but i'm pretty sure it doesn't refcount things)

> i think v8 works pretty hard to not use floats Correct, to the point where at work a colleague and I actually have looked into how to force using floats even if we initiate objects with a small-integer number (the idea being that ensuring our objects having the correct hidden class the first time might help the JIT, and avoids wasting time on integer-to-float promotion in tight loops). Via trial and error in Node w…

so then the remaining performance-critical case is where you have a big array of floats you're looping over. in firefox that works fine (one allocation per lowest-level array, not one allocation and unprefetchable pointer dereference per float), but maybe in chrome you'd want to use a typedarray?

Re: Python 3.13 Gets a JIT

#169

Post by Difwif »

guenthert wrote: post #108
blagie wrote: 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…

AFAIK good JITs like V8 can do runtime introspection and recompile on the fly if types change. Maybe using the type hints will be helpful but I don't think they are necessary for significant improvement.

Re: Python 3.13 Gets a JIT

#170

Post by nritchie »

At the end of the day, the number of optimizations that even a JIT can do on Python is limited because all variables are boxed (each time the variable is accessed the type of the variable needs to be checked because it could change) and then function dispatches must be chosen based on the type of the variable. Without some mechanism to strictly type variables, the number of optimizations will always be limited.
Post reply on HN