4 ms·

I realize this is a "how long is a piece of string" question, but I'm wondering what cost benefits you might realistically see from moving lambdas from Python t

by Joeboy 3y ago

I realize this is a "how long is a piece of string" question, but I'm wondering what cost benefits you might realistically see from moving lambdas from Python to a faster language like Rust? You pay (partly) for execution time so I guess you should see some savings, but I'm wondering how that works out in practice. Worth it?

steveklabnik 3y ago
Here's a fun answer to that question: Rubygems saved infinity money. That is, they got resource usage down to the point where they could move to the free tier. * https://andre.arko.net/2018/10/25/parsing-logs-230x-faster-with-rust/ https://andre.arko.net/2018/10/25/parsing-logs-230x-faster-w... * https://andre.arko.net/2019/01/11/parsing-logs-faster-with-rust-continued/ https://andre.arko.net/2019/01/11/parsing-logs-faster-with-r... (obviously most people will not realize infinity money)
odyssey7 3y ago
This paper is not about lambdas and their typical operations specifically, but it shows that across a variety of tasks, as of 2017, Rust is more environmentally friendly than Python. https://greenlab.di.uminho.pt/wp-content/uploads/2017/09/paperSLE.pdf https://greenlab.di.uminho.pt/wp-content/uploads/2017/09/pap...
- steveklabnik 3y ago
  I am gonna be honest: I hope this paper never gets cited by anyone, ever. There's a number of very weird issues about it, but I don't think what it actually shows is demonstrative of reality, even if it happens to show Rust in a good light.
  - odyssey7 3y ago
    I’d love to know more. Anything you can point to?
    - steveklabnik 3y ago
      A couple of things off the top of my head: The title conflates languages and their implementations. Different implementations prioritize different things. They occasionally do test different implementations, as in the main Ruby distribution vs JRuby, but it is still annoying. The second, and I think largest issue, is that they chose the Language Benchmarks Game as the set of sample programs to test. I do not believe that the kinds of programs in the Language Benchmarks Game are representative of the broader set of software written in most languages. They tend towards math-y, puzzle-style programs, and not CLIs, web applications, GUIs, or anything else. A very specific issue I have is that Typescript and JavaScript are very different in their analysis, and that's very confusing to me, given that all JavaScript is valid TypeScript, and you would execute it in the same way. This may be an artifact of issue #2, which is that the benchmarks game is only as good as the people who wrote the programs, and it's quite possible that the folks who submitted the TypeScript code didn't do as much perf work as the JavaScript code, but it is still a confusing result that's not explained anywhere in the paper. A final one (and this is the one I remember least well, so I may be wrong here) is that it is not reproducible. They do not mention which date they retrieved the programs from the Benchmarks Game, let alone the source code of the program, nor released the scripts that were used to collect the data, though they describe them. This means that these discrepancies are hard to actually investigate, and makes the results lower quality than if we were able to independently verify the results, let alone update them based on what has changed since 2017, which is an increasingly long time ago. In short, I do not think this paper is literally useless, though I think that it does not actually demonstrate its central claim very well, and is difficult to evaluate the actual quality of the results, making it a far weaker result than the title would suggest.
      - odyssey7 3y ago
        Thanks for writing all of that out! I appreciate the analysis.
        igouy 3y ago
        Alternatively https://news.ycombinator.com/item?id=38463579 https://news.ycombinator.com/item?id=38463579
Matthias247 3y ago
Instrument your python code and gather metrics. Maybe use a profiler. If it is heavily CPU limited and it spends all time in python interpreter calls it might benefit from moving to a more efficient language. It it’s mostly waiting on IO (eg remote services) it might be a negligible difference.

by Joeboy 3y ago

steveklabnik 3y ago

Here's a fun answer to that question: Rubygems saved infinity money. That is, they got resource usage down to the point where they could move to the free tier. * https://andre.arko.net/2018/10/25/parsing-logs-230x-faster-with-rust/ https://andre.arko.net/2018/10/25/parsing-logs-230x-faster-w... * https://andre.arko.net/2019/01/11/parsing-logs-faster-with-rust-continued/ https://andre.arko.net/2019/01/11/parsing-logs-faster-with-r... (obviously most people will not realize infinity money)

odyssey7 3y ago

This paper is not about lambdas and their typical operations specifically, but it shows that across a variety of tasks, as of 2017, Rust is more environmentally friendly than Python. https://greenlab.di.uminho.pt/wp-content/uploads/2017/09/paperSLE.pdf https://greenlab.di.uminho.pt/wp-content/uploads/2017/09/pap...

steveklabnik 3y ago
I am gonna be honest: I hope this paper never gets cited by anyone, ever. There's a number of very weird issues about it, but I don't think what it actually shows is demonstrative of reality, even if it happens to show Rust in a good light.
- odyssey7 3y ago
  I’d love to know more. Anything you can point to?
  - steveklabnik 3y ago
    A couple of things off the top of my head: The title conflates languages and their implementations. Different implementations prioritize different things. They occasionally do test different implementations, as in the main Ruby distribution vs JRuby, but it is still annoying. The second, and I think largest issue, is that they chose the Language Benchmarks Game as the set of sample programs to test. I do not believe that the kinds of programs in the Language Benchmarks Game are representative of the broader set of software written in most languages. They tend towards math-y, puzzle-style programs, and not CLIs, web applications, GUIs, or anything else. A very specific issue I have is that Typescript and JavaScript are very different in their analysis, and that's very confusing to me, given that all JavaScript is valid TypeScript, and you would execute it in the same way. This may be an artifact of issue #2, which is that the benchmarks game is only as good as the people who wrote the programs, and it's quite possible that the folks who submitted the TypeScript code didn't do as much perf work as the JavaScript code, but it is still a confusing result that's not explained anywhere in the paper. A final one (and this is the one I remember least well, so I may be wrong here) is that it is not reproducible. They do not mention which date they retrieved the programs from the Benchmarks Game, let alone the source code of the program, nor released the scripts that were used to collect the data, though they describe them. This means that these discrepancies are hard to actually investigate, and makes the results lower quality than if we were able to independently verify the results, let alone update them based on what has changed since 2017, which is an increasingly long time ago. In short, I do not think this paper is literally useless, though I think that it does not actually demonstrate its central claim very well, and is difficult to evaluate the actual quality of the results, making it a far weaker result than the title would suggest.
    - odyssey7 3y ago
      Thanks for writing all of that out! I appreciate the analysis.
      - igouy 3y ago
        Alternatively https://news.ycombinator.com/item?id=38463579 https://news.ycombinator.com/item?id=38463579

Matthias247 3y ago

Instrument your python code and gather metrics. Maybe use a profiler. If it is heavily CPU limited and it spends all time in python interpreter calls it might benefit from moving to a more efficient language. It it’s mostly waiting on IO (eg remote services) it might be a negligible difference.