Hacker News

points by PathOfEclipse 2 days ago | 0 comments

How many Python JIT experiments have failed? I find it interesting because Ruby is probably harder to optimize than Python but Ruby has had a JIT for a long time. Maybe base python is more optimized than base Ruby so the JIT is incrementally not changing much? Also, I'd expect javascript to be harder to optimize but it has JITs. That could just be a funding issue, though. There's probably much more money and incentive to optimize Javascript.

[–] necovek 2 days ago

The type of dynamic language gymnastics done with Python is huge: any sufficiently well known library basically employs some sort of meta-programming of the language:

  * Typing is a non-obligatory add-on to the syntax
  * SQLAlchemy and other ORMs override basic operators like "=" and employ metaclass programming heavily to create Python-like SQL query builders
  * Pytest rewrites all the assertions as it side-steps bytecode generation (so your .pyc files are different than what they would be without pytest)
  * Many libraries depend on monkey-patching live library calls, including ones to external dependencies
  * The way async was added in is another bolt-on where the same code behaves differently in different contexts
  * Decorators can introduce any side-effect you imagine, and nobody (including core libraries) follow the golden rule of "don't do, only decorate"
  * Many debugging and profiling mechanisms (including REPL) depend on these properties to function — including observability tooling like Sentry, Datadog etc.
  ...

JavaScript never had that level of flexibility (for better and for worse), and by extension, it's easier to build an alternative implementation and keep it compatible with the rest of the world that claims to be JavaScript.

[–] xorcist 2 days ago

> The type of dynamic language gymnastics done with Python is huge

Have you seen Ruby?

[–] KerrAvon 2 days ago

Ruby is essentially Smalltalk (see also Objective-C).

I don't know Python's innards well enough to understand why it's so especially difficult in this regard, but I gather around the edges that its object model may not be as well founded.

[–] jashmatthews 2 days ago

JIT compiling Ruby or Python in a way that speeds up code using existing libraries and frameworks is harder. We built up decades of code that does stuff that it would be a lot easier for JIT performance if we didn't do, like using C extensions instead of defined FFI.

https://arxiv.org/html/2609.01502v1

[–] pjmlp 2 days ago

The common excuse that ignores Smalltalk, Self, Lisp Machines like Interlisp-D, and more recently Ruby.

All just as dynamic as Python, and with quite usable JIT compilers.

Or for that matter, PyPy and GraalPy do exist.

[–] cdavid 1 day ago

The common excuse is indeed wrong, as pypy proved. IMO the real issue is the python C API.

The python C API is the "killer app" of python, and what gave its edge against otherwise similar languages (ruby/js). That's makes it unique (the whole scientific stack). But a lot of early choices leaked into this API, and this (+ preference from guido for simple implementation) is at odds with doing JIT: lots of global state (instead of explicitly passing interpreter state), ref counting, no tagged pointers meaning boxing/unboxing everywhere, etc. Some of those are getting gradually fixed, but that's a slog, though maybe AI can accelerate a lot.

I had high hopes for HPy but that unfortunately fizzled out.

[–] necovek 2 days ago

Obviously, I am not saying making a JIT for Python is impossible: both PyPy and GraalPy prove otherwise. We are talking about full ecosystem support, not just the base language and stdlib.

Can you just replace CPython with PyPy or GraalPy in every project? And why not? :)

[–] pjmlp 2 days ago

Because the Python community writes libraries in C, C++, Fortran and Rust, to make up for the CPython slowness, using CPython C API, calls them Python libraries, and they naturally only work in CPython.

PyPy and GraalPy then never get to use those pseudo "Python" libraries, because their API for C based extensions differs enough that you cannot take a random shared library and load them into either.

They came up with a common C API proposal, but has hardly taken that much adoption.

[–] necovek 2 days ago

Indeed, mixing all the language features and anti-features with non-native Python libraries is a big reason too — both because it mitigates many of the performance issues a JIT would solve, but mostly because it complicates or makes the implementation unfeasible altogether.

[–] cyberax 2 days ago

Operator overloading is a non-issue, it's just another form of method calls.

JavaScript also has monkey-patching, and it's also very common. E.g. SolidJS replaces objects with dependency-tracking proxies.

There are really no fundamental language reasons why Python should be more complex. From what I heard from a JIT developer, the main issue is not the code itself but the module system and code loading.

JavaScript was designed from the start to operate inside a sealed environment with only few external handles, with the code loaded upfront or added on-demand via "eval". Not so for Python, where native code modules can (and will) result in code loaded dynamically and it's hard to track what depends on what.

[–] pjmlp 2 days ago

See Self and Smalltalk for such kind of highly dynamic environment with code being loaded, and completely changing the running image on the fly.

Yet both languages are on the genesis of modern JIT compilers, going beyond what was already being done for Lisps, Prolog, BASIC.

[–] exyi 2 days ago

> JavaScript also has monkey-patching, and it's also very common. E.g. SolidJS replaces objects with dependency-tracking proxies.

And the proxies make it slow as Python. Plain objects cannot suddenly become proxies, so the runtime can treat them as a special case.

[–] mistrial9 2 days ago

> Many libraries depend on monkey-patching live library calls, including ones to external dependencies

someone please think of the monkey patchers!

[–] gopalv 2 days ago

Python is harder to JIT because of the way __dict__ works.

If all python had was __slots__ then we would not be struggling to JIT python.

Tight numerical loops is where the JIT adds performance.

Most performance sensitive features are already available in python between numpy, numba and Cython without really leaving the language core.

You'll mostly be speeding up the slow parts of python, not supercharging the fast parts.

[–] hermitdev 2 days ago

> Python is harder to JIT because of the way __dict__ works.

Heh, how about how `__class__` works? Not that I recommend actually doing this, but you can literally change the type of an already instantiated object by reassigning `__class__`:

    >>> class Dog:
    ...     def hi(self):
    ...             print("woof")
    ...
    >>> class Cat:
    ...     def hi(self):
    ...             print("meow")
    ...
    >>> dog = Dog()
    >>> dog.hi()
    woof
    >>> dog.__class__ = Cat
    >>> dog.hi()
    meow
    >>> isinstance(dog, Dog)
    False
    >>> isinstance(dog, Cat)
    True
    >>>

[–] samatman 2 days ago

Lua has the same property with metatables. LuaJIT, which is very fast, has a solution: if you change a metatable after assigning it, or reassign a metatable, Mike Pall turns his back on you. Your code dies slowly, in the outer darkness of the interpreter loop, never to be JIT’ted upon again.

[–] sakesun 2 days ago

I've been doing things in Python for over 20 years. Only recently I learn that I can do this.

    >>> Dog.__bases__ = (Cat,)
    >>> isinstance(dog, Dog)
    True
    >>> isinstance(dog, Cat)
    True
    >>>

[–] pjmlp 1 day ago

Smalltalk, Self, Common Lisp, Ruby as well, no big deal in regards to JIT code.

[–] gregdeon 2 days ago

This is wild. Is it part of Python's specification, or an implementation detail of CPython?

[–] sakesun 2 days ago

As far as I understand, CPython implementation is THE specification. Some billions dollar ERP system firmly rely on this behavior, btw.

[–] gregdeon 1 day ago

Yeah, I was afraid you would say that.

[–] sakesun 1 day ago

Just check with pypy and Graalpy. Both support this as well.

[–] dcrazy 1 day ago

Is the question whether multiple base classes are part of Python’s spec, or if the ability to assign to `__class__` is part of the spec?

[–] esprehn 2 days ago

That's also possible in JS with __proto__. The prototypes of the classes in the chain can be mutated at runtime too. How to handle these cases is well understood for JITs though and python could do the same.