Live data from Hacker News

Python JIT project was asked to pause development

discuss.python.org

91–100 of 105 posts

Re: Python JIT project was asked to pause development

#91
post #22

Earlier quoted context omitted.

Python software is to a large extent either doing things in not-python (c, c++, rust, etc.) or doing things that are not cpu bound (io bound, async, etc.). If you're cpu bound then you can either take a 2x jit improvement or take a 10x non-python improvement. There's few companies of a scale where the non-hot path cost of 2x cpu is so massive as to be worth caring about.

The python overhead of launching big ML jobs is nontrivial, so I think speeding that up would be meaningful. (I mean the initial tracing and other setup, not things once the GPUs are actually doing the work).

That seems more like the tracing overhead than the python overhead. The original jit proposal would I believe not help at all with that since ML workloads basically do their own jit. The post being discussed however pushes for a general framework and good tracing support so might help ML workloads.

Re: Python JIT project was asked to pause development

#92
post #89
post #86

Earlier quoted context omitted.

Except it’s not. The intention of JIT in CPython is to make it into the main branch feature complete. If they can’t get the necessary support then it won’t be relegated to niche uses, it’ll be abandoned and need a new effort to get off the ground. Not even remotely the same context.

It certainly is the same context, given the Python culture to ignore JITs, rewrite in C, and call it "Python" libraries. We have been here several times, versus the other dynamic languages, and it has nothing to do with the usual excuse how dynamic Python happens to be.

I don’t know why you keep bringing up Python being dynamic, it’s not particularly relevant. What matters is the content of the request which is to outline how the feature should work and be maintained over time before it can be accepted.

What’s your position? That we should allow an extremely complex system into Python with:

- No clear design goal?

- No maintenance plan?

- No discussion with the steering committee?

PyPy and Jython, and others are not built by the Python team and there has never been a suggestion that any of these systems would be part of CPython.

So again, I still don’t see how different implementations of Python are relevant to the discussion about CPython.

Re: Python JIT project was asked to pause development

#93
post #41

Earlier quoted context omitted.

So it will join PyPy and GraalPy in the corner. Python JIT history is full of drama, and no, Smalltalk, Common Lisp, Interlisp-D, SELF are just as dynamic if not more.

Honorable mention: https://github.com/tonybaloney/Pyjion

Not to forget Unladen Swallow Which even tried to merge into CPython: https://peps.python.org/pep-3146/

Re: Python JIT project was asked to pause development

#94
post #92
post #89

Earlier quoted context omitted.

It certainly is the same context, given the Python culture to ignore JITs, rewrite in C, and call it "Python" libraries. We have been here several times, versus the other dynamic languages, and it has nothing to do with the usual excuse how dynamic Python happens to be.

I don’t know why you keep bringing up Python being dynamic, it’s not particularly relevant. What matters is the content of the request which is to outline how the feature should work and be maintained over time before it can be accepted. What’s your position? That we should allow an extremely complex system into Python with: - No clear design goal? - No maintenance plan? - No discussion with the steering committee? P…

They are relevant for the Python culture towards JIT adoption.

Re: Python JIT project was asked to pause development

#95
post #88

Earlier quoted context omitted.

Why does it happen?

Default arguments are only evaluated once and assigned the same instance to every call that doesn't specify that argument. So when you assign a new list as a default argument and then append to that list, the next call will already have one element in that list. So what you need to do is have it "None-able" and within the function create a new list.

You can use anything immutable like a string, a number, a tuple of immutables, a frozendict, any dataclass with frozen=True, and so on.

No need to do the annoying if x is None.

Re: Python JIT project was asked to pause development

#97
post #82

Earlier quoted context omitted.

> We’ve seen bad implementations of things land before and now live forever. Er, doesn't that depend on how leaky the abstraction is? How often have you seen a JITted language be unable to swap in a new JITter due to some sort of unintended coupling?

If it’s so easy then writing a PEP and getting it approved in 6 months will be trivial.

"It"? What are you talking about? You didn't answer my question at all. I said if you have a second JIT to swap to in the future, you should be able to switch to that without breaking apps and not be forced to keep this implementation forever -- because JITs don't tend to expose APIs or leaky abstractions to the code, and it's not hard to ensure this one doesn't either. I asked you if you've ever seen another language that actually had another JIT to switch to but wasn't able to. Instead of addressing my point, you replied that it should be easy to write something else (a second JIT, "general infrastructure" for JITs, or whatever suits your fancy) and get it approved? What? No that is not, and I never claimed that would be easy. And if it has to be approved by someone who responds like this, it clearly wouldn't be fun either.

Re: Python JIT project was asked to pause development

#98
post #88

Earlier quoted context omitted.

Why does it happen?

Default arguments are only evaluated once and assigned the same instance to every call that doesn't specify that argument. So when you assign a new list as a default argument and then append to that list, the next call will already have one element in that list. So what you need to do is have it "None-able" and within the function create a new list.

Yes I know as much, but why? Is it for speed? Python is slow anyway, so no big deal. Incompetence? Malice perhaps?

Re: Python JIT project was asked to pause development

#99
post #98

Earlier quoted context omitted.

Default arguments are only evaluated once and assigned the same instance to every call that doesn't specify that argument. So when you assign a new list as a default argument and then append to that list, the next call will already have one element in that list. So what you need to do is have it "None-able" and within the function create a new list.

Yes I know as much, but why? Is it for speed? Python is slow anyway, so no big deal. Incompetence? Malice perhaps?

It's just because the `def xxx()` part gets executed once when the module is loaded so the default arguments get created then. It's not really a design choice.

If you declare a function inside a for loop with the default argument set to a list, it will be re-declared at every iteration of the loop and the list of the default argument will be a new instance every time.

Re: Python JIT project was asked to pause development

#100
Why is Python trying to be fast? Can it please stop messing around with the bytecode to make it "faster". If your user want speed, please for the love of god just use anything else. Just keep Python simple and immortal. I want to keep using Python as is for the next 50 years, please stop breaking shit because you want to fit a square into a rectangular hole.
Post reply on HN