In most cases, you either optimize the memory, or you optimize the speed of execution.
Having more memory means we can optimize the speed of execution.
Now, the side effect is that we can also afford to be slower to gain other benefits: Ease of development (come in javascript everywhere, or python) at the cost of speed, maintainability at the cost of speed, etc…
So, even though you dont always see performance gains as the years go, that doesn’t mean shit devs, it means the priority is somewhere else. We have more complex software today than 20 years ago because we can afford not to focus on ram and speed optimization, and instead focus on maintainable, unoptimized code that does complex stuff.
You can still have complex code that is optimized for performance. You can spend more resources to do more complex computations and still be optimized so long as you’re not wasting processing power on pointless stuff.
For example, in some of my code I have to get a physics model within 0.001°. I don’t use that step size every loop, because that’d be stupid and wasteful. I start iterating with 1° until it overshoots the target, back off, reduce the step to 1/10, and loop through that logic until I get my result with the desired accuracy.
Of course! But sometimes, most often even, the optimization is not worth the development to get it. We’re particularly talking about memory optimization here, and it is so cheap (or at least it was… ha) that it is not worth optimizing like we used to 25 years ago. Instead you use higher level languages with garbage collection or equivalents that are easier to maintain with and faster to implement new stuff with. You use algorithms that consume a fuck ton of memory for speed improvements. And as long as it is fast enough, you shouldn’t over optimize.
Proper optimization these days is more of a hobby.
Now obviously some fields require a lot more optimization - embedded systems, for instance. Or simulations, which get a lot of value from being optimized as much as possible.
In most cases, you either optimize the memory, or you optimize the speed of execution.
Having more memory means we can optimize the speed of execution.
Now, the side effect is that we can also afford to be slower to gain other benefits: Ease of development (come in javascript everywhere, or python) at the cost of speed, maintainability at the cost of speed, etc…
So, even though you dont always see performance gains as the years go, that doesn’t mean shit devs, it means the priority is somewhere else. We have more complex software today than 20 years ago because we can afford not to focus on ram and speed optimization, and instead focus on maintainable, unoptimized code that does complex stuff.
Optimization is not everything.
You can still have complex code that is optimized for performance. You can spend more resources to do more complex computations and still be optimized so long as you’re not wasting processing power on pointless stuff.
For example, in some of my code I have to get a physics model within 0.001°. I don’t use that step size every loop, because that’d be stupid and wasteful. I start iterating with 1° until it overshoots the target, back off, reduce the step to 1/10, and loop through that logic until I get my result with the desired accuracy.
Of course! But sometimes, most often even, the optimization is not worth the development to get it. We’re particularly talking about memory optimization here, and it is so cheap (or at least it was… ha) that it is not worth optimizing like we used to 25 years ago. Instead you use higher level languages with garbage collection or equivalents that are easier to maintain with and faster to implement new stuff with. You use algorithms that consume a fuck ton of memory for speed improvements. And as long as it is fast enough, you shouldn’t over optimize.
Proper optimization these days is more of a hobby.
Now obviously some fields require a lot more optimization - embedded systems, for instance. Or simulations, which get a lot of value from being optimized as much as possible.