6 ms·

It turns out that if you have language semantics that make optimizations hard, making a fast optimizing compiler is hard. Who woulda thunk? To be clear, this s

It turns out that if you have language semantics that make optimizations hard, making a fast optimizing compiler is hard. Who woulda thunk? To be clear, this seems like a cool project and I dont want to be too negative about it, but i just think this was an entirely foreseeable outcome, and the amount of people excited about this JIT project when it was announced shows how poorly a lot of people understand what goes into making a language fast.

almostgotcaught 1y ago
> It turns out that if you have language semantics that make optimizations hard, making a fast optimizing compiler is hard. Who woulda thunk? Is this in the article? I don't see Python's semantics mentioned anywhere as a symptom (but I only skimmed). > shows how poorly a lot of people understand what goes into making a language fast. ...I'm sorry but are you sure you're not one of these people? Some facts: 1. JS is just as dynamic and spaghetti as Python and I hope we're all aware that it has some of the best jits out there; 2. Conversely, C++ has many "optimizing compiler[s]" and they're not all magically great by virtue of compiling a statically typed, rigid language like C++.
- o11c 1y ago
  JS is absolutely not as dynamic as Python. It supports `const`ness, and uses it by default for classes and functions.
  - dontlaugh 1y ago
    More importantly, there's nothing like locals[] or __getattribute__.
    - pjmlp 1y ago
      Smalltalk has them, and its JIT research eventually became Hotspot. Anything can change at any time in Smalltalk.
      - dontlaugh 1y ago
        Strongtalk limited dynamic features. But you’re not wrong in general. Even for Python there’s PyPy, with a JIT ~3x faster than CPython.
        pjmlp 1y ago
        Strongtalk was the transition step between Smalltalk JITs and what became Sun's Hotspot, but that wasn't the main point I was making. Also to note that even in that regard, Java happens to be more dynamic that people think, while the syntax is C++ like, the platform semantics are more akin to Smalltalk/Objective-C, hence why a JIT with such a background was a great addition.
      - hyperpape 1y ago
        There's a pretty big gap between "its JIT research eventually became Hotspot" and "Smalltalk can be made to perform on a par with Hotspot."
        pjmlp 1y ago
        HN comments usually aren't big enough for a CS lecture regarding evolution of dynamic compilation, aka JIT. There is enough stuff to fill at least one semester.
      - igouy 1y ago
        And then we find out that Smalltalk implementations might choose to optimize instead of allowing anything to change at any time. ifFalse: alternativeBlock "Answer the value of alternativeBlock. Execution does not actually reach here because the expression is compiled in-line." ^alternativeBlock value
        pjmlp 1y ago
        One tree doesn't make a forest, from whatever implementation that was taken out of, and naturally there are always magician tricks that PyPy also uses.
    - almostgotcaught 1y ago
      yes there is: https://wiki.python.org/moin/UsingSlots https://wiki.python.org/moin/UsingSlots people really don't know enough about this to be talking about it with such confidence...
      - dontlaugh 1y ago
        I was pointing examples of the opposite, that JavaScript is less dynamic than Python. There's lots of Python code out there that relies on not using slots. If you're making a JIT, you can't assume that all code is using slots.
jerf 1y ago
I was active in the Python community in the 200x timeframe, and I daresay the common consensus is that language didn't matter and a sufficiently smart compiler/JIT/whatever would eventually make dynamic scripting languages as fast as C, so there was no reason to learn static languages rather than just waiting for this to happen. It was not universal. But it was very common and at least plausibly a majority view, so this idea wasn't just some tiny minority view either. I consider this idea falsified now, pending someone actually coming up with a JIT/compiler/whatever that achieves this goal. We've poured millions upon millions of dollars into the task and the scripting languages still are not as fast as C or static languages in general. These millions were not wasted; there were real speedups worth having, even if they are somewhat hard on RAM. But they have clearly plateaued well below "C speed" and there is currently no realistic chance of that happening anytime soon. Some people still have not noticed that the idea has been falsified and I even occasionally run into someone who thinks Javascript actually is as fast as C in general usage. But it's not and it's not going to be.
- yxhuvud 1y ago
  While what you say is true, there is still a huge gap between the performance of javascript (and even Ruby) and that of Python. The efforts to optimize Python are lagging behind, so there is a lot of things that still can be made faster.
  - Sesse__ 1y ago
    Python is also choosing to play with one hand behind its back; e.g., the “no extension API changes” rule which means any hope of a faster value representation (one of the most important factors in making a dynamic language fast!) goes out the window, refusing to change the iterator API (which means that throwing and handling exceptions is something that needs to be handled by the fast path of basically everything), and so on.
    - pbronez 1y ago
      Those changes are big enough that they’d need to be a Python 4, don’t you think? Community is still gun why after the 2-3 transition pain.
manypineapples 1y ago
pypy manages
- pjmlp 1y ago
  The black swan of Python JITs, mostly ignored by the community, unfortunately.
- deleted 1y ago
  [deleted]
- eigenspace 1y ago
  Pypy is only "fast" relative to CPython. In all other metrics it's still very slow, and it comes at the cost of making interop with actually fast languages much harder and slower. It's basically useless.
pjmlp 1y ago
Especially when one keeps ignoring the JITs of dynamic languages, that were in the genesis of all high end production JITs being used nowadays, tracing back to Smalltalk, Self, Lisp, Prolog. All those languages are just as dynamic as Python, more so given the dynamically loading of code with image systems, across network, with break into debugger/condition points and redo workflows.
ngrilly 1y ago
Agreed. I'd like CPython to offer the possibility to opt in semantics that are more amenable to optimizations, similar to what Cider is enabling with their opt-in strict modules and static classes: https://github.com/facebookincubator/cinder https://github.com/facebookincubator/cinder.
pizlonator 1y ago
The semantics of Python-the-language aren’t any worse than JavaScript’s for optimization. Something else is going on.
- deleted 1y ago
  [deleted]

almostgotcaught 1y ago

> It turns out that if you have language semantics that make optimizations hard, making a fast optimizing compiler is hard. Who woulda thunk? Is this in the article? I don't see Python's semantics mentioned anywhere as a symptom (but I only skimmed). > shows how poorly a lot of people understand what goes into making a language fast. ...I'm sorry but are you sure you're not one of these people? Some facts: 1. JS is just as dynamic and spaghetti as Python and I hope we're all aware that it has some of the best jits out there; 2. Conversely, C++ has many "optimizing compiler[s]" and they're not all magically great by virtue of compiling a statically typed, rigid language like C++.

o11c 1y ago
JS is absolutely not as dynamic as Python. It supports `const`ness, and uses it by default for classes and functions.
- dontlaugh 1y ago
  More importantly, there's nothing like locals[] or __getattribute__.
  - pjmlp 1y ago
    Smalltalk has them, and its JIT research eventually became Hotspot. Anything can change at any time in Smalltalk.
    - dontlaugh 1y ago
      Strongtalk limited dynamic features. But you’re not wrong in general. Even for Python there’s PyPy, with a JIT ~3x faster than CPython.
      - pjmlp 1y ago
        Strongtalk was the transition step between Smalltalk JITs and what became Sun's Hotspot, but that wasn't the main point I was making. Also to note that even in that regard, Java happens to be more dynamic that people think, while the syntax is C++ like, the platform semantics are more akin to Smalltalk/Objective-C, hence why a JIT with such a background was a great addition.
    - hyperpape 1y ago
      There's a pretty big gap between "its JIT research eventually became Hotspot" and "Smalltalk can be made to perform on a par with Hotspot."
      - pjmlp 1y ago
        HN comments usually aren't big enough for a CS lecture regarding evolution of dynamic compilation, aka JIT. There is enough stuff to fill at least one semester.
    - igouy 1y ago
      And then we find out that Smalltalk implementations might choose to optimize instead of allowing anything to change at any time. ifFalse: alternativeBlock "Answer the value of alternativeBlock. Execution does not actually reach here because the expression is compiled in-line." ^alternativeBlock value
      - pjmlp 1y ago
        One tree doesn't make a forest, from whatever implementation that was taken out of, and naturally there are always magician tricks that PyPy also uses.
  - almostgotcaught 1y ago
    yes there is: https://wiki.python.org/moin/UsingSlots https://wiki.python.org/moin/UsingSlots people really don't know enough about this to be talking about it with such confidence...
    - dontlaugh 1y ago
      I was pointing examples of the opposite, that JavaScript is less dynamic than Python. There's lots of Python code out there that relies on not using slots. If you're making a JIT, you can't assume that all code is using slots.

jerf 1y ago

I was active in the Python community in the 200x timeframe, and I daresay the common consensus is that language didn't matter and a sufficiently smart compiler/JIT/whatever would eventually make dynamic scripting languages as fast as C, so there was no reason to learn static languages rather than just waiting for this to happen. It was not universal. But it was very common and at least plausibly a majority view, so this idea wasn't just some tiny minority view either. I consider this idea falsified now, pending someone actually coming up with a JIT/compiler/whatever that achieves this goal. We've poured millions upon millions of dollars into the task and the scripting languages still are not as fast as C or static languages in general. These millions were not wasted; there were real speedups worth having, even if they are somewhat hard on RAM. But they have clearly plateaued well below "C speed" and there is currently no realistic chance of that happening anytime soon. Some people still have not noticed that the idea has been falsified and I even occasionally run into someone who thinks Javascript actually is as fast as C in general usage. But it's not and it's not going to be.

yxhuvud 1y ago
While what you say is true, there is still a huge gap between the performance of javascript (and even Ruby) and that of Python. The efforts to optimize Python are lagging behind, so there is a lot of things that still can be made faster.
- Sesse__ 1y ago
  Python is also choosing to play with one hand behind its back; e.g., the “no extension API changes” rule which means any hope of a faster value representation (one of the most important factors in making a dynamic language fast!) goes out the window, refusing to change the iterator API (which means that throwing and handling exceptions is something that needs to be handled by the fast path of basically everything), and so on.
  - pbronez 1y ago
    Those changes are big enough that they’d need to be a Python 4, don’t you think? Community is still gun why after the 2-3 transition pain.

manypineapples 1y ago

pypy manages

pjmlp 1y ago
The black swan of Python JITs, mostly ignored by the community, unfortunately.
deleted 1y ago
[deleted]
eigenspace 1y ago
Pypy is only "fast" relative to CPython. In all other metrics it's still very slow, and it comes at the cost of making interop with actually fast languages much harder and slower. It's basically useless.

pjmlp 1y ago

Especially when one keeps ignoring the JITs of dynamic languages, that were in the genesis of all high end production JITs being used nowadays, tracing back to Smalltalk, Self, Lisp, Prolog. All those languages are just as dynamic as Python, more so given the dynamically loading of code with image systems, across network, with break into debugger/condition points and redo workflows.

ngrilly 1y ago

Agreed. I'd like CPython to offer the possibility to opt in semantics that are more amenable to optimizations, similar to what Cider is enabling with their opt-in strict modules and static classes: https://github.com/facebookincubator/cinder https://github.com/facebookincubator/cinder.

pizlonator 1y ago

The semantics of Python-the-language aren’t any worse than JavaScript’s for optimization. Something else is going on.

deleted 1y ago
[deleted]