6 ms·
>It simply cannot be the case that we're willing to give up a decade or more of hardware performance just to make programmers’ lives a little bit easier. Our jo
by xupybd 4y ago
>It simply cannot be the case that we're willing to give up a decade or more of hardware performance just to make programmers’ lives a little bit easier. Our job is to write programs that run well on the hardware that we are given. If this is how bad these rules cause software to perform, they simply aren't acceptable.
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.
Some programmers work in industries where performance is key but I'd bet not most.
CPU cycles are much cheaper than developer wages.
- dgb23 4y agoWell yes it kind of is? Everyone solves problems. We solve problems with computers. And we use them because they’re autonomous, remember exact details and are very fast and reliable. There’s of course some level of good enough. We don’t write ad-hoc scripts in assembly. But to say dev time is more expensive than computer time only makes sense if programs are actually fast. Fast, reliable feedback loops matter. Consistency matters. And simplicity matters in many dimensions. Web application servers that are orders of magnitude (N times) slower than they should be (not even _could_ be) cost us N times more hardware resources, N times more architectural complexity that require specialized workers and tools and so on. Speed and throughout matter for productivity. Not just ours but our user’s as well. Good performance is important for good UX. Wasting fewer cycles opens up opportunities to do meaningful things.
- danuker 4y ago> and are very fast and reliable. Among the most popular languages is Python. It is popular in spite of its bad performance, high memory use, and lack of CPU multithreading. And it is heavily ran on servers. Why? Because running Python apps is still much cheaper than hiring humans to wait for calls or manage e-mails. Humans are valuable. They should not be working on easily automatable problems. The bottleneck is automating AT ALL, rather than automating with a low machine cost. Only at huge scale (i.e. Big Tech with billions of daily events) does it warrant to optimize the code. Of course, assuming you have a sane computational complexity. If you don't, it doesn't matter which paradigm you use.
- dgb23 4y agoI think you’re right what you said. But the gist of the video doesn’t disagree at all. In fact the resulting code was very clear, easy to write and understand. He got a 15x improvement by removing indirection and OO cruft. I don’t think he’s saying “don’t use language X” here, but rather “don’t make it harder for yourself and the computer”.
- danuker 4y agoBut it does disagree. Python is a dynamic language where essentially everything is indirect (an object). Hardcoding types and methods (so they compile to simple/fast machine code as the video proposes) takes away flexibility (but you can do that with Cython by the way, but it is not nearly that popular).
- dgb23 4y agoI don’t know/use python. But I assume that it has hasmaps and vectors that are backed by something performant and possibly JITed? The table driven, static dispatch approach Muratori isn’t necessarily “hard coded” in the general case. It’s just data driven, or table driven as he puts it. It’s not less flexible as you can easier add (append!) new cases. In fact it reminds me of how I do it in higher level languages like JS and Clojure. Of course we’re paying a substantial performance tax when using higher level, dynamic languages. We’re paying that tax in order to get very tangible benefits. But we can still program in a way that is data oriented, simple and easy to work with by the compiler and runtime (JIT).
- alfalfasprout 4y agoOK but... computationally heavy code in Python isn't generally really running in Python. Almost all of it either calls out to optimized C/C++/Fortran (eg; Numpy which in turn calls BLAS+LAPACK) or do that or some other separate compilation (eg; what ML libraries do with XLA, etc. or cython). Sure, python web servers are a thing. Heck, we use them a fair bit. But it's a deliberate decision from the start where it makes sense to use it for that purpose.
- itake 4y agoI think there are some ethical aspects of this that are missing. Writing in efficient code has an environmental impacts and a human impact. I still lean heavily towards clean code, because clean is easier to Grep and bugs have a much higher impact to my career, but efficiency imho should be addressed in the language or compiler, not in the code.
- jiggawatts 4y ago> CPU cycles are much cheaper than developer wages. Please just stop with this. It's plainly false. At $dayjob I recommended some simple database query tuning that 1 developer applied in their spare time. This improved performance from 9 seconds per page to 500 milliseconds per page. That customer wanted to use auto-scale to expand capacity (nearly 20-fold!) to meet the original requirements, which would have cost about $250K annually. The dev fixed the issue in like... a week. What developer costs $250K per week!? None. None do. Not even the top tier at a FAANG. Not to mention the time saved for the thousands of users that use this web application. Their wasted time costs money too.
- xupybd 4y agoIn this case you have massive scale so a small amount of developer time can equate to a big reduction in CPU cycles. Those are the constraints you work with. Those are the business problems you are solving. So yes this was justified. It was justified on the numbers. My point is that your job is only to tune performance iff there is a solid business case for it. I spent a week reducing a pages load time because the busines saw the load times as a problem for customer acquisition. The cost of my time was justified. Meanwhile we had a task that for 6 years took over an hour to run. I optimized it to take less than a second. That change has offered zero business value and was a waste of time. It runs periodically on a server that is most often idle. There was no justification for that work, other than it taught me to align my efforts with the business. CPU cycles are much cheaper than developer hours. But yes, if you have enough of them yes they will cost more than a developer.
- jay_kyburz 4y ago>My point is that your job is only to tune performance if there is a solid business case for it. I think its very very hard to put a cost on performance. A few seconds here or there is very draining on people. How do you measure if people are avoiding doing things, or putting off work because their tools are janky. How do you measure how much time people spend complaining about how slow their computer is?
- 4y ago
- adamrezich 4y agoeverything with computers being slow and janky these days despite running on hardware that we could have only dreamed of mere decades ago is somebody's fault—if not ours, then whose? you can only excuse-kick the blame-can down the time-road so far.
- loup-vaillant 4y ago> CPU cycles are much cheaper than developer wages. CPU cycles are cheap. Dev time is expensive. User time is sacred. https://www.lesswrong.com/tag/scope-insensitivity https://www.lesswrong.com/tag/scope-insensitivity
- xupybd 4y ago>User time is sacred. Why? What if the user is a machine operator? He is standing around waiting for the machine to finish it's current cycle. As long as he can get his data entry done in the time he is waiting it costs the business nothing.
- _aavaa_ 4y agoI am not sure how to explain that "user time is sacred" is from the point of view of the user, not of the business where the user is treated as a cog in a machine.
- loup-vaillant 4y agoIt's a game of numbers. Few developers, many users. The more users you have the more sinful it is to waste their time. But we don't realise it because we have no idea how harmful it really is to waste a few seconds a day for millions of users.
- halayli 4y agoSounds like someone stuck in their bubble.
- xupybd 4y agoThis is exactly the point. Each bubble has different goals. For example: The finance industry heavily uses Excel the inefficiencies this brings to performance are huge. However, the ability to get a domain expert to maintain the 'code' is worth it. There are always trade offs. Even if you are in a performance sensitive industry your job is still not to write the most efficient code possible. You are there to make the best use of the resources you have to produce the best product you can. Sometimes that will mean doing things that harm performance but help in other ways.
- alfalfasprout 4y agoThe 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.
- timeon 4y ago> That is not our job! Our job is to solve business problems within the constraints we are given. > Look at Bitcoin, it burns hardware time as a proof of work Sounds to me like the job needs other constraints in form of regulations then.
- DeathArrow 4y ago>CPU cycles are much cheaper than developer wages. But using "clean code" and SOLID does not make the code faster to write, easier to maintain. It makes it harder to reason about and slower.