Hacker News

PathOfEclipse 18 hours ago [ - ]

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 18 hours 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 17 hours ago [ - ]

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

Have you seen Ruby?

KerrAvon 12 hours 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 9 hours 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 15 hours 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.

necovek 12 hours 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 hours 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 an hour 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 16 hours 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 15 hours 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 11 hours 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 7 hours ago [ - ]

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

someone please think of the monkey patchers!

benrutter 2 hours ago [ - ]

> How many Python JIT experiments have failed?

Wait, how many? I'd say just this one. The other that I know of, pypy, was massively successful for a single maintainer project. And definitely showed the possibility/potential of JIT python.

I wouldn't call it a failure for not over taking mainline CPython.

gopalv 18 hours 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 14 hours 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
    >>>

sakesun 10 hours 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
    >>>

gregdeon 7 hours ago [ - ]

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

sakesun 6 hours ago [ - ]

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

esprehn 9 hours 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.