The PR message with a riff off the Night Before Christmas is gold.
Python 3.13 Gets a JIT
291–300 of 553 posts
Re: Python 3.13 Gets a JIT
#292Earlier quoted context omitted.
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…
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 typed languages, functional languages, immutable data , system languages, type safe language, language with advanced parallelism and concurrency support etc ..
python is old , boring OOP, if you like it, than like millions of developers you are not picky about programming language, you use what works, what pays
but for devs passionate about programming languages, python is a relic they hope vanish
Re: Python 3.13 Gets a JIT
#293Earlier quoted context omitted.
Do a quick test with the latest JVM. Print Hello, world. That's it. Time it. Do the same with Python. The difference is minuscule. People don't build CLIs with them due to cultural reasons (fashion). Developers are creatures of fashion.
Printing hello world does not show the cost / benefit of a tracing jit that needs to be warmed up over thousands of iterations. And counter example: it takes maven 0.788s to realize I don't have a pom.xml in my PWD and fail a build. It takes meson 0.163s.
Maven versus Meson is purely about architecture, just look at Maven's design.
There is a reason I didn't say anything about that aspect of JITs that you mention, it's because it's not relevant to commands which are launched from shell scripts and then exit.
Re: Python 3.13 Gets a JIT
#294Earlier quoted context omitted.
That's true, and Rust compiler speed has seen similar speedups from lots of 1% improvements. But even if you can get a 2x improvement from lots of 1% improvements (if you work really really hard), you're never going to get a 10x improvement. Rust is never going to compile remotely as quickly as Go. Python is never going to be remotely as fast as Rust, C++, Go, Java, C#, Dart, etc.
Does it matter? Trains are never going to beat jets in pure speed. But in certain scenarios, trains make a lot more sense to use than jets, and in those scenarios, it is usually preferable having a 150 mph train to a 75 mph train. Looking at the world of railways, high-speed rail has attracted a lot more paying customers than legacy railways, even though it doesn't even try to achieve flight-like speeds. Same with pr…
What is the programming analogy here?
Two decades ago, you could (as e.g. Paul Graham did at the time) argue that dynamically typed languages can get your ideas to market faster so you become viable and figure out optimization later.
It's been a long time since that argument held. Almost every dynamic programming language still under active development is adding some form of gradual typing because the maintainability benefits alone are clearly recognized, though such languages still struggle to optimize well. Now there are several statically typed languages to choose from that get those maintainability benefits up-front and optimize very well.
Different languages can still be a better fit for different projects, e.g. Rust, Go, and Swift are all statically typed compiled languages better fit for different purposes, but in your analogy they're all jets designed for different tactical roles, none of them are "trains" of any speed.
Analogies about how different programming languages are like different vehicles or power tools or etc go way back and have their place, but they have to recognize that sometimes one design approach largely supersedes another for practical purposes. Maybe the analogy would be clearer comparing jets and trains which each have their place, to horse-drawn carriages which still exist but are virtually never chosen for their functional benefits.
Re: Python 3.13 Gets a JIT
#295"by Anthony Shaw, January 9, 2023"
2024, right?
Re: Python 3.13 Gets a JIT
#296Wasn't CPython supposed to remain very simple in its codebase, with the heavy optimization left for other implementations to tackle? I seem to remember hearing as much a few years back.
Does Python even have a language specification? I've been told that CPython IS the specification. I don't know if this is still true. In the Java world there is a specification and a set of tests to test for conformation so it's easier to have alternative implementations of the JVM. If what I said is correct, then I can see how the optimized alternative implementation idea is less likely to happen.
Re: Python 3.13 Gets a JIT
#297Earlier quoted context omitted.
> i think v8 works pretty hard to not use floats Correct, to the point where at work a colleague and I actually have looked into how to force using floats even if we initiate objects with a small-integer number (the idea being that ensuring our objects having the correct hidden class the first time might help the JIT, and avoids wasting time on integer-to-float promotion in tight loops). Via trial and error in Node w…
so then the remaining performance-critical case is where you have a big array of floats you're looping over. in firefox that works fine (one allocation per lowest-level array, not one allocation and unprefetchable pointer dereference per float), but maybe in chrome you'd want to use a typedarray?
As I understand it, V8 keeps track of an ElementsKind for each array (or, more precisely, for the elements of every object; arrays are not special in this sense). If an array only contains floats, then they will all be stored unboxed and inline. See here: https://source.chromium.org/chromium/chromium/src/+/main:v8/...
I assume that integers are coerced to floats in this mode, and that there's a performance cliff if you store a non-number in such an array, but in both cases I'm just guessing.
In SpiderMonkey, as you say, we store all our values as doubles, and disguise the non-float values as NaNs.
Re: Python 3.13 Gets a JIT
#298Earlier quoted context omitted.
Do a quick test with the latest JVM. Print Hello, world. That's it. Time it. Do the same with Python. The difference is minuscule. People don't build CLIs with them due to cultural reasons (fashion). Developers are creatures of fashion.
Printing hello world does not show the cost / benefit of a tracing jit that needs to be warmed up over thousands of iterations. And counter example: it takes maven 0.788s to realize I don't have a pom.xml in my PWD and fail a build. It takes meson 0.163s.
This is not the gotcha you think it is.
Re: Python 3.13 Gets a JIT
#299I love Python and use it for everything other than web development. One reason is performance. So if Python has a faster future ahead of it: Hurray! The other reason is that the Python ecosystem moved away from stateless requests like CGI or mod_php use and now is completely set on long running processes. Does this still mean you have to restart your local web application after any change you made to it? I heard that…
Python is amazing and shines for Web development. I'd recommend taking a look at https://www.tornadoweb.org/en/stable/index.html. I use this in production on my pet project at https://www.meecal.co/. Put Nginx in front and you're golden.
Definitely take a look, it's come a long way from ten years ago.
Re: Python 3.13 Gets a JIT
#300Earlier quoted context omitted.
There's a lot of Django going on in the world. shrug . If we're talking personal experience, I've been using Python since 1.4. It's been my primary development language since the late 1990s, with of course speed critical portions in C or C++ when needed - and I know a lot of people who also primarily develop in Python. And there's a bunch of Python development at CERN for tasks other than OS scripting. ("The ease of…
> There's a lot of Django going on in the world. Unfortunely. > And there's a bunch of Python development at CERN for tasks other than OS scripting Of course there is, CMT was a build tool, not OS scripting. No need to give me CERN links to me to show me Python bindings to ROOT, or Jupyter notebooks. > PyPy's experience shows we'll not be expecting a 5x boost any time soon from this new JIT framework, while C/C++/For…
The link wasn't for you - the link was for other HN users who might look at your mention of your use at CERN and mistakenly assume it was a more widespread viewpoint there.
> I really don't get the attitude that if it doesn't 100% fix all the world problems, then it isn't worth it.
Then it's a good thing I'm not making that argument, but rather that "Having a Python with JIT, in many cases it will be fast enough for most cases." has very little information content, because Python without a JIT already meets the consequent.