3 ms·

One point that I wish the article had expanded on is the impact on software development. In a recent speech, John Carmack talks of how the power of the desktop

by waivek 9y ago

One point that I wish the article had expanded on is the impact on software development. In a recent speech, John Carmack talks of how the power of the desktop will never reach mobile. https://m.youtube.com/watch?v=vlYL16-NaOw&t=14m20s https://m.youtube.com/watch?v=vlYL16-NaOw&t=14m20s This is incredibly exciting. I see the end of Moores law as the return of the era of performance-oriented software development. The past decade was ruled by software methodologies which optimised for developer time at the cost of performance. Moores law was the crutch on which such latency ridden software limped into userland. With the stabilization of hardware performance, developers can once again put dedicated time and effort into crafting performant software with the assurance that hardware gains will not render their efforts useless in 2 years.

BoiledCabbage 9y ago
> This is incredibly exciting. I see the end of Moores law as the return of the era of performance-oriented software development. And I see this as the exact opposite. Optimizing for developer time is one of the largest productivity enhancements we have. A true/pure positive feedback loop in technological progress. Optimizing for performance is getting little real gain for large human cost. The end game of optimized for developer efficiency is we can design and implement "anything" we can think of in almost no time flat. The end game for optimizing for performance is it takes significantly longer to develop a program just to run it on the equivalent of 5 years ago hardware. An analogy: it's early in human writing. People have trouble expressing average thoughts. We can either teach society to have a better grasp on writing and expressing complex ideas precisely. Or we can teach people to write really small because we're running out of paper. The positive feedback loop of improved development is enormous.
- waivek 9y ago
  If I may, a rebuttal. The software methodology that has evolved over the last two decades has focused on development time. As such, there has not been much focus/research on performance-first methodologies. I see no reason that developer time cannot be optimized in a performance-first methodology, it's just that a developer time oriented methodology has years of fine tuning in it. An example for this is video game development. If you look at some talks given by Mike Acton, you can see that it is possible to ship a game while optimizing for developer time. A triple A game is arguably one of the most intricate and complex projects under the label of "Software Engineering". I see no reason why we can't learn from such sub-fields and apply it to general software development. I also disagree with you saying that "Optimizing for performance is getting little real gain for large human cost". Not optimizing for performance has had led to the creation of unresponsive text editors, slow word processors and a plethora of other latency-ridden software. This in turn affects the user and unfortunately alters their expectations for software. There is no technological reason why Visual Studio 2017 should not run on a 5 year old laptop, yet that is the state we are in.
  - BoiledCabbage 9y ago
    > If I may, a rebuttal. Of course - when it's performing well, it's what this site shines at. > I see no reason that developer time cannot be optimized in a performance-first methodology Well clearly it can but it won't be nearly as much of a priority. Just like performance isn't as much of a priority when focusing on developer time. It's not clear what you're specifically rebutting in this section. We're both agreeing that developer-performance will improve significantly less in this model. And unresponsive text editor gives at most what a 3x slowdown in performance. Very little of a programmer's time is actually inputting text or data. While let's take the other extreme to show a point: Building a distributed transactional relational data driven application from scratch (because our tools weren't built because people would have been optimizing performance of late 90s hw) would be a 1,000x loss of developer productivity. The scaling factor of productivity just utterly dwarfs human interface performance. > There is no technological reason why Visual Studio 2017 should not run on a 5 year old laptop, yet that is the state we are in. True, but almost everyone would rather 2017 VS not run on a 5 year old laptop, then the best available product right now be Visual Studio 2005 era functionality highly optimized so it can still run on a 5 year old laptop.
    - waivek 9y ago
      If text editors slowed down by 3x, I'd be happy. The latency I am complaining about is orders of magnitude higher than 3x. This is the most rigorous benchmarking that I am aware of: https://pavelfatin.com/typing-with-pleasure/ https://pavelfatin.com/typing-with-pleasure/ Each of those tables show that the difference in performance is not 3x but at least an order of magnitude, if not more. I think this is where our disagreement stems from. Your next point is valid, it would not make sense to develop such an application from scratch. However, I'm not talking about rebuilding from scratch merely prioritizing performance. This can be done by learning from Data Oriented Design where developers give a lot of importance to performance critical issues such as cache locality. This can be done without rewriting our tools from scratch, it just means that the developer will have to understand how memory works. It's not a tools issue, it's a knowledge issue. Your last point on Visual Studio makes me want to re-iterate the core of my argument: Performance and developer time optimizations need not be mutually exclusive.

by waivek 9y ago

BoiledCabbage 9y ago

> This is incredibly exciting. I see the end of Moores law as the return of the era of performance-oriented software development. And I see this as the exact opposite. Optimizing for developer time is one of the largest productivity enhancements we have. A true/pure positive feedback loop in technological progress. Optimizing for performance is getting little real gain for large human cost. The end game of optimized for developer efficiency is we can design and implement "anything" we can think of in almost no time flat. The end game for optimizing for performance is it takes significantly longer to develop a program just to run it on the equivalent of 5 years ago hardware. An analogy: it's early in human writing. People have trouble expressing average thoughts. We can either teach society to have a better grasp on writing and expressing complex ideas precisely. Or we can teach people to write really small because we're running out of paper. The positive feedback loop of improved development is enormous.

waivek 9y ago
If I may, a rebuttal. The software methodology that has evolved over the last two decades has focused on development time. As such, there has not been much focus/research on performance-first methodologies. I see no reason that developer time cannot be optimized in a performance-first methodology, it's just that a developer time oriented methodology has years of fine tuning in it. An example for this is video game development. If you look at some talks given by Mike Acton, you can see that it is possible to ship a game while optimizing for developer time. A triple A game is arguably one of the most intricate and complex projects under the label of "Software Engineering". I see no reason why we can't learn from such sub-fields and apply it to general software development. I also disagree with you saying that "Optimizing for performance is getting little real gain for large human cost". Not optimizing for performance has had led to the creation of unresponsive text editors, slow word processors and a plethora of other latency-ridden software. This in turn affects the user and unfortunately alters their expectations for software. There is no technological reason why Visual Studio 2017 should not run on a 5 year old laptop, yet that is the state we are in.
- BoiledCabbage 9y ago
  > If I may, a rebuttal. Of course - when it's performing well, it's what this site shines at. > I see no reason that developer time cannot be optimized in a performance-first methodology Well clearly it can but it won't be nearly as much of a priority. Just like performance isn't as much of a priority when focusing on developer time. It's not clear what you're specifically rebutting in this section. We're both agreeing that developer-performance will improve significantly less in this model. And unresponsive text editor gives at most what a 3x slowdown in performance. Very little of a programmer's time is actually inputting text or data. While let's take the other extreme to show a point: Building a distributed transactional relational data driven application from scratch (because our tools weren't built because people would have been optimizing performance of late 90s hw) would be a 1,000x loss of developer productivity. The scaling factor of productivity just utterly dwarfs human interface performance. > There is no technological reason why Visual Studio 2017 should not run on a 5 year old laptop, yet that is the state we are in. True, but almost everyone would rather 2017 VS not run on a 5 year old laptop, then the best available product right now be Visual Studio 2005 era functionality highly optimized so it can still run on a 5 year old laptop.
  - waivek 9y ago
    If text editors slowed down by 3x, I'd be happy. The latency I am complaining about is orders of magnitude higher than 3x. This is the most rigorous benchmarking that I am aware of: https://pavelfatin.com/typing-with-pleasure/ https://pavelfatin.com/typing-with-pleasure/ Each of those tables show that the difference in performance is not 3x but at least an order of magnitude, if not more. I think this is where our disagreement stems from. Your next point is valid, it would not make sense to develop such an application from scratch. However, I'm not talking about rebuilding from scratch merely prioritizing performance. This can be done by learning from Data Oriented Design where developers give a lot of importance to performance critical issues such as cache locality. This can be done without rewriting our tools from scratch, it just means that the developer will have to understand how memory works. It's not a tools issue, it's a knowledge issue. Your last point on Visual Studio makes me want to re-iterate the core of my argument: Performance and developer time optimizations need not be mutually exclusive.