5 ms·

I don't understand why Python gets shit for being a slow language when it's slow but no credit for being fast when it's fast just because "it's not really Pytho

by qd011 3y ago

I don't understand why Python gets shit for being a slow language when it's slow but no credit for being fast when it's fast just because "it's not really Python". If I write Python and my code is fast, to me that sounds like Python is fast, I couldn't care less whether it's because the implementation is in another language or for some other reason.

paulddraper 3y ago
Yeah, it's weird.
afdbcreid 3y ago
Usually, yes, but when it's a bug in the hardware, it's not really that Python is fast, more like that CPython developers were lucky enough to not have the bug.
- munch117 3y ago
  How do you know that it's luck?
  - cozzyd 3y ago
    Because the offset is entirely due to space for the PyObject header.
    - munch117 3y ago
      The PyObject header is a target for optimisation. Performance regressions are likely to be noticed, and if a different header layout is faster, then it's entirely possible that it will be used for purely empirical reasons. Trying different options and picking the best performing one is not luck, even if you can't explain why it's the best performing.
      - cozzyd 3y ago
        I suspect any size other than 0 would lead to this. But the Zen3/4 were developed far, far after the PyObject header...
      - saagarjha 3y ago
        You can expect the Python developers to look very closely at any benchmark that significantly benefits from adding random padding to the object header. Performance isn’t just trying a bunch of random things and picking whatever works the best, it’s critical to understand why so you know that the improvement is not a fluke. Especially since it is very easy to introduce bias and significantly perturb the results if you don’t understand what’s going on.
        munch117 3y ago
        We're not talking about random changes. We're talking about paying attention to the measured performance of changes made for other reasons. Just like in this article. The author measured, wondered, investigated, experimented, and finally, after a lot of hard work, made the C/Rust programs faster. You wouldn't call that luck, would you? If there had been a similar performance regression in CPython, then a benchmark could have picked up on it, and the CPython developers would then have done the same.
        saagarjha 3y ago
        You can look at the history of PyObject yourself: https://github.com/python/cpython/commits/main/Include/object.h https://github.com/python/cpython/commits/main/Include/objec.... None of these changes were done because of weird CPU errata that meant that making the header bigger was a performance win. That isn't to say that the developers wouldn't be interested in such effects, or be able to detect them, but the fact that the object header happens to be large enough to avoid the performance bug isn't because of careful testing but because that's what they ended up for other reasons, far before Zen 3 was ever released. If it so happened that Python was affected because the offset needed to avoid a penalty was 0x50 or something then I am sure they would take it up with AMD rather than being content to increase the size of their header for no reason.
  - adgjlsfhk1 3y ago
    because the offset here is a result of python's reference counting which dates ~20 years before zen3
benrutter 3y ago
I wonder if its because we're sometimes talking cross purposes. For me, coding is almost exclusively using python libraries like numpy to call out to other languages like c or FORTRAN. It feels silly to say I'm not coding in Python to me. On the other hand, if you're writing those libraries, coding to you is mostly writing FORTRAN and c optimizations. It probably feels silly to say you're coding in Python just because that's where your code is called from.
- zare_st 3y ago
  There is a version of BASIC, a QuickBasic clone called Qb64 that is lightning fast because it transpiles to C++. By your admission a programmer should think that BASIC is fast because he only does BASIC and does not care about the environment details? It's actually the opposite, a Python programmer should know how to offload most, or use the libraries that do so, out of Python into C. He should not be oblivious to the fact that any decent Python performance is due to shrinking down the ratio of actual Python instructions vs native instructions.
  - benrutter 3y ago
    I think maybe it's just semantics as long as everyone agrees where the speedup is happening (at the low level language calls). I noticed that you're pretty hard in the "basic isn't fast, the thing it transpiles to is fast" camp, but still accidentally said "there is a version of BASIC [...] that is lightning fast" which I'm not sure you think? Highlights just how tricky it is to talk about where speed lives
    - zare_st 3y ago
      I agree with that. There is clear distinction between original language design (an interpreter) and a project aiming to recreate a sub-standard of that language and support its legacy codebase via a transpiler.
kbenson 3y ago
Because for any nontrivial case you would expect python+compiled library and associated marshaling of data to be slower than that library in its native implementation without any inyerop/marshaling required. When you see an interpreted language faster than a compiled one, it's worth looking at why, because most the time it's because there's some hidden issue causing the other to be slow (which could just be a different and much worse implementation). Put another way, you can do a lot to make a Honda Civic very fast, but when you hear one goes up against a Ferrari and wins your first thoughts should be about what the test was, how the Civic was modified, and if the Ferrari had problems or the test wasn't to its strengths at all. If you just think "yeah, I love Civics, that's awesome" then you're not thinking critically enough about it.
- Attummm 3y ago
  In this case, Python's code (opening and loading the content of a file) operates almost fully within its C runtime. The C components initiate the system call and manage the file pointer, which loads the data from the disk into a pyobj string. Therefore, it isn't so much Python itself that is being tested, but rather python underlying C runtime.
  - kbenson 3y ago
    Yep, and the next logical question when both implementations are for the most part bare metal (compiled and low-level), is why is there a large difference? Is it a matter of implementation/algorithm, inefficiency, or a bug somewhere? In this case, that search turned up a hardware issue that should be addressed, which is why it's so useful to examine these things.
- heavyset_go 3y ago
  If you're staying within Python and its C-extensions, there is no marshalling, you're dealing with raw PyObjects that are exposed to the interpreter.
- lmm 3y ago
  > Because for any nontrivial case you would expect python+compiled library and associated marshaling of data to be slower than that library in its native implementation without any inyerop/marshaling required. > When you see an interpreted language faster than a compiled one, it's worth looking at why, because most the time it's because there's some hidden issue causing the other to be slow (which could just be a different and much worse implementation). On the contrary, the compiled languages tend to only be faster in trivial benchmarks. In real-world systems the Python-based systems tends to be faster because they haven't had to spend so long twiddling which integers they're using and debugging crashes and memory leaks, and got to spend more time on the problem.
rafaelmn 3y ago
But you will care if that "python" breaks - you get to drop down to C/C++ and debugging native code. Likewise for adding features or understanding the implementation. Not to mention having to deal with native build tooling and platform specific stuff. It's completely fair to say that's not python because it isn't - any language out there can FFI to C and it has the same problems mentioned above.
IshKebab 3y ago
Because when people talk about Python performance they're talking about the performance of Python code itself, not C/Rust code that it's wrapping. Pretty much any language can wrap C/Rust code. Why does it matter? 1. Having to split your code across 2 languages via FFI is a huge pain. 2. You are still writing some Python. There's plenty of code that is pure Python. That code is slow.
- munch117 3y ago
  Of course in this case there's no FFI involved - the open function is built-in. It's as pure-Python as it can get.
  - IshKebab 3y ago
    Not sure I agree there, but anyway in this case the performance had nothing to do with Python being a slow or fast language.
  - jwueller 3y ago
    How is it pure Python if it delegates all of the actual work to the Kernel?
    - munch117 3y ago
      All I/O delegates to the kernel, eventually. It's pure Python in that there's no cffi, no ctypes, no Cython, no C extensions of any kind.
      - int_19h 3y ago
        It's pretty hard to draw this line in Python because all built-in types and functions are effectively C extensions, just compiled directly into the interpreter. Conversely, you can have pure C code just using PyObjects (this is effectively what Cython does), with the Python bytecode interpreter completely out of the picture. But the perf improvement is nowhere near what people naively expect from compiled code, usually.
insanitybit 3y ago
>I don't understand why Python gets shit for being a slow language when it's slow but no credit for being fast when it's fast just because "it's not really Python". What's there to understand? When it's fast it's not really Python, it's C. C is fast. Python can call out to C. You don't have to care that the implementation is in another language, but it is.
analog31 3y ago
I think the confusion comes from people not having a good understanding of what an interpreted programming language does, and what actual portion of time is spent in high versus low level code. I've always assumed that most of my programs amount to a bit of glue thrown in between system calls. Also, when we talk about "faster" and "slower," it's not clear the order of magnitude. Maybe an analysis of actual code execution would shed more light than a simplistic explanation that the Python interpreter is written in C. I don't think the BASIC interpreter in my first computer was written in BASIC.
- zare_st 3y ago
  Agreed. The speed of a language is reverse proportional to number of CPU instructions emitted to do something meaningful, e.g. solve a problem. Not whether it can target system calls without overhead and move memory around freely. That's a given.
p5a0u9l 3y ago
I constantly get low key shade for choosing to build everything in Python. It’s really interesting to me. People can’t break out of thinking, “oh, you wrote a script for that?”. Actually, no, it’s software, not a script. 99% of my use cases are easily, maintainably solved with good, modern Python. The Python execution is almost never the bottleneck in my workflows. It’s disk or network I/O. I’m not against building better languages and ecosystems, and compiled languages are clearly appropriate/required in many workflows, but the language parochialism gets old. I just want to build shit that works and get stuff done.

by qd011 3y ago

paulddraper 3y ago

Yeah, it's weird.

afdbcreid 3y ago

Usually, yes, but when it's a bug in the hardware, it's not really that Python is fast, more like that CPython developers were lucky enough to not have the bug.

munch117 3y ago
How do you know that it's luck?
- cozzyd 3y ago
  Because the offset is entirely due to space for the PyObject header.
  - munch117 3y ago
    The PyObject header is a target for optimisation. Performance regressions are likely to be noticed, and if a different header layout is faster, then it's entirely possible that it will be used for purely empirical reasons. Trying different options and picking the best performing one is not luck, even if you can't explain why it's the best performing.
    - cozzyd 3y ago
      I suspect any size other than 0 would lead to this. But the Zen3/4 were developed far, far after the PyObject header...
    - saagarjha 3y ago
      You can expect the Python developers to look very closely at any benchmark that significantly benefits from adding random padding to the object header. Performance isn’t just trying a bunch of random things and picking whatever works the best, it’s critical to understand why so you know that the improvement is not a fluke. Especially since it is very easy to introduce bias and significantly perturb the results if you don’t understand what’s going on.
      - munch117 3y ago
        We're not talking about random changes. We're talking about paying attention to the measured performance of changes made for other reasons. Just like in this article. The author measured, wondered, investigated, experimented, and finally, after a lot of hard work, made the C/Rust programs faster. You wouldn't call that luck, would you? If there had been a similar performance regression in CPython, then a benchmark could have picked up on it, and the CPython developers would then have done the same.
        saagarjha 3y ago
        You can look at the history of PyObject yourself: https://github.com/python/cpython/commits/main/Include/object.h https://github.com/python/cpython/commits/main/Include/objec.... None of these changes were done because of weird CPU errata that meant that making the header bigger was a performance win. That isn't to say that the developers wouldn't be interested in such effects, or be able to detect them, but the fact that the object header happens to be large enough to avoid the performance bug isn't because of careful testing but because that's what they ended up for other reasons, far before Zen 3 was ever released. If it so happened that Python was affected because the offset needed to avoid a penalty was 0x50 or something then I am sure they would take it up with AMD rather than being content to increase the size of their header for no reason.
- adgjlsfhk1 3y ago
  because the offset here is a result of python's reference counting which dates ~20 years before zen3

benrutter 3y ago

I wonder if its because we're sometimes talking cross purposes. For me, coding is almost exclusively using python libraries like numpy to call out to other languages like c or FORTRAN. It feels silly to say I'm not coding in Python to me. On the other hand, if you're writing those libraries, coding to you is mostly writing FORTRAN and c optimizations. It probably feels silly to say you're coding in Python just because that's where your code is called from.

zare_st 3y ago
There is a version of BASIC, a QuickBasic clone called Qb64 that is lightning fast because it transpiles to C++. By your admission a programmer should think that BASIC is fast because he only does BASIC and does not care about the environment details? It's actually the opposite, a Python programmer should know how to offload most, or use the libraries that do so, out of Python into C. He should not be oblivious to the fact that any decent Python performance is due to shrinking down the ratio of actual Python instructions vs native instructions.
- benrutter 3y ago
  I think maybe it's just semantics as long as everyone agrees where the speedup is happening (at the low level language calls). I noticed that you're pretty hard in the "basic isn't fast, the thing it transpiles to is fast" camp, but still accidentally said "there is a version of BASIC [...] that is lightning fast" which I'm not sure you think? Highlights just how tricky it is to talk about where speed lives
  - zare_st 3y ago
    I agree with that. There is clear distinction between original language design (an interpreter) and a project aiming to recreate a sub-standard of that language and support its legacy codebase via a transpiler.

kbenson 3y ago

Because for any nontrivial case you would expect python+compiled library and associated marshaling of data to be slower than that library in its native implementation without any inyerop/marshaling required. When you see an interpreted language faster than a compiled one, it's worth looking at why, because most the time it's because there's some hidden issue causing the other to be slow (which could just be a different and much worse implementation). Put another way, you can do a lot to make a Honda Civic very fast, but when you hear one goes up against a Ferrari and wins your first thoughts should be about what the test was, how the Civic was modified, and if the Ferrari had problems or the test wasn't to its strengths at all. If you just think "yeah, I love Civics, that's awesome" then you're not thinking critically enough about it.

Attummm 3y ago
In this case, Python's code (opening and loading the content of a file) operates almost fully within its C runtime. The C components initiate the system call and manage the file pointer, which loads the data from the disk into a pyobj string. Therefore, it isn't so much Python itself that is being tested, but rather python underlying C runtime.
- kbenson 3y ago
  Yep, and the next logical question when both implementations are for the most part bare metal (compiled and low-level), is why is there a large difference? Is it a matter of implementation/algorithm, inefficiency, or a bug somewhere? In this case, that search turned up a hardware issue that should be addressed, which is why it's so useful to examine these things.
heavyset_go 3y ago
If you're staying within Python and its C-extensions, there is no marshalling, you're dealing with raw PyObjects that are exposed to the interpreter.
lmm 3y ago
> Because for any nontrivial case you would expect python+compiled library and associated marshaling of data to be slower than that library in its native implementation without any inyerop/marshaling required. > When you see an interpreted language faster than a compiled one, it's worth looking at why, because most the time it's because there's some hidden issue causing the other to be slow (which could just be a different and much worse implementation). On the contrary, the compiled languages tend to only be faster in trivial benchmarks. In real-world systems the Python-based systems tends to be faster because they haven't had to spend so long twiddling which integers they're using and debugging crashes and memory leaks, and got to spend more time on the problem.

rafaelmn 3y ago

But you will care if that "python" breaks - you get to drop down to C/C++ and debugging native code. Likewise for adding features or understanding the implementation. Not to mention having to deal with native build tooling and platform specific stuff. It's completely fair to say that's not python because it isn't - any language out there can FFI to C and it has the same problems mentioned above.

IshKebab 3y ago

Because when people talk about Python performance they're talking about the performance of Python code itself, not C/Rust code that it's wrapping. Pretty much any language can wrap C/Rust code. Why does it matter? 1. Having to split your code across 2 languages via FFI is a huge pain. 2. You are still writing some Python. There's plenty of code that is pure Python. That code is slow.

munch117 3y ago
Of course in this case there's no FFI involved - the open function is built-in. It's as pure-Python as it can get.
- IshKebab 3y ago
  Not sure I agree there, but anyway in this case the performance had nothing to do with Python being a slow or fast language.
- jwueller 3y ago
  How is it pure Python if it delegates all of the actual work to the Kernel?
  - munch117 3y ago
    All I/O delegates to the kernel, eventually. It's pure Python in that there's no cffi, no ctypes, no Cython, no C extensions of any kind.
    - int_19h 3y ago
      It's pretty hard to draw this line in Python because all built-in types and functions are effectively C extensions, just compiled directly into the interpreter. Conversely, you can have pure C code just using PyObjects (this is effectively what Cython does), with the Python bytecode interpreter completely out of the picture. But the perf improvement is nowhere near what people naively expect from compiled code, usually.

insanitybit 3y ago

>I don't understand why Python gets shit for being a slow language when it's slow but no credit for being fast when it's fast just because "it's not really Python". What's there to understand? When it's fast it's not really Python, it's C. C is fast. Python can call out to C. You don't have to care that the implementation is in another language, but it is.

analog31 3y ago

I think the confusion comes from people not having a good understanding of what an interpreted programming language does, and what actual portion of time is spent in high versus low level code. I've always assumed that most of my programs amount to a bit of glue thrown in between system calls. Also, when we talk about "faster" and "slower," it's not clear the order of magnitude. Maybe an analysis of actual code execution would shed more light than a simplistic explanation that the Python interpreter is written in C. I don't think the BASIC interpreter in my first computer was written in BASIC.

zare_st 3y ago
Agreed. The speed of a language is reverse proportional to number of CPU instructions emitted to do something meaningful, e.g. solve a problem. Not whether it can target system calls without overhead and move memory around freely. That's a given.

p5a0u9l 3y ago

I constantly get low key shade for choosing to build everything in Python. It’s really interesting to me. People can’t break out of thinking, “oh, you wrote a script for that?”. Actually, no, it’s software, not a script. 99% of my use cases are easily, maintainably solved with good, modern Python. The Python execution is almost never the bottleneck in my workflows. It’s disk or network I/O. I’m not against building better languages and ecosystems, and compiled languages are clearly appropriate/required in many workflows, but the language parochialism gets old. I just want to build shit that works and get stuff done.