3 ms·

The problem is I think you're also disagreeing with yourself in a way. > That is not our job! Our job is to solve business problems within the constraints we a

The problem is I think you're also disagreeing with yourself in a way. > That is not our job! Our job is to solve business problems within the constraints we are given. No one cares how well it runs on the hardware we're given. They care if it solves the business problem. Look at Bitcoin, it burns hardware time as a proof of work. That solves a business problem. Cost is a business problem. It is a constraint. The problem is sometimes it doesn't feel that way because a lot of folks around you use bad practices and it's easy to horizontally scale things so performance is often brushed off. Now that the era of 0% interest has ended, companies are actually starting to take a look at what they're running and... surprise! Taking even 10% longer to write quality, performant code can yield 2-3x (sometimes I've seen 1000x) improvements which means much lower cost. > Some programmers work in industries where performance is key but I'd bet not most. Because most don't know any better. Unfortunately this is a symptom of bootcamps, etc. that have created a lot of "programmers" that only know how to code vs. "engineers" that know how to build systems that are maintainable, scale, and solve complex problems. In almost every company I've been at they inadvertently retroactively look back and realize how wasteful they were. In the ML world at least, it's a bit different I suppose because performance matters from the start.

xupybd 4y ago
> Cost is a business problem. It is a constraint I 100% agree. What I'm trying to get across is that you have to identify the cost to justify the performance tuning. If the cost of the tuning is greater than the cost incurred by not doing you might not want to do it. What are your actual costs and how do they line up? Are you writing ML and big data then processing costs are huge. You can probably win by spending money on developer time to reduce processing costs. On the opposite end of the scale are you writing CRUD for a small business, then the development costs are likely to outweigh any costs from inefficiencies in the applications code. To me the article read as if our job was to make every bit of code as fast as possible. I think we should only spend time on code that meets the greater goals of the system it operates in. If you identify that run time is a cost then you have to identify what part of the code is the bottle neck and fix that. Then you have look back to see if any more improvements will be worth the time invested.
- sakras 4y ago
  > To me the article read as if our job was to make every bit of code as fast as possible. My interpretation was that he thinks the baseline for performance is too low. There are kind of two parts to performance: non-pessimization and optimization. He’s mostly harping on the former point, that you don’t have to go tuning anything. Just by writing code without following the clean code rules you can get a huge speed up for free, without any tuning at all. It’ll be free of obvious overheads, even if it doesn’t do anything special to fully utilize the hardware.
- inkblotuniverse 4y ago
  There are 1000x gains on the table! Almost all software is so far from pareto-optimal it's comical! It isn't a tradeoff between readability and efficiency, most software is unreadable and inefficient! When every function in your program is virtual, fixing bottlenecks won't give you a significant speedup. You don't need to optimize programs to make them 1000x faster, we just need to stop shooting ourselves in the foot.

xupybd 4y ago

> Cost is a business problem. It is a constraint I 100% agree. What I'm trying to get across is that you have to identify the cost to justify the performance tuning. If the cost of the tuning is greater than the cost incurred by not doing you might not want to do it. What are your actual costs and how do they line up? Are you writing ML and big data then processing costs are huge. You can probably win by spending money on developer time to reduce processing costs. On the opposite end of the scale are you writing CRUD for a small business, then the development costs are likely to outweigh any costs from inefficiencies in the applications code. To me the article read as if our job was to make every bit of code as fast as possible. I think we should only spend time on code that meets the greater goals of the system it operates in. If you identify that run time is a cost then you have to identify what part of the code is the bottle neck and fix that. Then you have look back to see if any more improvements will be worth the time invested.

sakras 4y ago
> To me the article read as if our job was to make every bit of code as fast as possible. My interpretation was that he thinks the baseline for performance is too low. There are kind of two parts to performance: non-pessimization and optimization. He’s mostly harping on the former point, that you don’t have to go tuning anything. Just by writing code without following the clean code rules you can get a huge speed up for free, without any tuning at all. It’ll be free of obvious overheads, even if it doesn’t do anything special to fully utilize the hardware.
inkblotuniverse 4y ago
There are 1000x gains on the table! Almost all software is so far from pareto-optimal it's comical! It isn't a tradeoff between readability and efficiency, most software is unreadable and inefficient! When every function in your program is virtual, fixing bottlenecks won't give you a significant speedup. You don't need to optimize programs to make them 1000x faster, we just need to stop shooting ourselves in the foot.