3 ms·

So I guess a bigger question is, how do you reconcile old thinking with new? You can’t really program everything to use big blocks of virtual memory that are f

So I guess a bigger question is, how do you reconcile old thinking with new? You can’t really program everything to use big blocks of virtual memory that are file backed. And you can’t program everything to be cache oblivious. So is the only real solution to implement naive solutions until they’re slow and test them until they’re not? That would be sort of a sad way to write software, but perhaps it is the only true way, since it’s the most widely applied and pragmatic practice. Further, if all of this really is true, which I’m sure it is, then APIs and languages have not caught up, not developers. Because we’re all still writing software with what’s provided to us, and last time I checked, we didn’t have access to black box caching implementation details, or direct access to L1, L2, L3, etc.

phkamp 5y ago
Ohh, one of the hard questions :-) Personally, I think the cache oblivious thing was oversold, all the algorithms I have seen are horribly complex and thus only an improvement if your N is so big as to overshadow the constant terms in O(...) we usually ignore. Patenting and expecting to become stinking filthy rich on the licensing fees, was another good way to prevent them from being used. I think the best we can do is probably still making sure we know what we are trying to do, and what we are not going to do, and then architect accordingly. That is of course really just a fancy way of saying "it depends", but I'm OK with that: Magic silver bullets are not a thing.