4 ms·

This is a great read, and it's fantastic to see all the work being done to evaluate and improve the language! The dynamic-nature of the language is actually so

This is a great read, and it's fantastic to see all the work being done to evaluate and improve the language! The dynamic-nature of the language is actually something that I had studied a few years back [1]. Particularly the variable and object attribute look ups! My work was just a master's thesis, so we didn't go too deep into more tricky dynamic aspects of the language (e.g. eval, which we restricted entirely). But we did see performance improvements by restricting the language in certain ways that aid in static analysis, which allowed for more performant runtime code. But for those interested, the abstract of my thesis [2] gives more insight into what we were evaluating. Our results showed that restricting dynamic code (code that is constructed at run time from other source code) and dynamic objects (mutation of the structure of classes and objects at run time) significantly improved the performance of our benchmarks. There was also some great discussion on HN when I had posted our findings as well [3]. [1]: https://github.com/joncatanio/cannoli https://github.com/joncatanio/cannoli [2]: https://digitalcommons.calpoly.edu/theses/1886/ https://digitalcommons.calpoly.edu/theses/1886/ [3]: https://news.ycombinator.com/item?id=17093051 https://news.ycombinator.com/item?id=17093051

Animats 4y ago
But we did see performance improvements by restricting the language in certain ways that aid in static analysis, which allowed for more performant runtime code. Well, yes. In Python, one thread can monkey-patch the code in another thread while running. That feature is seldom used. In CPython, the data structures are optimized for that. Underneath, everything is a dict. This kills most potential optimizations, or even hard-code generation. It's possible to deal with that efficiently. PyPy has a compiler, an interpreter, and something called the "backup interpreter", which apparently kicks in when the program being run starts doing weird stuff that requires doing everything in dynamic mode. I proposed adding "freezing", immutable creation, to Python in 2010, as a way to make threads work without a global lock.[1] Guido didn't like it. Threads in Python still don't do much for performance. [1] http://www.animats.com/papers/languages/pythonconcurrency.html http://www.animats.com/papers/languages/pythonconcurrency.ht...
- chrisseaton 4y ago
  > This kills most potential optimizations, or even hard-code generation. It doesn’t - this has been a basically solved problem since Self and deoptimisation were invented.
  - Animats 4y ago
    In theory, yes. In CPython, apparently not. In PyPy, yes.[1] PyPy has to do a lot of extra work to permit some unlikely events. [1] https://carolchen.me/blog/jits-impls/ https://carolchen.me/blog/jits-impls/
    - deleted 4y ago
      [deleted]
    - chrisseaton 4y ago
      You’re trying to correct me by posting my own mentee’s blog post at me.

Animats 4y ago

But we did see performance improvements by restricting the language in certain ways that aid in static analysis, which allowed for more performant runtime code. Well, yes. In Python, one thread can monkey-patch the code in another thread while running. That feature is seldom used. In CPython, the data structures are optimized for that. Underneath, everything is a dict. This kills most potential optimizations, or even hard-code generation. It's possible to deal with that efficiently. PyPy has a compiler, an interpreter, and something called the "backup interpreter", which apparently kicks in when the program being run starts doing weird stuff that requires doing everything in dynamic mode. I proposed adding "freezing", immutable creation, to Python in 2010, as a way to make threads work without a global lock.[1] Guido didn't like it. Threads in Python still don't do much for performance. [1] http://www.animats.com/papers/languages/pythonconcurrency.html http://www.animats.com/papers/languages/pythonconcurrency.ht...

chrisseaton 4y ago
> This kills most potential optimizations, or even hard-code generation. It doesn’t - this has been a basically solved problem since Self and deoptimisation were invented.
- Animats 4y ago
  In theory, yes. In CPython, apparently not. In PyPy, yes.[1] PyPy has to do a lot of extra work to permit some unlikely events. [1] https://carolchen.me/blog/jits-impls/ https://carolchen.me/blog/jits-impls/
  - deleted 4y ago
    [deleted]
  - chrisseaton 4y ago
    You’re trying to correct me by posting my own mentee’s blog post at me.