3 ms·

In the real world, your application is running in a container among hundreds or thousands of other containers. The system's resources are also probably being ma

In the real world, your application is running in a container among hundreds or thousands of other containers. The system's resources are also probably being managed by a hypervisor. The CPU is shared among N tenants _and_ is overcommitted. When I read this, I thought the rest of your post would go entirely differently. As in, I immediately agreed with you, only for you to "turn this 180" (according to how I think about this at least :) ) It's not that much to ask to optimize where you can, when it isn't unreasonably difficult. You take the above to mean we should optimize such that L2 cache is used as per the post as much as possible. Optimize the wazoo out of things. But how does that even help in any way, when the CPU this runs on is like you said shared among N tenants and your carefully optimized L2 cache access is still going to be miss because another tenant got "your" CPU in between? If you're paying for bare metal i.e. have the whole instance for yourself, by all means, if your domain actually requires you to use the system in such a way (things like high frequency trading come to mind), then optimize like that! If you're running on seventeen levels of hypervisors that destroy any careful optimization in a random fashion anyway, then what's the point even? (non rhetorical question!)

kbelder 2y ago
It's a version of the tragedy of the commons. Yes, your software bloat isn't the main factor keeping you slow, and cleaning it up might be barely perceptible. But... all the other software makes the same decision. Then, suddenly, everything on the computer is running at 10% efficiency. In a complex, multitasking environment, keeping your code clean benefits other tasks as much or more than your own. It should be considered a responsibility.
- tharkun__ 2y ago
  I would agree with the sentiment but not necessarily the conclusion. Like, don't use (the equivalent of) Stooge Sort (for your particular situation). But unless you are in a very particular situation, it should be OK for everyone to "just use your language's built-in sort function" (hopefully that's a thing and you don't use something where you need to roll your own even in 2024) assuming that it uses a sane default like quicksort or merge sort that will work perfectly fine for most regular common situations. Another example might be to not stupidly build slow algorithms saying "this won't see much data anyhow" (yes, I've seen that in PRs unfortunately) when a very simple hash lookup will ensure it's fast all the time. But it should be totally fine to assume that your language's hash table implementation is fine for common situations and you don't need to optimize anything unless you're a very special case.

kbelder 2y ago

It's a version of the tragedy of the commons. Yes, your software bloat isn't the main factor keeping you slow, and cleaning it up might be barely perceptible. But... all the other software makes the same decision. Then, suddenly, everything on the computer is running at 10% efficiency. In a complex, multitasking environment, keeping your code clean benefits other tasks as much or more than your own. It should be considered a responsibility.

tharkun__ 2y ago
I would agree with the sentiment but not necessarily the conclusion. Like, don't use (the equivalent of) Stooge Sort (for your particular situation). But unless you are in a very particular situation, it should be OK for everyone to "just use your language's built-in sort function" (hopefully that's a thing and you don't use something where you need to roll your own even in 2024) assuming that it uses a sane default like quicksort or merge sort that will work perfectly fine for most regular common situations. Another example might be to not stupidly build slow algorithms saying "this won't see much data anyhow" (yes, I've seen that in PRs unfortunately) when a very simple hash lookup will ensure it's fast all the time. But it should be totally fine to assume that your language's hash table implementation is fine for common situations and you don't need to optimize anything unless you're a very special case.