Comment by 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.

29 comments

PathOfEclipse

Reply
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.

      1 reply →

  • 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? :)

      2 replies →

  • cyberax  17 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  8 hours ago

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

    someone please think of the monkey patchers!

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
    >>>

  • cpburns2009  18 hours ago

    I've never bought this argument. Underneath all of the magic inheritance in Python is just the MRO (method resolution order). That's not characteristically any different from JavaScript's prototype chain. There's no reason a Python JIT couldn't optimize everything JavaScript does, and if you do specifically access `self.__dict__`, that can be a cold, unoptimizable path.

    • hinkley  14 hours ago

      One of the tricks here is to treat the happy path as a quasi-invariant and leave a guard that branches to slow code if the invariant didn’t hold.

      I saw this presented as new tech at either OOPSLA or OSCon almost exactly 20 years ago.

      CPU branch prediction is still pretty good even with the loss of function in recent years.

      1 reply →

    • gobdovan  16 hours ago

      I'd say that's about right. The way people usually code in Python, mro is quite stable and most lookups would be cache hits. You can still get more weird invalidation in Python cuz they let you change stuff like `__bases__`, or you get some weird `__getattribute__` change in some place that would force you to invalidate more than you'd initially think should be necessary.

  • rurban  2 hours ago

    Same as for the common lisp or raku mop. You check for the default, and use the fast path if so. And if you can guarantee that nobody changed those keys or values, lift that check to the front.

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.