3 ms·

> It’s actually dominated by the time complexity of the code running on it. No. Please read the paper I posted. It’s the language.

saagarjha 3y ago
I’ve read it; it’s a garbage paper. I don’t fault the authors for doing the study but applying the results to anything in reality is almost tantamount to malpractice. It just means AWS people go up on stage and make fools of themselves pushing Rust for environmental impact or people like you try to explain how iOS apps kill your battery to one of the few people who actually has worked to optimize this. The first thing we always investigated was doing less work and fixing bad algorithms, followed by very localized language replacement on hot paths, then as a last resort wholesale rewrites. The ratio of these options was close to 90:9:1.
- robomartin 3y ago
  You sound angry. You also sound like you are talking to a bunch of morons who don't understand the difference between time complexity and the computational/implementation realities of different languages. On a personal note, I started my hardware/software development career in the early '80's, writing non-trivial applications in assembly language for a dozen different processors and, of course, designing entire computers from scratch. On from there through languages such as C, C++, Forth, APL, LISP, various Basics and, eventually pretty much all of the "modern" languages. During that time I designed and manufactured custom bit-sliced micro-coded processors with discrete chips in the early days and, PLD/PAL's and, later-on, FPGA's. Sure, I use Python a lot today, yet, I know what I am walking into when I do. I also use lots of C/C++ and, these days, ARM assembler. Slow code that is both time and energy inefficient is a modern reality. Virtually nobody coming out of a typical university CS curriculum today is exposed to coding without objects. Bloated, slow and, yes, high energy-consuming code is almost normal these days. Look at almost any open source codebase for evidence of this. And, frankly, as machines become faster, nobody cares, because inefficient code works just fine. Sometimes I compare it to sailing. When there's lots of wind everyone is a sailor. When wind is minimal, you better know what you are doing. Today people benefit from processors running multiple cores at multi-GHz clock rates with tens of gigabytes of memory and terabytes of storage. Of course that leads to bloat and inefficiency at every level! Why wouldn't it?
  - saagarjha 3y ago
    Yes, that paper does make me angry :) I understand and agree with you that most code that exists today is inefficient and slow, but there is room for "let's after the lowest hanging fruit" in the discussion. Almost all projects these days are object-oriented in some form because complexity demands it. Performance and maintainability for modern software can be at odds along some axes and we pick the latter because our hardware gets better, and we might as well use it for that. That doesn't mean that there aren't places where you can see easy wins or that there isn't horribly inefficient software that ought to be optimized regardless but when you look at the broader picture "let's rewrite everything because it's in an inefficient language" is generally not actually an optimal strategy.

saagarjha 3y ago

I’ve read it; it’s a garbage paper. I don’t fault the authors for doing the study but applying the results to anything in reality is almost tantamount to malpractice. It just means AWS people go up on stage and make fools of themselves pushing Rust for environmental impact or people like you try to explain how iOS apps kill your battery to one of the few people who actually has worked to optimize this. The first thing we always investigated was doing less work and fixing bad algorithms, followed by very localized language replacement on hot paths, then as a last resort wholesale rewrites. The ratio of these options was close to 90:9:1.

robomartin 3y ago
You sound angry. You also sound like you are talking to a bunch of morons who don't understand the difference between time complexity and the computational/implementation realities of different languages. On a personal note, I started my hardware/software development career in the early '80's, writing non-trivial applications in assembly language for a dozen different processors and, of course, designing entire computers from scratch. On from there through languages such as C, C++, Forth, APL, LISP, various Basics and, eventually pretty much all of the "modern" languages. During that time I designed and manufactured custom bit-sliced micro-coded processors with discrete chips in the early days and, PLD/PAL's and, later-on, FPGA's. Sure, I use Python a lot today, yet, I know what I am walking into when I do. I also use lots of C/C++ and, these days, ARM assembler. Slow code that is both time and energy inefficient is a modern reality. Virtually nobody coming out of a typical university CS curriculum today is exposed to coding without objects. Bloated, slow and, yes, high energy-consuming code is almost normal these days. Look at almost any open source codebase for evidence of this. And, frankly, as machines become faster, nobody cares, because inefficient code works just fine. Sometimes I compare it to sailing. When there's lots of wind everyone is a sailor. When wind is minimal, you better know what you are doing. Today people benefit from processors running multiple cores at multi-GHz clock rates with tens of gigabytes of memory and terabytes of storage. Of course that leads to bloat and inefficiency at every level! Why wouldn't it?
- saagarjha 3y ago
  Yes, that paper does make me angry :) I understand and agree with you that most code that exists today is inefficient and slow, but there is room for "let's after the lowest hanging fruit" in the discussion. Almost all projects these days are object-oriented in some form because complexity demands it. Performance and maintainability for modern software can be at odds along some axes and we pick the latter because our hardware gets better, and we might as well use it for that. That doesn't mean that there aren't places where you can see easy wins or that there isn't horribly inefficient software that ought to be optimized regardless but when you look at the broader picture "let's rewrite everything because it's in an inefficient language" is generally not actually an optimal strategy.