I have quetion - slightly off topic, but related. I was wandering why is pyhton interpreter so much slower than V8 javascript interpreter when both javascript and python are dynamic interpreted languages.
keep in mind that, apart from the money throw at js runtime interpreters by google and others, there is also the fact that python - as a language - is way more "dynamic" than javascript. Even "simple" stuff like field access in python may refer to multiple dynamically-mapped method resolution. Also, the ffi-bindings of python, while offering a way to extend it with libraries written in c/c++/fortran/... , limit how f…
Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster
131–140 of 164 posts
Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster
#132Earlier quoted context omitted.
genuinely curious, doesn't JS's proxy objects and prototype-based MRO have a similar performance impact in theory?
Yeah, I don't see how Python is fundamentally different from JavaScript as far as dynamicism goes. Sure Python has operator overloading, but JavaScript would implement those as regular methods. Pyrhon's init & new aren't any more convoluted than JavaScript's constructors. Python may support multiple inheritance but method and attribute resolution just uses the MRO which is no different than JavaScript's prototype cha…
Most people that parrot repeat Python dynamism as root cause never used Smalltalk, Self or Common Lisp, or even PyPy for that matter.
Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster
#133I have quetion - slightly off topic, but related. I was wandering why is pyhton interpreter so much slower than V8 javascript interpreter when both javascript and python are dynamic interpreted languages.
Even though Javascript is quite dynamic, Python is much worse. Basically everything involves a runtime look-up. It's pretty much the language you'd design if you were trying to make it as slow as possible.
Which can change on the fly anything that is currently executing in the image.
Also after breaking into the debugger, the world can be totally different after resuming execution at the trap location.
Then there are nice primitives like a becomes: b. where all occurrences of a get swapped with b.
Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster
#134Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster
#135So…if the Python team finds tail calls useful, when are we going to see them in Python?
Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster
#136The money shot (wish this were included in the blog post): # if defined(_MSC_VER) && !defined(__clang__) # define Py_MUSTTAIL [[msvc::musttail]] # define Py_PRESERVE_NONE_CC __preserve_none # else # define Py_MUSTTAIL __attribute__((musttail)) # define Py_PRESERVE_NONE_CC __attribute__((preserve_none)) # endif https://github.com/python/cpython/pull/143068/files#diff-45b... Apparently(?) this also needs to be attached…
Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster
#137After years of admonition discouraging me, I’m using Python for a Windows GUI app over my usual C#/MAUI. I’m much more familiar with Python and the whole VS ecosystem is just so heavy for lightweight tasks. I started with tkinter but found it super clunky for interactions I needed heavily, like on field change, but learning QT seemed like more of a lift than I was interested in. (Maybe a skill issue on both fronts?)…
Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster
#138MSVC mostly generates slower code than gcc/clang, so maybe this trick reduces the gap.
Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster
#139https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster
#140Earlier quoted context omitted.
In the near future we will use lazy imports :) https://peps.python.org/pep-0810/
This can't come soon enough. Python is great for CLIs until you build something complex and a simple --help takes seconds. It's not something easily worked around without making your code very ugly.