4 ms·

That makes it so that in absolute terms, Python is not as slow as you might naively expect. But we don't measure programming language performance in absolute t

by jerf 1y ago

That makes it so that in absolute terms, Python is not as slow as you might naively expect. But we don't measure programming language performance in absolute terms. We measure them in relative terms, generally against C. And while your Python code is speculating about how this Python object will be unboxed, where its methods are, how to unbox its parameters, what methods will be called on those, etc., compiled code is speculating on actual code the programmer has written, running that in parallel, such that by the time the Python interpreter is done speculating successfully on how some method call will resolve with actual objects the compiled code language is now done with ~50 lines of code of similar grammatical complexity. (Which is a sloppy term, since this is a bit of a sloppy conversation, but consider a series "p.x = y"-level statements in Python versus C as the case I'm looking at here.) There's no way around it. You can spend your amazingly capable speculative parallel CPU on churning through Python interpretation or you can spend it on doing real work, but you can't do both. After all, the interpreter is just C code too. It's not like it gets access to special speculation opcodes that no other program does.

Demiurge 1y ago
I love this “real work”. Real work, like writing linked lists, array bounds checking, all the error handling for opening files, etc, etc? There is a reason Python and C both have a use case, and it’s obvious Python will never be as fast as C doing “1 + 1”. The real “real work” is in getting stuff done, not just making sure the least amount of cpu cycles are used to accomplish some web form generation. Anyway, I think you’re totally right, in your general message. Python will never be the fastest language in all contexts. Still, there is a lot of room for optimization, and given it’s a popular language, it’s worth the effort.
- btown 1y ago
  To put it another way, I choose Python because of its semantics around dynamic operator definition, duck typing etc. Just because I don’t write the bounds-checking and type-checking and dynamic-dispatch and error-handling code myself, doesn’t make it any less a conscious decision I made by choosing Python. It’s all “real work.”
  - kragen 1y ago
    Type checking and bounds checking aren't "real work" in the sense that, when somebody checks their bank account balance on your website or applies a sound effect to an audio track in their digital audio workstation, they don't think, "Oh good! The computer is going to do some type checking for me now!" Type checking and bounds checking may be good means to an end, but they are not the end, from the point of view of the outside world. Of course, the bank account is only a means to the end of paying the dentist for installing crowns on your teeth and whatnot, and the sound effect is only a means to the end of making your music sound less like Daft Punk or something, so it's kind of fuzzy. It depends on what people are thinking about achieving. As programmers, because we know the experience of late nights debugging when our array bounds overflow, we think of bounds checking and type checking as ends in themselves. But only up to a point! Often, type checking and bounds checking can be done at compile time, which is more efficient. When we do that, as long as it works correctly, we never† feel disappointed that our program isn't doing run-time type checks. We never look at our running programs and say, "This program would be better if it did more of its type checks at runtime!" No. Run-time type checking is purely a deadweight loss: wasting some of the CPU on computation that doesn't move the program toward achieving the goals we were trying to achieve when we wrote it. It may be a worthwhile tradeoff (for simplicity of implementation, for example) but we must weigh it on the debit side of the ledger, not the credit side. ______ † Well, unless we're trying to debug a PyPy type-specialization bug or something. Then we might work hard to construct a program that forces PyPy to do more type-checking at runtime, and type checking does become an end.
    - rightbyte 1y ago
      > and the sound effect is only a means to the end of making your music sound less like Daft Punk or something What do you mean. Daft Punk is not daft punk. Why single them out :)
      - kragen 1y ago
        Well, originally I wrote "more like Daft Punk", but then I thought someone might think I was stereotyping musicians as being unoriginal and derivative, so I swung the other way.
- jerf 1y ago
  I can't figure out what your first paragraph is about. The topic under discussion is Python performance. We do not generally try to measure something as fuzzy as "real work" as you seem to be using the term in performance discussions because what even is that. There's a reason my post referenced "lines of code", still a rather fuzzy thing (which I already pointed out in my post), but it gets across the idea that while Python has to do a lot of work for "x.y = z" for all the things that "x.y" might mean including the possibility that the user has changed what it means since the last time this statement ran, compiled languages generally do over an order of magnitude less "work" in resolving that. This is one of the issues with Python I've pointed out before, to the point I suggest that someone could make a language around this idea: https://jerf.org/iri/post/2025/programming_language_ideas/#semi-dynamic-language https://jerf.org/iri/post/2025/programming_language_ideas/#s... In Python you pay and pay and pay and pay and pay for all this dynamic functionality, but in practice you aren't actually dynamically modifying class hierarchies and attaching arbitrary attributes to arbitrary instances with arbitrary types. You pay for the feature but you benefit from them far less often than the number of times Python is paying for them. Python spends rather a lot of time spinning its wheels double-checking that it's still safe to do the thing it thinks it can do, and it's hard to remove that even in JIT because it is extremely difficult to prove it can eliminate those checks.
  - mmcnl 1y ago
    You claimed churning through Python interpretation is not "real work". You now correctly ask the question: what is "real work"? Why is interpreting Python not real work, if it means I don't have to check for array bounds?
    - coldtea 1y ago
      >Why is interpreting Python not real work, if it means I don't have to check for array bounds? Because other languages can do that for you too, much much faster...
  - Demiurge 1y ago
    I understand what you're saying. In a way, my comment is actually off-topic to most of your comment. What I was saying in my first paragraph is that the words you use in your context of a language runtime in-effeciency, can be used to describe why these in-effeciences exist, in the context of higher level processes, like business effeciency. I find your choice of words amusing, given the juxtoposition of these contexts, even saying "you pay, pay, pay".
- Calavar 1y ago
  I believe they are talking about the processor doing real work, not the programmer.
  - Demiurge 1y ago
    Yeah, I get it, but I found the choice of words funny, because these words can apply in the larger context. It's like saying, Python transfers work from your man hours to cpu hours :)
    - deleted 1y ago
      [deleted]
- weinzierl 1y ago
  "There is a reason Python and C both have a use case [..]" If you mean historically, then yes, but I don't think there is an inherent reason why we couldn't have a language as convenient as Python and fast as C.
  - Demiurge 1y ago
    It seems like a lot of people are trying, it doesn’t look like they’re succeeding.
    - weinzierl 1y ago
      Rust is pretty close.
      - Demiurge 1y ago
        I don't know a single person who would agree with that, including both python and rust enthusiasts.
        yunohn 1y ago
        If I had to choose, I would compare golang but definitely not rust! Too slow to compile and non-ergonomic syntax compared to Python…
  - whytevuhuni 1y ago
    I think there is indeed an inherent reason. In order to get conciseness, you need to accept defaults that work for everyone. Those defaults might not be that great for you, but they're good enough. In order to get performance, those "good enough defaults" are suddenly no longer good enough, and now you need to get very specific with what you're doing. Maybe with a smart enough compiler, a high-level language could be compiled to something with very good performance, but the promise of that "sufficiently smart compiler" has yet to be fulfilled.
dragonwriter 1y ago
> After all, the interpreter is just C code too. What interpreter? We’re talking about JITting Python to native code.
qaq 1y ago
Welp there is Mojo so looks like soon you will not really need to care that much. Prob will get better performance than C too.
- jerf 1y ago
  I've been hearing promises about "better than C" performance from Python for over 25 years. I remember them on comp.lang.python, back on that Usenet thing most people reading this have only heard about. At this point, you just shouldn't be making that promise. Decent chance that promise is already older than you are. Just let the performance be what it is, and if you need better performance today, be aware that there are a wide variety of languages of all shapes and sizes standing by to give you ~25-50x better single threaded performance and even more on multi-core performance today if you need it. If you need it, waiting for Python to provide it is not a sensible bet.
  - hnfong 1y ago
    You're probably right, Mojo seems to be more "python-like" than actually source-compatible with python. Bunch of features notably classes are missing.
    - qaq 1y ago
      Give em a bit of time it's pretty young lang
  - qaq 1y ago
    I am a bit older than Python :). I imagine creator of clang and LLVM has fairly good grasp on making things performant. Think of Mojo as Rust with better ergonomics and more advanced compiler that you can mix and match with regular python.
  - sevensor 1y ago
    I maintain a program written in Python that is faster than the program written in C that it replaces. The C version can do a lot more operations, but it amounts to enumerating 2^N alternatives when you could enumerate N alternatives instead. Certainly my version would be even faster if I implemented it in C, but the gains of going from exponential to linear completely dominate the language difference.
CraigJPerry 1y ago
> And while your Python code is speculating about how this Python object will be unboxed This is wrong i think? The GP is talking about JIT'd code.

by jerf 1y ago

Demiurge 1y ago

I love this “real work”. Real work, like writing linked lists, array bounds checking, all the error handling for opening files, etc, etc? There is a reason Python and C both have a use case, and it’s obvious Python will never be as fast as C doing “1 + 1”. The real “real work” is in getting stuff done, not just making sure the least amount of cpu cycles are used to accomplish some web form generation. Anyway, I think you’re totally right, in your general message. Python will never be the fastest language in all contexts. Still, there is a lot of room for optimization, and given it’s a popular language, it’s worth the effort.

btown 1y ago
To put it another way, I choose Python because of its semantics around dynamic operator definition, duck typing etc. Just because I don’t write the bounds-checking and type-checking and dynamic-dispatch and error-handling code myself, doesn’t make it any less a conscious decision I made by choosing Python. It’s all “real work.”
- kragen 1y ago
  Type checking and bounds checking aren't "real work" in the sense that, when somebody checks their bank account balance on your website or applies a sound effect to an audio track in their digital audio workstation, they don't think, "Oh good! The computer is going to do some type checking for me now!" Type checking and bounds checking may be good means to an end, but they are not the end, from the point of view of the outside world. Of course, the bank account is only a means to the end of paying the dentist for installing crowns on your teeth and whatnot, and the sound effect is only a means to the end of making your music sound less like Daft Punk or something, so it's kind of fuzzy. It depends on what people are thinking about achieving. As programmers, because we know the experience of late nights debugging when our array bounds overflow, we think of bounds checking and type checking as ends in themselves. But only up to a point! Often, type checking and bounds checking can be done at compile time, which is more efficient. When we do that, as long as it works correctly, we never† feel disappointed that our program isn't doing run-time type checks. We never look at our running programs and say, "This program would be better if it did more of its type checks at runtime!" No. Run-time type checking is purely a deadweight loss: wasting some of the CPU on computation that doesn't move the program toward achieving the goals we were trying to achieve when we wrote it. It may be a worthwhile tradeoff (for simplicity of implementation, for example) but we must weigh it on the debit side of the ledger, not the credit side. ______ † Well, unless we're trying to debug a PyPy type-specialization bug or something. Then we might work hard to construct a program that forces PyPy to do more type-checking at runtime, and type checking does become an end.
  - rightbyte 1y ago
    > and the sound effect is only a means to the end of making your music sound less like Daft Punk or something What do you mean. Daft Punk is not daft punk. Why single them out :)
    - kragen 1y ago
      Well, originally I wrote "more like Daft Punk", but then I thought someone might think I was stereotyping musicians as being unoriginal and derivative, so I swung the other way.
jerf 1y ago
I can't figure out what your first paragraph is about. The topic under discussion is Python performance. We do not generally try to measure something as fuzzy as "real work" as you seem to be using the term in performance discussions because what even is that. There's a reason my post referenced "lines of code", still a rather fuzzy thing (which I already pointed out in my post), but it gets across the idea that while Python has to do a lot of work for "x.y = z" for all the things that "x.y" might mean including the possibility that the user has changed what it means since the last time this statement ran, compiled languages generally do over an order of magnitude less "work" in resolving that. This is one of the issues with Python I've pointed out before, to the point I suggest that someone could make a language around this idea: https://jerf.org/iri/post/2025/programming_language_ideas/#semi-dynamic-language https://jerf.org/iri/post/2025/programming_language_ideas/#s... In Python you pay and pay and pay and pay and pay for all this dynamic functionality, but in practice you aren't actually dynamically modifying class hierarchies and attaching arbitrary attributes to arbitrary instances with arbitrary types. You pay for the feature but you benefit from them far less often than the number of times Python is paying for them. Python spends rather a lot of time spinning its wheels double-checking that it's still safe to do the thing it thinks it can do, and it's hard to remove that even in JIT because it is extremely difficult to prove it can eliminate those checks.
- mmcnl 1y ago
  You claimed churning through Python interpretation is not "real work". You now correctly ask the question: what is "real work"? Why is interpreting Python not real work, if it means I don't have to check for array bounds?
  - coldtea 1y ago
    >Why is interpreting Python not real work, if it means I don't have to check for array bounds? Because other languages can do that for you too, much much faster...
- Demiurge 1y ago
  I understand what you're saying. In a way, my comment is actually off-topic to most of your comment. What I was saying in my first paragraph is that the words you use in your context of a language runtime in-effeciency, can be used to describe why these in-effeciences exist, in the context of higher level processes, like business effeciency. I find your choice of words amusing, given the juxtoposition of these contexts, even saying "you pay, pay, pay".
Calavar 1y ago
I believe they are talking about the processor doing real work, not the programmer.
- Demiurge 1y ago
  Yeah, I get it, but I found the choice of words funny, because these words can apply in the larger context. It's like saying, Python transfers work from your man hours to cpu hours :)
  - deleted 1y ago
    [deleted]
weinzierl 1y ago
"There is a reason Python and C both have a use case [..]" If you mean historically, then yes, but I don't think there is an inherent reason why we couldn't have a language as convenient as Python and fast as C.
- Demiurge 1y ago
  It seems like a lot of people are trying, it doesn’t look like they’re succeeding.
  - weinzierl 1y ago
    Rust is pretty close.
    - Demiurge 1y ago
      I don't know a single person who would agree with that, including both python and rust enthusiasts.
      - yunohn 1y ago
        If I had to choose, I would compare golang but definitely not rust! Too slow to compile and non-ergonomic syntax compared to Python…
- whytevuhuni 1y ago
  I think there is indeed an inherent reason. In order to get conciseness, you need to accept defaults that work for everyone. Those defaults might not be that great for you, but they're good enough. In order to get performance, those "good enough defaults" are suddenly no longer good enough, and now you need to get very specific with what you're doing. Maybe with a smart enough compiler, a high-level language could be compiled to something with very good performance, but the promise of that "sufficiently smart compiler" has yet to be fulfilled.

dragonwriter 1y ago

> After all, the interpreter is just C code too. What interpreter? We’re talking about JITting Python to native code.

qaq 1y ago

Welp there is Mojo so looks like soon you will not really need to care that much. Prob will get better performance than C too.

jerf 1y ago
I've been hearing promises about "better than C" performance from Python for over 25 years. I remember them on comp.lang.python, back on that Usenet thing most people reading this have only heard about. At this point, you just shouldn't be making that promise. Decent chance that promise is already older than you are. Just let the performance be what it is, and if you need better performance today, be aware that there are a wide variety of languages of all shapes and sizes standing by to give you ~25-50x better single threaded performance and even more on multi-core performance today if you need it. If you need it, waiting for Python to provide it is not a sensible bet.
- hnfong 1y ago
  You're probably right, Mojo seems to be more "python-like" than actually source-compatible with python. Bunch of features notably classes are missing.
  - qaq 1y ago
    Give em a bit of time it's pretty young lang
- qaq 1y ago
  I am a bit older than Python :). I imagine creator of clang and LLVM has fairly good grasp on making things performant. Think of Mojo as Rust with better ergonomics and more advanced compiler that you can mix and match with regular python.
- sevensor 1y ago
  I maintain a program written in Python that is faster than the program written in C that it replaces. The C version can do a lot more operations, but it amounts to enumerating 2^N alternatives when you could enumerate N alternatives instead. Certainly my version would be even faster if I implemented it in C, but the gains of going from exponential to linear completely dominate the language difference.

CraigJPerry 1y ago

> And while your Python code is speculating about how this Python object will be unboxed This is wrong i think? The GP is talking about JIT'd code.