3 ms·

> Insanely smart optimizations done. But then you rewrite the whole thing in vanilla Rust without profiling once and it's still 20x faster, and much more readab

by lpapez 2y ago

> Insanely smart optimizations done. But then you rewrite the whole thing in vanilla Rust without profiling once and it's still 20x faster, and much more readable than the mix of numpy vectorization and C-routines. I'd argue that if you can rewrite the whole thing in Rust (or any other language), then it's not really a large project and it doesn't matter what you originally wrote it in. On multiple occassions I had to port parts of Python projects to C++ for performance reasons, and the amount of code you have to write (and time you need to spend) is mind blowing. Sometimes a single line of Python would expand to several files of C++, and you always had to redesign it somehow so that memory and lifetime management becomes feasible. Python is often the right choice IMO, because most of the time the convenience you mention trumps all other concerns, including performance. I bet you would get tons of examples from people if you "Ask HN" about "how many quickly written Python prototypes are still out there years later because their C++ replacement could never be implemented on time?"

maccard 2y ago
There's a huge swathe of languages between Python and C++. On threads about Node's performance (which is somewhere in between) people regularly say that it's unfair of developers to solely focus on devex, which is the argument here. > On multiple occassions I had to port parts of Python projects to C++ for performance reasons, and the amount of code you have to write (and time you need to spend) is mind blowing. Sometimes a single line of Python would expand to several files of C++, and you always had to redesign it somehow so that memory and lifetime management becomes feasible. Part of that is because it's designed for python. Using this benchmark example, the python code (without imports) is 36 lines and the go code is 70. Except, we're doing a 1:1 copy of python to go here, not writing it like you would write go. Most of the difference is braces, and the test scaffold. I'd also argue the go code is more readable than the python code, doubly so when it scales.
- rbanffy 2y ago
  > it's unfair of developers to solely focus on devex, which is the argument here. For most companies and applications, developer time is many orders of magnitude more expensive than machine time. I agree that, if are running applications that run across thousands of servers, then it's worth writing it in the most performant way possible. If your app runs on half a dozen average instances in a dozen-node K8s cluster, it's often cheaper to add more metal than to rewrite a large app.
  - PhilipRoman 2y ago
    There is more to it than just time. If your app is customer facing (or even worse, runs on your customer's own resources), high latency and general slowness is a great way to make your users hate it. That can cost a lot more than few days of developer time for optimization.
    - rbanffy 2y ago
      There is, of course, a limit. OTOH, if your devex is so terrible you can’t push out improvements at the same cadence of your competitors, you are doomed as well.
  - maccard 2y ago
    No, it’s more expensive to you, and you get to ignore the externalities. It’s like climate change - you don’t care because it doesn’t affect you. How many hundreds of hours are wasted every day by Jira’s lazy loaded UI? I spend seconds waiting for UI transitions to happen on that app. How much of my life do I spend waiting for applications to load and show a single string that should take 50ms to fetch but instead takes 30 seconds to load a full application?
    - lpapez 2y ago
      I don't know, but personally I've spent orders of magnitude more time debugging memory leaks in languages without GC than the time I've wasted waiting for shitty apps to load. Software bloat is a real thing, I agree, but it's a fact of life and in my opinion not a hill worth dying on. People just don't care. If you want proof of this, try to find a widely used Jira alternative which doesn't suck and doesn't need a terabyte cluster to run. There isn't one because most people just don't care about it, they care about the bottom line.
      - rbanffy 2y ago
        Not only that - when your ticket system becomes a Jira because of all the feature creep required, it’ll perform like a Jira. Perhaps a little better if you can implement more in less crazy ways (it seems to keep a lot of logic into a relational database, which is a big no-no for the long term evolution of your system).
- igouy 2y ago
  > Using this benchmark example, the python code (without imports) is 36 lines and the go code is 70. Look at the gz values and notice that longer programs might be faster programs: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python3-go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... ~ "How source code size is measured" https://benchmarksgame-team.pages.debian.net/benchmarksgame/how-programs-are-measured.html#source-code https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
visarga 2y ago
It all depends on execution time. If you run it just a few times or the total execution time doesn't take days, you can do it faster in Python end-to-end.
KolenCh 2y ago
I have an example to support: https://github.com/hpc4cmb/toast/pull/380/commits/a38d1d6dbcc97001a1ad1c315bb08cf1eecc74c7?diff=unified&w=1 https://github.com/hpc4cmb/toast/pull/380/commits/a38d1d6dbc... A one-liner in Python is replaced by hundreds of lines of changes to implement in C++. (The one-liner has some boilerplates around it too, but the C++ function itself is longer and the boilerplates around is even more.) Edit: 230 additions and 36 deletions in 14 files.
- maccard 2y ago
  That’s replacing one line which calls a a third party dependency with a manual implementation in native code.
  - KolenCh 2y ago
    Technically right, but the original code only optionally depends on Numba, and Numpy is ubiquitous in scientific Python. The problem I was trying to solve in all those boilerplates is basically that Numpy still has overhead and dropping it to lower level is trivial if Numba is used, but the package maintainers doesn’t want to introduce Numba dependency for various reasons. And the diff is showing that change from Numpy/Numba to C++ with pybind11.
    - maccard 2y ago
      That doesn't change the fact that it's not representative of how many lines something takes in python vs C++. If you replaced it with a call to native that used a third party library it would be back to being one line.
      - KolenCh 2y ago
        First, no sane mind will think one single example will be representative to anything. Second, if you want to focus on 3rd party or not, sure. But you could also think Numba jit vs C++ and in this case it puts them on a more equal footing to compare them. As far as Numba is concerned, numpy is in its stdlib as it aren’t calling Numpy but jit compile it. You may say Numba is not Python, true, but you could consider Numba an implementation of a subset of Python. We can argue about the details but the example is not that long to read. My summary and your summary are both at best distilled through our own point of view a.k.a. biases. Anyone can read the diff itself to judge. That’s why I link to it.

by lpapez 2y ago

maccard 2y ago

There's a huge swathe of languages between Python and C++. On threads about Node's performance (which is somewhere in between) people regularly say that it's unfair of developers to solely focus on devex, which is the argument here. > On multiple occassions I had to port parts of Python projects to C++ for performance reasons, and the amount of code you have to write (and time you need to spend) is mind blowing. Sometimes a single line of Python would expand to several files of C++, and you always had to redesign it somehow so that memory and lifetime management becomes feasible. Part of that is because it's designed for python. Using this benchmark example, the python code (without imports) is 36 lines and the go code is 70. Except, we're doing a 1:1 copy of python to go here, not writing it like you would write go. Most of the difference is braces, and the test scaffold. I'd also argue the go code is more readable than the python code, doubly so when it scales.

rbanffy 2y ago
> it's unfair of developers to solely focus on devex, which is the argument here. For most companies and applications, developer time is many orders of magnitude more expensive than machine time. I agree that, if are running applications that run across thousands of servers, then it's worth writing it in the most performant way possible. If your app runs on half a dozen average instances in a dozen-node K8s cluster, it's often cheaper to add more metal than to rewrite a large app.
- PhilipRoman 2y ago
  There is more to it than just time. If your app is customer facing (or even worse, runs on your customer's own resources), high latency and general slowness is a great way to make your users hate it. That can cost a lot more than few days of developer time for optimization.
  - rbanffy 2y ago
    There is, of course, a limit. OTOH, if your devex is so terrible you can’t push out improvements at the same cadence of your competitors, you are doomed as well.
- maccard 2y ago
  No, it’s more expensive to you, and you get to ignore the externalities. It’s like climate change - you don’t care because it doesn’t affect you. How many hundreds of hours are wasted every day by Jira’s lazy loaded UI? I spend seconds waiting for UI transitions to happen on that app. How much of my life do I spend waiting for applications to load and show a single string that should take 50ms to fetch but instead takes 30 seconds to load a full application?
  - lpapez 2y ago
    I don't know, but personally I've spent orders of magnitude more time debugging memory leaks in languages without GC than the time I've wasted waiting for shitty apps to load. Software bloat is a real thing, I agree, but it's a fact of life and in my opinion not a hill worth dying on. People just don't care. If you want proof of this, try to find a widely used Jira alternative which doesn't suck and doesn't need a terabyte cluster to run. There isn't one because most people just don't care about it, they care about the bottom line.
    - rbanffy 2y ago
      Not only that - when your ticket system becomes a Jira because of all the feature creep required, it’ll perform like a Jira. Perhaps a little better if you can implement more in less crazy ways (it seems to keep a lot of logic into a relational database, which is a big no-no for the long term evolution of your system).
igouy 2y ago
> Using this benchmark example, the python code (without imports) is 36 lines and the go code is 70. Look at the gz values and notice that longer programs might be faster programs: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python3-go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... ~ "How source code size is measured" https://benchmarksgame-team.pages.debian.net/benchmarksgame/how-programs-are-measured.html#source-code https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

visarga 2y ago

It all depends on execution time. If you run it just a few times or the total execution time doesn't take days, you can do it faster in Python end-to-end.

KolenCh 2y ago

I have an example to support: https://github.com/hpc4cmb/toast/pull/380/commits/a38d1d6dbcc97001a1ad1c315bb08cf1eecc74c7?diff=unified&w=1 https://github.com/hpc4cmb/toast/pull/380/commits/a38d1d6dbc... A one-liner in Python is replaced by hundreds of lines of changes to implement in C++. (The one-liner has some boilerplates around it too, but the C++ function itself is longer and the boilerplates around is even more.) Edit: 230 additions and 36 deletions in 14 files.

maccard 2y ago
That’s replacing one line which calls a a third party dependency with a manual implementation in native code.
- KolenCh 2y ago
  Technically right, but the original code only optionally depends on Numba, and Numpy is ubiquitous in scientific Python. The problem I was trying to solve in all those boilerplates is basically that Numpy still has overhead and dropping it to lower level is trivial if Numba is used, but the package maintainers doesn’t want to introduce Numba dependency for various reasons. And the diff is showing that change from Numpy/Numba to C++ with pybind11.
  - maccard 2y ago
    That doesn't change the fact that it's not representative of how many lines something takes in python vs C++. If you replaced it with a call to native that used a third party library it would be back to being one line.
    - KolenCh 2y ago
      First, no sane mind will think one single example will be representative to anything. Second, if you want to focus on 3rd party or not, sure. But you could also think Numba jit vs C++ and in this case it puts them on a more equal footing to compare them. As far as Numba is concerned, numpy is in its stdlib as it aren’t calling Numpy but jit compile it. You may say Numba is not Python, true, but you could consider Numba an implementation of a subset of Python. We can argue about the details but the example is not that long to read. My summary and your summary are both at best distilled through our own point of view a.k.a. biases. Anyone can read the diff itself to judge. That’s why I link to it.