A lot of good stuff in there

And it's true that as time passes and machines improve, some older optimizations are no longer relevant. For example I took extreme care to avoid generating bsf/bsr on atoms because that was slow as hell while a hand-written version was much faster, to the point of being visible in the end-user's code. Nowadays first-gen atoms have disappeared and that distinction can disappear as well. Similarly, there's a lot of legacy code around to deal with each generation of compiler's misbehavior, like gcc 4.x doing stupidities with __builtin_expect(x, 1) that was turning x to an int and explicitly comparing it to value 1! Some of the complexity of old code does come from the collection of all such bad stuff, and many of us have been happy to fix such performance trouble caused by a single stupidity in a compiler or CPU that was causing 2-3% total performance loss. And code cleanups over time allow to get rid of that stuff, which sometimes can look like pieces of art, by the way, but just no longer relevant art.

Some of us know that such problems are recurring and continue to want to be able to provide solutions to them. Nowadays, with massively multi-core CPUs we're seeing extreme times caused by cache line sharing that happens very easily if you're not careful. I've been used to organize my structs to avoid accidental sharing between areas that are supposed to be accessible from other threads and those which don't for example. And that's just an example. Sometimes you realize that a function call significantly degrades performance just because pushing the return pointer to the stack forces cache writes because in parallel you're holding a lock that another CPU tries to acquire, and since that lock is in the same cache line as the data you're manipulating, every time it wants to read the lock's state, it causes a cache line flush which due to TSO also causes the stack to be written. I'd feel terribly useless by not being able to easily tweak all that when such problems are faced.

And at the same time I totally understand that the vast majority of developers don't want to care about this. A lot of code doesn't need to be finely tuned nor to be performant under specially stressful conditions. But what I like in programming precisely is getting the most from the hardware and making sure my code scales as much as possible. Just for the same reason I wouldn't develop a web browser in C myself and would rather have someone do it in a more suitable language, there would probably be specific points where that person would prefer to rely on low-level optimizations for certain things that are on the critical path and rely on someone doing my job in their preferred language. I think there are jobs for everyone, and when all developers will realize that this should be complementary instead of a competition, we'll have made great progress!

Please read and respond to what I actually wrote.