Comment by lich_king
5 days ago
I think the boring answer is that we waste computing resources simply because if memory and CPU cycles are abundant and cheap, developers don't find it worth their time to optimize nearly as much as they needed to optimize in the 1980s or 1990s.
Had we stopped with 1990s tech, I don't think that things would have been fundamentally different. 1980s would have been more painful, mostly because limited memory just did not allow for particularly sophisticated graphics. So, we'd be stuck with 16-color aesthetics and you probably wouldn't be watching movies or editing photos on your computer. That would mean a blow to social media and e-commerce too.
I don't actually blame dev laziness for the lack of optimization.
There is certainly a level of "good enough" that's come in, but a lot of that comes not from devs but from management.
But I'll say that part of what has changed how devs program is what's fast and slow has changed from the 90s to today.
In the early 90s, you could basically load or store something into memory in 1 or 2 CPU cycles. That meant that datastructures like a linked list were a more ideal than datastructures like an array backed list. There was no locality impact and adding/removing items was faster.
The difference in hard drive performance was also notable. One wasteful optimization that started in the late 90s was duplicating assets to make sure they were physically colocated with other data loading. That's because the slowest memory to load in old systems came from the hard drive.
Now with SSDs, disk loading can literally be nearly as fast as interactions with GPU memory. Slower than main memory, but not by much. And because SSDs don't suffer as much from random access, it means how you structure data on disk can be wildly different. For example, for spinning disks a b-tree structure is ideal because it reduces the amount of random accesses across the disk. However, for an SSD, a hash datastructure is generally better.
But also, the increase of memory has made tradeoffs a lot more worth it. At one point, the best thing you could do is sort your memory in some way (perhaps a tree structure) so that searching for items is faster. That is in-fact built into C++'s `map`. But now, a hash map will eat a bit more memory, but the O(1) lookup is much more ideal in general for storing lookups.
Even when we talk about the way memory allocation works, we see that different tradeoffs have been made than would be without a lot of extra memory.
State of the art allocators use multiple arenas and memory allocators to allow for multithreaded applications to allocate as fast as possible. That does mean you end up with wasted memory, but you can allocate much faster than you could in days of old. Without that extra memory headroom, you end up with slower allocation algorithms because wasting any space would be devastating. Burning the extra CPU cycles to find a location for allocation ends up being the right trade off.