7 ms·
I'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 Pyt
by ModernMech 1y ago
I'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 the world. But it's interesting to me seeing Python getting adopted for a purpose it wasn't suited for (high performance AI computing). Given how slow it is, people seem to think there's a lot of room for performance improvements. Take this line for instance:
> The free-threading interpreter disables the global interpreter lock (GIL), a change that promises to unlock great speed gains in multi-threaded applications.
No, not really. I mean, yeah you might get some speed gains, but the chart shows us if you want "great" speed gains you have two options: 1) JIT compile which gets you an order of magnitude faster or 2) switch to a static compiled language which gets you two orders of magnitude faster.
But there doesn't seem to be a world where they can tinker with the GIL or optimize python such that you'll approach JIT or compiled perf. If perf is a top priority, Python is not the language for you. And this is important because if they change Python to be a language that's faster to execute, they'll probably have to shift it away from what people like about it -- that it's a dynamic, interpreted language good for prototyping and gluing systems together.
- huflungdung 1y ago[dead]
- IshKebab 1y agoI agree. Unless they make it like 10x faster it doesn't really change anything. It's still a language you only use if you absolutely don't care whatsoever about performance and can guarantee that you never will.
- nodesocket 1y agoIf you’re actually building and shipping software as a business Python is great. The advantages of Python for a startup are many. Large pool of talent that can pickup the codebase on essentially day 1. Fairly easy to reason about, mature, code velocity, typically one and only one way to do things as opposed to JavaScript. There is way more to the story than raw performance.
- OutOfHere 1y agoIt's not that great when you see that the majority of the Python code in businesses is a totally unmaintainable mess because it has incorrect, partial, or no type annotations, and is littered with serious errors that a most basic type checker would flag.
- IshKebab 1y ago> The advantages of Python for a startup are many. Large pool of talent that can pickup the codebase on essentially day 1. Large pool of mediocre Python developers that can barely string a function together in my experience.
- svara 1y agoThe 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.
- bowsamic 1y ago> 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
- IshKebab 1y agoI agree - Jupyter notebook is really the key feature Python has that makes it attractive for research/scientific computing. I would say the REPL too but until very recently it was extremely shoddy so I doubt many people did any serious work in it.
- pdonis 1y ago> I would say the REPL too but until very recently it was extremely shoddy Can you elaborate? I've been using the Python REPL for more than two decades now, and I've never found it to be "shoddy". Indeed, in pretty much every Python project I work on, one of the first features I add for development is a standard way to load a REPL with all of the objects that the code works with set up properly, so I can inspect them.
- IshKebab 1y agoVery obvious example - you can't paste code containing blank lines. Another example: navigating this history is done line by line instead of using whole inputs. It's just bare minimum effort - probably gnu readline piped directly into the interpreter or something. I think they did improve it a lot very recently by importing the REPL from some other Python interpreter but I haven't upgraded to use that version yet so I don't know how good it is now.
- bowsamic 1y agoWell, that's not true at all. Scientists care about performance, but it turns out that Python is really good for number crunching since it is really good for using very fast C libraries. I know people who use pandas to manipulate huge datasets from radar astronomy. Also, of course, it's used in machine learning. If Python was "only" used in situations where you don't care about performance, it would not be used in so many scenarios that definitely need high performance. Sure, it is not pure Python, but it's still Python being used, just used to orchestrate C libraries
- shcheklein 1y agoProbably 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.
- IshKebab 1y agoI 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.
- pjmlp 1y ago1980'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.
- shcheklein 1y agoYep, exactly, It takes time to close the gap so that more and more teams taking that tradeoff
- theLiminator 1y ago> 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.
- mixmastamyk 1y agoObtuse statement. There are many ways of speeding up a python project if requirements change.
- IshKebab 1y agoA painful rewrite in another language is usually the only option in my experience. If you're really lucky you have a small hot part of the code and can move just that to another language (a la Pandas, Pytorch, etc.). But that's usually only the case for numerical computing. Most Python code has its slowness distributed over the entire codebase.
- mixmastamyk 1y agoIt’s not painful, that’s the point. You have a working prototype now ready to port. (If the destination language is painful perhaps, but don’t do that.) I recently ported a Python program to Rust and it took me much less time the second time, even though I write Rust more slowly per-line. Because I knew definitively what the program needed. And if even that is too much optimizing the Python or adding Cython to a few hot loops is less difficult.
- IshKebab 1y agoI have also ported a Python program to Rust (got a ~50x speedup) but this was a smallish program, under 10k lines of code. Porting larger programs is rarely tractable. You can tell that because several large companies have decided that writing their own Python runtimes that are faster is less effort (although they all eventually gave up on that as far as I know).
- mixmastamyk 1y agoCould happen with any language. The well-known Spolsky piece was about a C++ to C++ rewrite if memory serves. Blaming repeated poor decisions on a prototyping/glue language is yet another instance. Luckily there's lots of options today to dig out of them.
- analog31 1y ago>>> you absolutely don't care whatsoever about performance and can guarantee that you never will. Those are actually pretty good bets, better than most other technological and business assumptions made during projects. After all, a high percentage of projects, perhaps 95%, are either short term or fail outright. And in my own case, anything I write that is in the 5% is certain to be rewritten from scratch by the coding team, in their preferred language.
- IshKebab 1y agoSure but you're still screwing yourself over on that 5% and for no real reason - there are plenty of languages that are just as good as Python (or better!) but aren't as hilariously slow. And in my experience rewrites are astonishingly rare. That's why Dropbox uses Python and Facebook uses PHP.
- morshu9001 1y agoPeople use Python for things where performance matters, and it's fine
- kstrauser 1y agoI'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 back out for 3 seconds. You could rewrite that in Rust and it wouldn't be any faster. In fact, a huge chunk of the common CPU-expensive stuff is already a thin wrapper around C or Rust, etc. Yeah, it'd be really cool if Python itself were faster. I'd enjoy that! It'd be nice to unlock even more things that were practical to run directly in Python code instead of swapping in a native code backend to do the heavy lifting! And yet, in practice, its speed has almost never been an issue for me or my employers. BTW, I usually do the Advent of Code in Python. Sometimes I've rewritten my solution in Rust or whatever just for comparison's sake. In almost all cases, choice of algorithm is vastly more important than choice of language, where you might have: * Naive Python algorithm: 43 quadrillion years * Optimal Python algorithm: 8 seconds * Rust equivalent: 2 seconds Faster's better, but the code pattern is a lot more important than the specific implementation.
- ModernMech 1y agoExactly, most Python devs neither need nor care about perf. Most applications don't even need perf, because whether it's .1 second or .001 seconds, the user is not going to notice. But this current quest to make Python faster is precisely because the sluggishness is noticeable for the task it's being used for most at the moment. That 6 second difference you note between the Optimal Python and the optimal Rust is money on the table if it translates to higher hardware requirements or more server time. When everything is optimal and you could still be 4x faster, that's a tough pill to swallow if it means spending more $$$.
- OutOfHere 1y ago> most Python devs neither need nor care about perf. You do understand that's a different but equivalent way of saying, "If you care about performance, then Python is not the language for you.", don't you?
- famouswaffles 1y agoIt's pretty simple. Nobody wants to do ML R&D in C++. Tensorflow is a C++ library with python bindings. Pytorch has supported a C++ interface for some time now, yet virtually nobody uses C++ for ML R&D. The relationship between Python and C/C++ is the inverse of the usual backend/wrapper cases. C++ is the replaceable part of the equation. It's a means to an end. It's just there because python isn't fast enough. Nobody would really care if some other high perf language took its place. Speed is important, but C++ is even less suited for ML R&D.
- whatever1 1y agoI think readability is what made python a winner. I can quickly type down my idea like a pseudo code, I can easily skim through other people’s algos. In C++ even a simple algo with a 100 lines of pseudo code will balloon to thousands of lines in c++