This might interest me as someone whose job is the absolute other end of the spectrum, in databases and HLLs. Reason is that I'm concerned with CPU performance and that largely depends on caches (after you've done any algorithmic improvements).
The unqualified claim - may I say lie - that CPU time is cheaper than programmer time was never true and never will be[0] because it depends, it depends on the economics, and a surprising amount of my time has been taken up optimising for speed on multicore modern CPUs. Exactly what other people say isn't worth doing, right up until it is - and it often is.
Optimising for speed often means optimising for caches, and that means optimising for size[1], so I'm going to dive into this guy's stuff.
[0] and I'd ask people to stop repeating it unless the larger context is accounted for.
[1] and cache-friendly access patterns; another issue.
I smile on reading this. I spent well over a decade hand-optimising SQL to do things like shaving a millisecond off a query, or helping (a little) to maintain a proprietary application server in C because it runs so fast we barely needed any servers to support one of the busiest web systems in the world. When you stack up the hardware and electricity costs and general bureaucracy costs of running hundreds of servers day in day out, then these economies do make sense.
As Jeff Atwood famously puts it "performance is a feature", so as any with feature, wether you should invest in it depends on the project and the needs. Sometimes it's worth your time sometimes it's not, only your specs can tell.
I keep telling people that being able to do something in one millisecond is a lot less powerful than being able to do it in one microsecond, especially in a world with Hypothesis and afl-fuzz. There's no such thing as “fast enough.”
I'll be surprised if you learn new things about cache-oblivious algorithm design from BootOS, though.
The unqualified claim - may I say lie - that CPU time is cheaper than programmer time was never true and never will be[0] because it depends, it depends on the economics, and a surprising amount of my time has been taken up optimising for speed on multicore modern CPUs. Exactly what other people say isn't worth doing, right up until it is - and it often is.
Optimising for speed often means optimising for caches, and that means optimising for size[1], so I'm going to dive into this guy's stuff.
[0] and I'd ask people to stop repeating it unless the larger context is accounted for.
[1] and cache-friendly access patterns; another issue.