401–410 of 553 posts
Is there an similarly accessible article about the specializing adaptive interpreter? It's mentioned in this article but not much detail is given, only that the JIT builds upon it.
I wonder if I can skip the bytecode compilation phase.
It's interesting to see these 2-9% improvements from version to version. They are always talked about with disappointment, as if they are too small, but they also keep coming, with each version being faster than the previous one. I prefer a steady 10% per version over breaking things because you are hoping for bigger numbers. Those percentages add up!
I spent about one week implementing PyPy's storage strategies in my language's collection types. When I finished the vector type modifications, I benchmarked it and saw the ~10% speed up claimed in the paper¹. The catch is performance increased only for unusually large vectors, like thousands of elements. Small vectors were actually slowed down by about the same amount. For some reason I decided to press on and implement it on my hash table type too which is used everywhere. That slowed the entire interpreter down by nearly 20%. The branch is still sitting there, unmerged.
I can't imagine how difficult it must have been for these guys to write a compiler and succeed at speeding up the Python interpreter.
¹ https://tratt.net/laurie/research/pubs/html/bolz_diekmann_tr...
I always wondered how Python can be one of the world's most popular languages without anyone (company) stepping up and make the runtime as fast as modern JavaScript runtimes.
Two reasons: 1. Javascript is a less dynamic language than Python and numbers are all float64 which makes it a lot easier to make fast. 2. If you want to run fast code on the web you only have one option: make Javascript faster. (Ok we have WASM now but that didn't exist at the time of the Javascript Speed wars.) If you want to run fast code on your desktop you have a MUCH easier option: don't use Python.
I have seen this mentioned multiple times, someone as a good reference explaining what makes python more dynamic than JS ?
Earlier quoted context omitted.
Someone please compare 3.13 to 2.3! I’d love to see how far we’ve come.
Good idea! It can be done fairly easily by people who are good with changelogs. FWIW, the most recent changelog is at https://docs.python.org/3.13/whatsnew/3.13.html
I think it's really cool that Haoran Xu and Fredrik Kjolstad's copy-and-patch technique[0] is catching on, I remember discovering it through Xu's blog posts about his LuaJIT remake project[1][2], where he intends to apply these techniques to Lua (and I probably found those through a post here). I was just blown away by how they "recycled" all these battle-tested techniques and technologies, and used it to synthesize…
Earlier quoted context omitted.
You're making this about Julia despite my repeated statements to the contrary. Please reread what I've written, you aren't responding to the actual point I've made twice now. A reminder: I'm talking specifically about my outlook on the future of Python, vis a vis my historical experience with how other JIT languages have developed. If you wanted to rebut this, you'd need to argue that Julia has always been awesome an…
> I'm talking specifically about my outlook on the future of Python, vis a vis my historical experience with how other JIT languages have developed. But your assessment of the other language you mentioned is several years out of date and made largely irrelevant by the fast pace of progress. Therefore your conclusions about the probable future of Python, which may be correct, nevertheless do not follow.
Earlier quoted context omitted.
I don't see this as an enhancement. Not pursuing JIT or efficient compilation in general was a deliberate decision way back when Python made some kind of sense. It was the simplicity of implementation valued over performance gains that motivated this decision. The mantra Python programmers liked to repeat was that "the performance is good enough, and if you want to go fast, write in C and make a native module". And i…
What are you talking about? From what I can read here there is no syntax change. Just a framework for faster execution. Plus, Python's usecase has HEAVILY evolved over the last few years since it's now the defacto language for machine learning. It's great that the core devs are keeping up with the time. The language is definitely getting more complex syntactically, and I'm not a huge fan of some of those changes but…
Read it again. It seems you were reading too fast. I'm talking about the future, not the change being discussed right now.
> It's great that the core devs are keeping up with the time.
You mistake the influence of Microsoft and their desire to sell features for progress. Python is actually regressing as a system. It's becoming worse, not better. But it's hard to see the gestalt of it if all you are looking for is the new features.
> it's no where near Java
That is true. Java is a much more simple and regular (not in the automata theory sense) language. Today, if you want a simpler language, you need to choose Java over Python (although neither is very simple, so, preferably, you need a third option).
> You can still write simple Python
I can also write simple C++ if I limit what I use from the language to a very small subset. This says nothing about the simplicity of the language...
Earlier quoted context omitted.
Having recently implemented parallel image rendering in corrscope ( https://github.com/corrscope/corrscope/pull/450 ), I can say that friends don't let friends write performance-critical code in Python. Depending on prebuilt C++ libraries hampers flexibility (eg. you can't customize the memory management or rasterization pipeline of matplotlib). Python's GIL inhibits parallelism within a process, and the workaround o…
> If you pre-open shared memory in a ProcessPoolExecutor's initializer functions, you can't close them when the worker process exits That's quite surprising to learn, as I didn't think the initializer ran in a specialized context (like a pthread_atfork postfork hook in the child). What happens when you try to close an initializer-allocated SharedMemory object on worker exit?
Unfortunate to see a couple of comments here drive-by pulling out the “x% faster” stat whilst minimising the context. This is a big deal and it’s effectively a given that this’ll pave the way for further enhancements.
It is a very big deal, as it will finally shift the mentality regarding: - "C/C++/Fortran libs are Python" - "Python is too dynamic", while disregarding Smalltalk, Common Lisp, Dylan, SELF, NewtonScript JIT capabilities, all dynamic languages where anything can change at any given moment
In Common Lisp not anything can change at any moment. Especially not in implementations where one uses AOT compilation like SBCL, ECL, LispWorks, Allegro CL, ... and so on. They have optimizing compilers which gradually can remove dynamic runtime behavior, upto supporting almost no dynamic runtime behavior.
Stuff which is supported: type specific code, inlining, block compilation, removal of development tools, ...
JIT implementations are rare in the Common Lisp world. They are mostly only used in implementations which use a byte-code virtual machine (CLISP, ABCL, ...). Common Lisp implementations mostly compile either directly to native code or via C compilers. The effect is that native AOT compiled code is much faster.
Earlier quoted context omitted.
[flagged]
Microsoft already tried Python on the CLR! They didn't stick with it. https://en.wikipedia.org/wiki/IronPython
It was a different time. Microsoft had a different strategy towards languages not developed by Microsoft. Similar to how there also used to be JScript, but now Node.js is basically a Microsoft's pet project.
There are actually plenty of popular Microsoft's projects that took even more than two tries. Azure is like their third attempt at cloud services, iirc. Credit where credit is due, they learn from mistakes... unfortunately, that only makes them more insidious.