I think its true, but also that we all use existing hardware kit longer than we did 5/10/15/20 years ago.
"Software is getting slower more rapidly than hardware becomes faster."
61–70 of 193 posts
Re: "Software is getting slower more rapidly than hardware becomes faster."
#62Hardware is interesting now that Moore's Law (or Dennard scaling) has flatlined 10 years ago--are college courses now taught any differently because of this? It's a significant issue of computational resources in that we can't assume exponential transistor density anymore.
Re: "Software is getting slower more rapidly than hardware becomes faster."
#63Here's a little old fart story from more than 25 years ago.
We'd been working on a hardware product and put a fair bit of effort into optimizing something that had to be done 1M times at startup, getting it down to a few seconds, in theory.
Software comes to complain that it's grossly inefficient and takes forever. Investigate. Well. They're running a 1M iteration loop and then calling down through something like a dozen layers of object oriented subroutines, constructors and destructors and all, to execute the hardware primitive, one at a time.
So I crack the PowerPC (this is ancient history, remember) manual and write a bit of assembly language. See here, I can get it done in 2.5 seconds!
That's ridiculous! We can't block for 2.5 seconds in a subroutine call.
Well how long can you? Oh. Well, then call it 100 times and do 10K iterations each time. So they did that, and problem solved.
That's because we still had full-stack expertise. Everything was in house.
These days, complexity is so vast that you simply can't afford to own the full stack any more. And so gross inefficiencies like the above creep in and there's simply nobody around to understand, much less fix them.
The same thing is briefly alluded to in my brother's video about the early days at Research in Motion (https://youtu.be/GLxjXP-XCJA). Talk about full stack. He spent a huge amount of time just working out how to extract every last millijoule out of an alkaline AA cell. And stopping software developers from introducing inefficiencies like the above. Full stack! And the RIM 950 really was an awesome gadget, running, if I recall correctly, for two weeks on that measly AA battery. Simply not possible if you're just bolting together re-usable pieces from different sources.
Re: "Software is getting slower more rapidly than hardware becomes faster."
#64I've been saying for a while now, that developers and their managers should use a low-spec machine, let's say the 5th-percentile of whatever their users are using in the field, at least one day a week. This might force some reprioritizing of performance and efficiency goals. As long as devs spend their days with bugattis while writing software for corollas, this will continue to get worse.
I hate this for developers. I got to experience this first hand because I had a boss who thought like you. Developers generally need to run a bunch of resource intensive tools to build the application in the first place, so an underpowered system will already be choking. It means their app will feel slow no matter what. So then when they run it and it's slow, they will shrug and say it's just slow because their syste…
Actually having to develop (browser, IDE, compilers, etc) on a slow machine is pointless torture, but I do see the value in the app that you're building running in a resource constrained VM or equivalent. That way your dev experience is crisp, but you get a more realistic sense of how your application functions for the end user.
Re: "Software is getting slower more rapidly than hardware becomes faster."
#65Is this really true that software is getting slower? I've been using a budget Windows 10 desktop lately, and I'm shocked by how fast everything is running: ESRI ArcGIS, Firefox, code editors, etc. I remember having a budget desktop PC back in the mid 2000's and it was a significantly worse experience on very basic workflows (Excel, regular web browsing, etc)
Agreed. Between SSDs, blazing faster home DSL internet, and multicore processors, using a computer is much faster than it's ever been before. Sure there's more software bloat, and webpage bloat, but if anything the overall user experience has gotten faster . And that's even with resource hogs like Retina displays and 4K video. Like, go look up YouTube videos of people using older systems (not VM's). A Mac in 1989 tak…
Counter argument - HN post from 6 months ago:
"Windows NT on 600MHz machine opens apps instantly. What happened?"
Re: "Software is getting slower more rapidly than hardware becomes faster."
#66I've been saying for a while now, that developers and their managers should use a low-spec machine, let's say the 5th-percentile of whatever their users are using in the field, at least one day a week. This might force some reprioritizing of performance and efficiency goals. As long as devs spend their days with bugattis while writing software for corollas, this will continue to get worse.
In some big business companies this is solved by pre-installed "security software" that usually takes up about half of the RAM, sometimes even more, and is using a measurable chunk of CPU all the time.
Re: "Software is getting slower more rapidly than hardware becomes faster."
#67Earlier quoted context omitted.
Have testers not suffered enough?! It's the devs that need the slow machines -- they're in the tightest feedback loop, and directly empowered to optimize performance.
Optimizing performance is very nontrivial and often means writing custom stuff, which will deeply affect TCO. It’s fine for devs to sympathize with users, but in the most ultimate perspective the users are actual or potential customers of the business and not your clients. In other words, the business should have ultimate authority and responsibility to structure incentives and pursue priorities. Up until the enginee…
In enterprise software, optimizing performance usually means removing the custom stuff.
Re: "Software is getting slower more rapidly than hardware becomes faster."
#68Is this really true that software is getting slower? I've been using a budget Windows 10 desktop lately, and I'm shocked by how fast everything is running: ESRI ArcGIS, Firefox, code editors, etc. I remember having a budget desktop PC back in the mid 2000's and it was a significantly worse experience on very basic workflows (Excel, regular web browsing, etc)
Well now I need to know what that machine is
Re: "Software is getting slower more rapidly than hardware becomes faster."
#69Anecdotally this does not apply to my laptop from 2014. It was born with a HDD and upgraded to SSD a couple of years later. It still feels fast enough and, more up to the point, it doesn't feel to get any slower by the years. Actually it's getting faster and that was the feeling I had with my previous laptop from 2006. OK, I've been using Linux on them since January 2009, so no Microsoft software (but Teams is slow,…
> Anecdotally this does not apply to my laptop from 2014.
It doesn't apply to anyone device, this is a comparison of generation over generation changes. Your 2014 laptop is closer to a 2018 laptop than 2014 software is to 2018 software.
Re: "Software is getting slower more rapidly than hardware becomes faster."
#70Earlier quoted context omitted.
Have testers not suffered enough?! It's the devs that need the slow machines -- they're in the tightest feedback loop, and directly empowered to optimize performance.
Optimizing performance is very nontrivial and often means writing custom stuff, which will deeply affect TCO. It’s fine for devs to sympathize with users, but in the most ultimate perspective the users are actual or potential customers of the business and not your clients. In other words, the business should have ultimate authority and responsibility to structure incentives and pursue priorities. Up until the enginee…
It may be non-trivial to dig yourself out of a performance hole if you didn’t account for performance at all in the design. The pervasive idea that you can make it fast later virtually never pans out.
In many cases, taking performance into account up front adds little overhead and won’t appreciably affect the design. But, if you codify some algorithmically inefficient approach into your public API, you’re going to find that hard to unwind. The engineering team should advocate for that when designing the product.