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

321–330 of 553 posts

Re: Python 3.13 Gets a JIT

#321

Post by dataangel »

londons_explore wrote: post #172
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.

> . I don't see an architectural path from a cut-and-paste JIT to something optimizing. One approach used in V8 is to have a dumb-but-very-fast JIT (ie. this), and keep counters of how often each block of code runs (perhaps actual counters, perhaps using CPU sampling features), and then any block of code running more than a few thousand times run through a far more complex yet slower optimizing jit. That has the bene…

> keep counters of how often each block of code runs ... and then any block of code running more than a few thousand times run through a far more complex yet slower optimizing jit.

That's just all JITs. Sometimes its counters for going from interpreter -> JIT rather than levels of JITs, but this idea is as old as JITs.

Re: Python 3.13 Gets a JIT

#322

Post by jampekka »

adgjlsfhk1 wrote: post #276
jampekka wrote: post #264

Earlier quoted context omitted.

Yes, but it's a good list of the major problems, and laudable for a self-professed "stan" to be upfront about them. It's my assesment that the problems listed in there are a cause why Julia will not take off and we're largely stuck with Python for the foreseeable future.

It is worth noting that the first of the reasons presented is significantly improved in Julia 1.9 and 1.10 (released ~8 months and ~1 month ago). The time for `using BioSequences, FASTX` on 1.10 is down to 0.14 seconds on my computer (from 0.62 seconds on 1.8 when the blog post was published).

TTFX is indeed getting a lot better. But e.g. "using DynamicalSystems" is still over 5 seconds.

There is something big going on in caching the binaries, so there's a chance the TTFX will get workable.

Re: Python 3.13 Gets a JIT

#323

Post by peterfirefly »

Pxtl wrote: post #216

I still don't get why they didn't reduce API of the interpreter internals in Python 3 so that things like this would be more achievable. If you're going to break backwards compatibility, it's not like Unicode was the only foundational problem Python 2 had.

They did change the API for Python modules implemented in C. That was actually part of the reason why the 2->3 transition went so badly.

It wasn't realistic to switch to 3.x when the libraries either weren't there or were a lot slower (due to using pure Python instead of C code).

It also wasn't realistic to rewrite the libraries when the users weren't there.

It was in many respects a perfect case study in how not to do version upgrades.

Re: Python 3.13 Gets a JIT

#324

Post by dataangel »

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…

I doubt it with a copy-and-patch JIT, not the way they work now. I'm a serious mypy/python-static-types user and as is they currently wouldn't allow you to do much optimization wise.

- All integers are still big integers

- Use of the typing opt-out 'Any' is very common

- All functions/methods can still be overwritten at runtime

- Fields can still be added and removed from objects at runtime

The combination basically makes it mandatory to not use native arithmetic, allocate everything on the heap, and need multiple levels of indirection for looking up any variable/field/function. CPU perf nightmare. You need a real optimizing JIT to track when integers are in a narrow range and things aren't getting redefined at runtime.

Re: Python 3.13 Gets a JIT

#326

Post by Gollapalli »

crabbone wrote: post #245
DeathArrow wrote: post #239

If JIT is a good thing for Python, why don't just compile to Java or .NET bytecode and use their already optimized infrastructure?

Given how many Microsoft employees today steer the Python decision making process, I'm sure in not so distant future, we might see a new CLR-based Python implementation. Maybe Microsoft don't know yet how to sell this thing, or maybe they are just boiling the frog. Time will tell. But I'm pretty sure your question will be repeated as soon as people will get used to the idea of Python on JIT.

“Python code runs 15% faster and and 20% cheaper on azure than aws, thanks to our optimized azurePython runtime. Use it for azure functions and ml training”

Just a guess at the pitch.

Re: Python 3.13 Gets a JIT

#327

Post by adhamsalama »

Ringz wrote: post #201
Joker_vD wrote: post #183

Earlier quoted context omitted.

But type declarations in Python are not required to be correct, are they? You are allowed to write def twice(x: int) -> int: return x + x print(twice("nope")) and it should print "nopenope". Right?

Yep. Therefore it’s better to def twice(x: int) -> int: if not isinstance(x, int): raise TypeError("Expected x to be an int, got " + str(type(x))) return x + x

Or use mypy.

Re: Python 3.13 Gets a JIT

#328

Post by Timothycquinn »

_bohm wrote: post #256
crabbone wrote: post #245

Earlier quoted context omitted.

Given how many Microsoft employees today steer the Python decision making process, I'm sure in not so distant future, we might see a new CLR-based Python implementation. Maybe Microsoft don't know yet how to sell this thing, or maybe they are just boiling the frog. Time will tell. But I'm pretty sure your question will be repeated as soon as people will get used to the idea of Python on JIT.

Doesn't this already exist in IronPython?

Correct. I just checked the project yesterday and they are presently at 3.4 :-|

Re: Python 3.13 Gets a JIT

#329

Post by moffkalast »

smabie wrote: post #312
moffkalast wrote: post #163

Earlier quoted context omitted.

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.

What does a jupyter notebook have to do with python syntax?

Take the code you find in an average notebook, copy it to a .py text file, run it with python. Does it run? In my experience the answer is usually 'no' because of some extra-ass syntax sugar jupyter has that doesn't exist in python.

Re: Python 3.13 Gets a JIT

#330

Post by zbentley »

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…

> If you pre-open shared memory in a ProcessPoolExecutor's initializer functions, you can't close them when the worker process exits

That's quite surprising to learn, as I didn't think the initializer ran in a specialized context (like a pthread_atfork postfork hook in the child).

What happens when you try to close an initializer-allocated SharedMemory object on worker exit?

Post reply on HN