Pithon, haha
Or Pijthon in Dutch.
Not Pijthon?
Python 3.14 is here. How fast is it?
41–50 of 579 posts
Re: Python 3.14 is here. How fast is it?
#42tl;dr: Two orders of magnitude slower than Rust, so 2-3 orders slower than native. Python on a 2 GHz processor runs as fast as C on a 2-20 MHz processor.
Re: Python 3.14 is here. How fast is it?
#43I would tell you a joke about python but it would take you a long time to get it.
You can tell me a joke about Python, but I'll need someone to interpret it.
Re: Python 3.14 is here. How fast is it?
#44I'm thankful they included a compiled language for comparison, because most of the time when I see Python benchmarks, they measure against other versions of Python. But "fast python" is an oxymoron and 3.14 doesn't seem to really change that, which I feel most people expected given the language hasn't fundamentally changed. This isn't a bad thing; I don't think Python has to be or should be the fastest language in th…
I've been writing Python professionally for a couple of decades, and there've only been 2-3 times where its performance actually mattered. When writing a Flask API, the timing usually looks like: process the request for .1ms, make a DB call for 300ms, generate a response for .1ms. Or writing some data science stuff, it might be like: load data from disk or network for 6 seconds, run Numpy on it for 3 hours, write it…
LOL, python is plenty fast if you make sure it calls C or Rust behind the scenes. Typical of 'professional' python people. Something too slow? just drop into C. It surely sounds weird to everyone who complains about Python being slow and the response is on these lines.
Re: Python 3.14 is here. How fast is it?
#45Earlier quoted context omitted.
The counterargument used to be, the heavy lifting will be offloaded to python modules written in C, like numpy. Which was true, but maybe not the strongest argument. Why not use a faster language in the first place? But it's different now. There's huge classes of problems where pytorch, jax &co. are the only options that don't suck. Good luck competing with python code that uses them on performance.
> Why not use a faster language in the first place? Well for the obvious reason that there isn't really anything like a Jupyter notebook for C. I can interactively manipulate and display huge datasets in Python, and without having to buy a Matlab license. That's why Python took off in this area, really
I believe I heard that argument since before jupyter became popular.
Usually it was accompanied by saying that the time needed to write code is often more important than the time it takes to run, which is also often true.
All that said, jupyter is probably part of python's success, although I'm not the only one who actively avoids it and views it as a bit of a code smell.
Re: Python 3.14 is here. How fast is it?
#46Earlier quoted context omitted.
I doubt it. C is well within 2x of what you can achieve with hand written assembly in almost every case. Furthermore writing large programs in pure assembly is not really feasible, but writing large programs in C++, Go, Rust, Java, C#, Typescript, etc. is totally feasible.
1980's and 1990's game development says hi. C compilers weren't up to stuff, that is why books like those from Michael Abrash do exist.
Yep, exactly, It takes time to close the gap so that more and more teams taking that tradeoff
Re: Python 3.14 is here. How fast is it?
#47> And this is a bit disappointing. At least for this test, the JIT interpreter did not produce any significant performance gains, so much that I had to double and triple check that I used a correctly built interpreter with this feature enabled. I do not know much about the internals of the new JIT compiler, but I'm wondering if it cannot deal with this heavily recursive function.
FWIW one thing that is worth calling out here is that the initial goal for JIT right now in Python is getting it relatively stable, functional, and more or less getting the initial implementation out there. It's not surprising at all that it's not faster.
I say this because I think the teams working on free-threaded and JIT python maybe could have done a better job publicly setting expectations.
Re: Python 3.14 is here. How fast is it?
#48Earlier quoted context omitted.
Probably people at some point were making same arguments about ASM and C. How many people though do ASM these days? Not arguing that for now it is relevant point, obviously Rust / C are way faster.
I doubt it. C is well within 2x of what you can achieve with hand written assembly in almost every case. Furthermore writing large programs in pure assembly is not really feasible, but writing large programs in C++, Go, Rust, Java, C#, Typescript, etc. is totally feasible.
> I doubt it. C is well within 2x of what you can achieve with hand written assembly in almost every case.
Depends what you mean, if you preclude using targeted ASM in your C I think some hot loops can be much slower than 2x.
Of course programs globally written in assembly largely don't make sense.
Re: Python 3.14 is here. How fast is it?
#49tl;dr: Two orders of magnitude slower than Rust, so 2-3 orders slower than native. Python on a 2 GHz processor runs as fast as C on a 2-20 MHz processor.
*for very specific benchmarks, not "on average"
Re: Python 3.14 is here. How fast is it?
#50Earlier quoted context omitted.
I've been writing Python professionally for a couple of decades, and there've only been 2-3 times where its performance actually mattered. When writing a Flask API, the timing usually looks like: process the request for .1ms, make a DB call for 300ms, generate a response for .1ms. Or writing some data science stuff, it might be like: load data from disk or network for 6 seconds, run Numpy on it for 3 hours, write it…
LOL, python is plenty fast if you make sure it calls C or Rust behind the scenes. Typical of 'professional' python people. Something too slow? just drop into C. It surely sounds weird to everyone who complains about Python being slow and the response is on these lines.
But that’s the whole point of it. You have the option to get that speed when it really matters, but can use the easier dynamic features for the very, very many use cases where that’s appropriate.
This is an eternal conversation. Years ago, it was assembler programmers laughing at inefficient C code, and C programmers replying that sometimes they don’t need that level of speed and control.