3 ms·

> For me, one of the points that this article seems to imply is that modern hardware can be extremely fast, but in our efforts to save "programmer time", we've

by exDM69 12y ago

> For me, one of the points that this article seems to imply is that modern hardware can be extremely fast, but in our efforts to save "programmer time", we've sacrificed an order of magnitude or more of that. There's still plenty of reasons to write fast code. If the code ends up being run repeatedly and is known to be the bottleneck, optimizing a piece of code may save on hardware costs. And power and cooling costs. Or if we're talking about a mobile device, doing something quickly and then powering off the CPU will save a lot of those precious milliwatts. (I do this in my day job) In this case, there was a 10x improvement in the time it takes, allowing the CPU to be powered off for 2 seconds. That translates to longer battery life and happy customers. While you're right in that CPU time is usually cheaper than programmer time, there's still a time and a place for writing fast code. Computers may be "fast enough" but the hardware is still expensive and the power it consumes is more important than ever.

Cthulhu_ 12y ago
Re: last paragraph, I agree; however, it's a cost / benefit thing. I work as a consultant, and while I want to make the most optimal software ever on the one hand, my customer also wants features. The more you optimize, the harder it gets and the more maintenance you'll need to do. It all depends on how much time (and money) you want to invest in optimization vs features.
- exDM69 12y ago
  > Re: last paragraph, I agree; however, it's a cost / benefit thing. Performance optimization is most definitely a cost/benefit trade off thing. In your business as a consultant, it will almost never make sense to optimize for performance. On the other hand, in my business (sw engineering for the semiconductor industry), performance and power consumption are some of the primary criteria our customers (consumer product manufacturers) make the choice between our product and our competitor's product. In our case, performance is a feature (if not the feature). Most software engineers probably fall in to the former category and do not have to care about performance of the software they write. But it is dangerous to think that it would always be the case, and especially harmful to think that educational articles like the OP are wasted programmer time. Especially given that OP seems to be focused in low level operating system development, and who wouldn't want their operating systems, browsers, etc faster.

by exDM69 12y ago

Cthulhu_ 12y ago

Re: last paragraph, I agree; however, it's a cost / benefit thing. I work as a consultant, and while I want to make the most optimal software ever on the one hand, my customer also wants features. The more you optimize, the harder it gets and the more maintenance you'll need to do. It all depends on how much time (and money) you want to invest in optimization vs features.

exDM69 12y ago
> Re: last paragraph, I agree; however, it's a cost / benefit thing. Performance optimization is most definitely a cost/benefit trade off thing. In your business as a consultant, it will almost never make sense to optimize for performance. On the other hand, in my business (sw engineering for the semiconductor industry), performance and power consumption are some of the primary criteria our customers (consumer product manufacturers) make the choice between our product and our competitor's product. In our case, performance is a feature (if not the feature). Most software engineers probably fall in to the former category and do not have to care about performance of the software they write. But it is dangerous to think that it would always be the case, and especially harmful to think that educational articles like the OP are wasted programmer time. Especially given that OP seems to be focused in low level operating system development, and who wouldn't want their operating systems, browsers, etc faster.