If python became fast, there's a chance it may become a language eater.
2-9% isn't changing any language hierarchies
Groundwork for the future.
Python 3.13 Gets a JIT
311–320 of 553 posts
Re: Python 3.13 Gets a JIT
#312Earlier quoted context omitted.
Disregarding the fact that python is an awful programming language for anthing other than jupyter notebooks
Ah I'd say the exact opposite, python in general is pretty good but jupyter sucks because the syntax isn't compatible with regular python and I avoid it like the plague.
What does a jupyter notebook have to do with python syntax?
Re: Python 3.13 Gets a JIT
#313How do you access optimizations such as dead code removal and constant propagation using this technique?
I believe a JIT using this technique could eliminate dead code at the Python bytecode level, but not at the machine code level. That seems pretty reasonable to me.
Re: Python 3.13 Gets a JIT
#314I 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…
Reminds me of David K who is local to me in Florida, or was, last I spoke to him. He has been a Finite State Machine advocate for ages, and its a well known concept, but you'd be surprised how useful they can be. He pushes it for front-end a lot, and even implemented a Tic Tac Toe sample using it.
Re: Python 3.13 Gets a JIT
#315The article describes that the new JIT is a "copy-and-patch JIT" (I've previously heard this called a "splat JIT"). This is a relatively simple JIT architecture where you have essentially pre-compiled blobs of machine code for each interpreter instruction that you patch immediate arguments into by copying over them. I once wrote an article about very simple JITs, and the first example in my article uses this style: h…
»LuaJIT is undoubtedly a "full" JIT compiler.« Yes, and it's practically unmaintained. Pull requests to add support for various architectures have remained largely unanswered, including RISC-V.
Doesn't change parent's point, clearly proves it's possible
Re: Python 3.13 Gets a JIT
#316Honestly I don't understand the pessimistic view here. I think every release since Microsoft started funding python has increased high single digit best case performance. Rather than focussing on the raw number compare to python 3.5 or so. It's still getting significantly faster. If they keep doing this steady pace they are slowly saving the planet!
I think the pessimism really comes from a dislike for Python While very very very popular, Python is i think is very disliked languages, it doesnt have or it is not built around the current programming language features that programmers like, its not functional or immutable by default, its not fast, the tooling is complex, it uses indentation for code blocks (this feature was cool in the 90s, but dreaded since at lea…
> (this feature was cool in the 90s, but dreaded since at least 2010)
LOL this is a dead giveaway you haven't been around long. There have been people kvetching about the whitespace since the beginning. Haskell went on to be the next big thing for reddit/HN/etc for years and it also uses whitespace.
Re: Python 3.13 Gets a JIT
#317If JIT is a good thing for Python, why don't just compile to Java or .NET bytecode and use their already optimized infrastructure?
Python is a convenient friendly syntax for calling code implemented in C. While you can easily re-implement the syntax, you then have to decide how much of that C to re-implement. A few of the builtin types are easy (eg strings and lists), but it soon becomes a mountain of code and interoperability, especially if you want to get the semantics exactly right. And that is just the beginning - a lot of the value of Python is in the extensions, and many popular ones (eg numpy, sqlite3) are implemented in C and need to interoperate with your re-implementation. Trying to bridge from Java or .NET to those extensions will overwhelm any performance advantages you got.
This JIT approach is improving the performance of bits of the interpreter while maintaining 100% compatibility with the rest of the C code base, its object model, and all the extensions.
Re: Python 3.13 Gets a JIT
#318Earlier quoted context omitted.
To each his own, but the things you list are largely subjective/inaccurate, and there are many, many, many developers who use Python because they enjoy it and like it a lot.
Python is a very widely used language, and like any popular thing, yes many many many like it , and many many many dislike it .. it is that big, python can be disliked by a million developer and still be a lot more liked than disliked but i also think that its true that python is not and have not been for a while considered as a modern or technically advanced language the hype currently is for typed or gradually type…
> the hype currently is for typed or gradually typed languages
So Python with mypy
Re: Python 3.13 Gets a JIT
#319Earlier quoted context omitted.
If you're interested in learning more about the challenges and tradeoffs, both Jython ( https://www.jython.org/ ) and IronPython ( https://ironpython.net/ ) have been around for a long time and there's a lot of reading material on that subject.
Graal Python exists too: https://www.graalvm.org/python/ It beats Python on performance, supposedly, but compatibility has never been great.
I've found the startup time for Graal Python to be terrible compared with other Graal languages like JS. When I did some profiling, it seemed that the vast majority of the time was spent loading the standard library. If implemented lazily, that should have a negligible performance impact.
Re: Python 3.13 Gets a JIT
#320The article describes that the new JIT is a "copy-and-patch JIT" (I've previously heard this called a "splat JIT"). This is a relatively simple JIT architecture where you have essentially pre-compiled blobs of machine code for each interpreter instruction that you patch immediate arguments into by copying over them. I once wrote an article about very simple JITs, and the first example in my article uses this style: h…
»LuaJIT is undoubtedly a "full" JIT compiler.« Yes, and it's practically unmaintained. Pull requests to add support for various architectures have remained largely unanswered, including RISC-V.
I think Mike Pall has done enough work on LuaJIT for several lifetimes. If nobody else wants to merge pull requests and make sure everything still works then maybe LuaJIT isn't important enough to the world.