News for hackers. Stuff that matters.
Re:Faster CPython (2021) [pdf] by kmod on Sunday January 23, 2022 @02:20PM (#30049410)
Yes, definitely. Python is much much more dynamic than Javascript -- the jump in dynamicness of Javascript to Python is about equivalent to Java to Javascript, and similarly requires a different set of techniques.

The single example I typically give is that in Python you can inspect stack frames after they've exited! This has concrete implications on your VM design.

Another example is that the multiple dispatch protocol for binary operations (such as addition) is sufficiently complicated that you generally cannot encode it into your compiler. We have been able to have a simplified version of that by building a tracing JIT for C, which is able to understand the dispatch protocol, but it is not always applicable.

Source: I've been working on Python optimization for several years as part of the Pyston project.

Re:Faster CPython (2021) [pdf] by iqanq on Sunday January 23, 2022 @03:28PM (#30050129)
>The single example I typically give is that in Python you can inspect stack frames after they've exited! This has concrete implications on your VM design.

How about an implementation of python that doesn't let you do fancy things like that that are not needed in production?

Re:Faster CPython (2021) [pdf] by Jasper_ on Sunday January 23, 2022 @03:51PM (#30050324)
The inspecting of stack frames is used by the logging library, and by most unit testing libraries. There are dozens of these small features which are challenging, and if you remove all of the challenging ones, you end up with something where pretty much no existing Python can run.

People have tried, pypy started with that goal before it became clear it wasn't practical.

Re:Faster CPython (2021) [pdf] by akx on Sunday January 23, 2022 @05:55PM (#30051441)
I think logging inspects frames while they're still on the stack, not post-fact..?
Re:Faster CPython (2021) [pdf] by kaba0 on Monday January 24, 2022 @03:25AM (#30054837)
Do you happen to know something about the graal python implementation? Based on other comments here, the often used C FFI can also hinder the work of Python implementations, and the graal project solves it by JIT compiling C code as well (from llvm ir)

From what I’ve seen last time I heard about graal python is that it is seldom faster than the pypy approach (AST-based vs tracing JIT), even though in case of TruffleRuby and TruffleJS it is insanely fast compared to the maturity of the projects.

Is your mentioned example of stack frame inspection make it map much worse to Java primitives (which happens behind the scenes of the truffle languages)?

Re:Faster CPython (2021) [pdf] by frozenport on Sunday January 23, 2022 @05:36PM (#30051260)
>> in Python you can inspect stack frames after they've exited!

How does that work and what is it used for?

Re:Faster CPython (2021) [pdf] by ravi-delia on Sunday January 23, 2022 @04:13PM (#30050489)
Is there any reason that Python's dynamicness (dynamicity?) is so much more of a hindrance than CL's? Is it just that CL is compiled?
Re:Faster CPython (2021) [pdf] by robert-brown on Sunday January 23, 2022 @08:01PM (#30052387)
The end of this post explains why Common Lisp can run much faster than Python.

https://markmail.org/message/dp56i26zhpf4fehb#query:+page:1+...

Re:Faster CPython (2021) [pdf] by pjmlp on Sunday January 23, 2022 @04:11PM (#30050480)
Not more dynamic than Smalltalk or SELF, though.
Re:Faster CPython (2021) [pdf] by igouy on Sunday January 23, 2022 @09:43PM (#30053111)
Please share the well understood criteria for "dynamic" in this context, that would let us order different programming languages as more dynamic or less dynamic.
Re:Faster CPython (2021) [pdf] by KerrAvon on Sunday January 23, 2022 @11:29PM (#30053759)
Search the web for Ruby or Smalltalk or Objective-C “object model” or “message dispatch”
Re:Faster CPython (2021) [pdf] by igouy on Monday January 24, 2022 @11:32AM (#30059881)
Please share your criteria for "dynamic", that would let us order different programming languages as more dynamic or less dynamic.
Re:Faster CPython (2021) [pdf] by fault1 on Sunday January 23, 2022 @04:29PM (#30050609)
Or dylan or julia
Re:Faster CPython (2021) [pdf] by anticensor on Sunday January 23, 2022 @03:04PM (#30049923)
Unlike JavaScript however, Python is strongly typed.
Re:Faster CPython (2021) [pdf] by Spivak on Sunday January 23, 2022 @05:39PM (#30051286)
Yeah but in practice basically all JS code in the wild is strongly typed since the community has long since decided that relying on implicit type coercion is a massive footgun.

Also I think Python’s truthy/falsey semantics make it dangerously close to being weakly typed.

Re:Faster CPython (2021) [pdf] by staticassertion on Sunday January 23, 2022 @09:36PM (#30053050)
All that means is that you get more exceptions raised when you use ==. It doesn't help performance at all, it doesn't even really confer anything about types, only that __eq__ is implemented between fewer types.
Re:Faster CPython (2021) [pdf] by anticensor on Saturday February 05, 2022 @10:38AM (#30222101)
Python exceptions are low-cost. It has to be that way because every for loop in Python throws an exception.
Re:Faster CPython (2021) [pdf] by IshKebab on Sunday January 23, 2022 @05:33PM (#30051236)
Python's type system is not more strongly typed than JavaScript's in any way that makes it easier to optimise.