3 ms·

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

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 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 ago
Exactly, 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?
  - ModernMech 1y ago
    Yes, I'm consistent in that. What I don't get is if that's the case, why is there such a focus on improving Python perf? At best they're getting marginal improvements on something that most Python devs claim they don't care about, and which they say is not important for Python as a language due to JIT, C interop, and so on.
    - OutOfHere 1y ago
      I think perhaps their hope is that eventually Python can get to Go-level if not Rust-level performance if they keep up the optimizations. I do personally believe this to be possible. The motivating example is Julia, which is a high level language with low-level language's performance. After arriving there, developers will care.
      - ModernMech 1y ago
        I agree, I think that's probably the hope. It's interesting you bring up Julia here because I was just reading the post about the 1.12 release and this comment struck me: https://news.ycombinator.com/item?id=45524485 https://news.ycombinator.com/item?id=45524485 Particularly this part is relevent to the Python discussion: What is Julia's central conceit? It aims to solve "the two language" problem, i.e. the problem where prototyping or rapid development is done in a dynamic and interactive language like Python or MATLAB, and then moved for production to a faster and less flexible language like Rust or C++. This is exactly what the speaker in the talk addresses. They are still using Julia for prototyping, but their production use of Julia was replaced with Rust. I've heard several more anecdotal stories of the exact same thing occurring. Here's another high profile instance of Julia not making it to production: https://discourse.julialang.org/t/julia-used-to-prototype-wh... Julia is failing at its core conceit. So that's the question I have right now: what is Python supposed to be? Is it supposed to be the glue language that is easy to use and bind together a system made from other languages? Or is it trying to be what Julia is, a solution to the two language problem. Because it's not clear Julia itself has actually solved that. The reason I bring this up is because there's a lot of "cake having/eating" floating around these types of conversations -- that's it's possible to be all the things, without a healthy discussion of what the tradeoffs are in going that direction, and what that would me mean for the people who are happy with the way things are. These little % gains are all Python is going to achieve without actually asking the developer to sacrifice their development process in some way.
the__alchemist 1y ago
That's because you're doing web stuff. (I/O limited). So much of our computing experience has been degraded due to this mindset applied more broadly. Despite a steady improvement in hardware, my computing experiences have been stagnating and degraded in terms of latency, responsiveness etc. I'm not going to even go into the comp chem simulations I've been running, or that about 1/3 the stuff I do is embedded. I do still use python for web dev, partly because as you say, it's not CPU-bound, and partly because Python's Django framework is amazing. But I have switched to rust for everything else.
- kstrauser 1y ago
  I won’t completely argue against that, and I’ve also adopted Rust for smaller or faster work. Still, I contend that a freaking enormous portion of computing workloads are IO bound to the point that even Python’s speed is Good Enough in an Amdahl’s Law kind of way.
  - lenerdenator 1y ago
    It's been said that Python's greatest superpower is that it's the second-best language at the most stuff. No one's really developed an ecosystem for a language that's more performant that can match it, and that's all it needs to assert dominance.
    - azkalam 1y ago
      I've never understood this. Python cannot be optimized like C, C++ or Rust. It cannot do advanced functional things like OCaml, Haskell or Scala. It cannot run in browsers like TypeScript. It cannot do games programming like C# and it can't do crazy macro stuff like Clojure. I don't think it's even second best at those things.
      - lenerdenator 1y ago
        I'm reading this as, "It cannot do things the best", and that's correct. It can't. But it can do them well enough, and enough people know it that they can drag a solution across the line in most domains.
cyberax 1y ago
And my experience is this: you start using ORMs, and maybe you need to format a large table once in a while. Then your Python just dies. Bonus points if you're using async to service multiple clients with the same interpreter. And you're now forced to spend time hunting down places for micro-optimizations. Or worse, you end up with a weird mix of Cython and Python that can only be compiled on the developer's machine.
- deleted 1y ago
  [deleted]
npalli 1y ago
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.
- kstrauser 1y ago
  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.
  - tredre3 1y ago
    You are correct. However it took about only about 10 years for C compilers to beat hand assembly (for the average programmer), thus proving the naysayers wrong. Meanwhile Python is just as slow today as it was 30 years ago (on the same machine).
- bee_rider 1y ago
  Even as a Fortran programmer, the majority of my flops come from BLAS, LAPACK, and those sort of libraries… putting me in the exact same boat as the Python programmers, really. The “professional” programmers in general don’t worry too much about tying their identities to language choices, I think.
- Karrot_Kream 1y ago
  This is a very common pattern in high level languages and has been a thing ever since Perl had first come onto the scene. The whole point was that you use more ergonomic, easier to iterate languages like Perl or Python for most of your logic and you drop down into C, C++, Zig, or Rust to write the performance sensitive portions of your code. When compiled languages became popular again in the 2010s there was a renewed effort into ergonomic compiled languages to buck this trend (Scala, Kotlin, Go, Rust, and Zig all gained their popularity in this timeframe) but there's still a lot of code written with the two language pattern.
lozenge 1y ago
Advent of code is deliberately set up to be doable in Python. You can also imagine a useful problem which Rust takes 2 weeks to do, how long would it take in Python?
varjag 1y ago
Sure then you get a developer who decides to go with Flask for an embedded product and it's an eye watering slog.
- kstrauser 1y ago
  People will always make bad decisions. For example, I'd also squint at a developer who wanted to write a new non-performance-critical network service in C. Or a performance-critical one, for that matter, unless there was some overwhelming reason they couldn't use Rust or even C++.
ncruces 1y ago
> 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. I was asked to rewrite some NumPy image processing in C++, because NumPy worked fine for 1024px test images but balked when given 40 Mpx photos. I cut the runtime by an order of magnitude for those large images, even before I added a bit of SIMD (just to handle one RGBX-float pixel at a time, nothing even remotely fancy). The “NumPy has uber fast kernels that you can't beat” mentality leads people to use algorithms that do N passes over N intermediate buffers, that can all easily be replaced by a single C/C++/Rust (even Go!) loop over pixels. Also reinforced by “you can never loop over pixels in Python - that's horribly slow!”
- rowanG077 1y ago
  Same with opencv and even sometimes optimized matrix libraries in pure C++. These are all highly optimized. But often when you want to achieve something you have to chain stuff which quickly eats up a lot of cycles, just by copying stuff around and having multiple passes that the compiler is unable to fuse. You can often pretty easily beat that even if you are not an optimization god by manual loop fusion.
- physicsguy 1y ago
  Fused expressions are possible using other libraries (numexpr is pretty good), but I agree that there's a reluctance to use things outside of NumPy. Personally though I find it easier to just drop into C extensions at the point that NumPy becomes a limiting factor. They're so easy to do and it lets me keep the Python usability.

ModernMech 1y ago

Exactly, 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?
- ModernMech 1y ago
  Yes, I'm consistent in that. What I don't get is if that's the case, why is there such a focus on improving Python perf? At best they're getting marginal improvements on something that most Python devs claim they don't care about, and which they say is not important for Python as a language due to JIT, C interop, and so on.
  - OutOfHere 1y ago
    I think perhaps their hope is that eventually Python can get to Go-level if not Rust-level performance if they keep up the optimizations. I do personally believe this to be possible. The motivating example is Julia, which is a high level language with low-level language's performance. After arriving there, developers will care.
    - ModernMech 1y ago
      I agree, I think that's probably the hope. It's interesting you bring up Julia here because I was just reading the post about the 1.12 release and this comment struck me: https://news.ycombinator.com/item?id=45524485 https://news.ycombinator.com/item?id=45524485 Particularly this part is relevent to the Python discussion: What is Julia's central conceit? It aims to solve "the two language" problem, i.e. the problem where prototyping or rapid development is done in a dynamic and interactive language like Python or MATLAB, and then moved for production to a faster and less flexible language like Rust or C++. This is exactly what the speaker in the talk addresses. They are still using Julia for prototyping, but their production use of Julia was replaced with Rust. I've heard several more anecdotal stories of the exact same thing occurring. Here's another high profile instance of Julia not making it to production: https://discourse.julialang.org/t/julia-used-to-prototype-wh... Julia is failing at its core conceit. So that's the question I have right now: what is Python supposed to be? Is it supposed to be the glue language that is easy to use and bind together a system made from other languages? Or is it trying to be what Julia is, a solution to the two language problem. Because it's not clear Julia itself has actually solved that. The reason I bring this up is because there's a lot of "cake having/eating" floating around these types of conversations -- that's it's possible to be all the things, without a healthy discussion of what the tradeoffs are in going that direction, and what that would me mean for the people who are happy with the way things are. These little % gains are all Python is going to achieve without actually asking the developer to sacrifice their development process in some way.

the__alchemist 1y ago

That's because you're doing web stuff. (I/O limited). So much of our computing experience has been degraded due to this mindset applied more broadly. Despite a steady improvement in hardware, my computing experiences have been stagnating and degraded in terms of latency, responsiveness etc. I'm not going to even go into the comp chem simulations I've been running, or that about 1/3 the stuff I do is embedded. I do still use python for web dev, partly because as you say, it's not CPU-bound, and partly because Python's Django framework is amazing. But I have switched to rust for everything else.

kstrauser 1y ago
I won’t completely argue against that, and I’ve also adopted Rust for smaller or faster work. Still, I contend that a freaking enormous portion of computing workloads are IO bound to the point that even Python’s speed is Good Enough in an Amdahl’s Law kind of way.
- lenerdenator 1y ago
  It's been said that Python's greatest superpower is that it's the second-best language at the most stuff. No one's really developed an ecosystem for a language that's more performant that can match it, and that's all it needs to assert dominance.
  - azkalam 1y ago
    I've never understood this. Python cannot be optimized like C, C++ or Rust. It cannot do advanced functional things like OCaml, Haskell or Scala. It cannot run in browsers like TypeScript. It cannot do games programming like C# and it can't do crazy macro stuff like Clojure. I don't think it's even second best at those things.
    - lenerdenator 1y ago
      I'm reading this as, "It cannot do things the best", and that's correct. It can't. But it can do them well enough, and enough people know it that they can drag a solution across the line in most domains.

cyberax 1y ago

And my experience is this: you start using ORMs, and maybe you need to format a large table once in a while. Then your Python just dies. Bonus points if you're using async to service multiple clients with the same interpreter. And you're now forced to spend time hunting down places for micro-optimizations. Or worse, you end up with a weird mix of Cython and Python that can only be compiled on the developer's machine.

deleted 1y ago
[deleted]

npalli 1y ago

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.

kstrauser 1y ago
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.
- tredre3 1y ago
  You are correct. However it took about only about 10 years for C compilers to beat hand assembly (for the average programmer), thus proving the naysayers wrong. Meanwhile Python is just as slow today as it was 30 years ago (on the same machine).
bee_rider 1y ago
Even as a Fortran programmer, the majority of my flops come from BLAS, LAPACK, and those sort of libraries… putting me in the exact same boat as the Python programmers, really. The “professional” programmers in general don’t worry too much about tying their identities to language choices, I think.
Karrot_Kream 1y ago
This is a very common pattern in high level languages and has been a thing ever since Perl had first come onto the scene. The whole point was that you use more ergonomic, easier to iterate languages like Perl or Python for most of your logic and you drop down into C, C++, Zig, or Rust to write the performance sensitive portions of your code. When compiled languages became popular again in the 2010s there was a renewed effort into ergonomic compiled languages to buck this trend (Scala, Kotlin, Go, Rust, and Zig all gained their popularity in this timeframe) but there's still a lot of code written with the two language pattern.

lozenge 1y ago

Advent of code is deliberately set up to be doable in Python. You can also imagine a useful problem which Rust takes 2 weeks to do, how long would it take in Python?

varjag 1y ago

Sure then you get a developer who decides to go with Flask for an embedded product and it's an eye watering slog.

kstrauser 1y ago
People will always make bad decisions. For example, I'd also squint at a developer who wanted to write a new non-performance-critical network service in C. Or a performance-critical one, for that matter, unless there was some overwhelming reason they couldn't use Rust or even C++.

ncruces 1y ago

> 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. I was asked to rewrite some NumPy image processing in C++, because NumPy worked fine for 1024px test images but balked when given 40 Mpx photos. I cut the runtime by an order of magnitude for those large images, even before I added a bit of SIMD (just to handle one RGBX-float pixel at a time, nothing even remotely fancy). The “NumPy has uber fast kernels that you can't beat” mentality leads people to use algorithms that do N passes over N intermediate buffers, that can all easily be replaced by a single C/C++/Rust (even Go!) loop over pixels. Also reinforced by “you can never loop over pixels in Python - that's horribly slow!”

rowanG077 1y ago
Same with opencv and even sometimes optimized matrix libraries in pure C++. These are all highly optimized. But often when you want to achieve something you have to chain stuff which quickly eats up a lot of cycles, just by copying stuff around and having multiple passes that the compiler is unable to fuse. You can often pretty easily beat that even if you are not an optimization god by manual loop fusion.
physicsguy 1y ago
Fused expressions are possible using other libraries (numexpr is pretty good), but I agree that there's a reluctance to use things outside of NumPy. Personally though I find it easier to just drop into C extensions at the point that NumPy becomes a limiting factor. They're so easy to do and it lets me keep the Python usability.