> The case for sacrificing flexibility for performance microptimizations gets weaker by the day, and it's certainly not worth the transitions cost I'm at loss

> The case for sacrificing flexibility for performance microptimizations gets weaker by the day, and it's certainly not worth the transitions cost I'm at loss here -- how is micro-optimization not necessary anymore? Both the CPU, the FSB and the DRAM hit {G,M}Hz barrier. The /only/† advance in performace we are getting those days are `horizontal' scaling (more cores) and micro-optimizations like better branch prediction, prefetch etc. And yes, better compilers. Note how every other generation of various busses flip-flop between serial (for increased signaling speed) and parallel (for increased bandwith) transmission. In short: the silicone free lunch is over, probably until we get abundant memristors or something. What we need is to help the CPU execute our code, which has a lot to do with reducing cache misses. Get rid of ELF shlib indirections like GPT, lessen amount of paging metadata to lessen amount of TLB misses, simplify run-time dynamic linking etc., etc.. I guess some will shift to static linking some libraries, to get rid of indirection and unused code. IIRC MPlayer already provides some ./configure option(s?) for statically linking some libs exactly to get better performance. Besides, when you think at the scale of Google or FB, one microsecond optimization multiplied by the sheer number of the CPUs they burn adds up to significant money. > another incompatible ABI change would kill linux dead. a.out to ELF32 was handled just fine, and ELF32 to ELF64 is going pretty well. What is your point? †aside of HDD -> SSD transition, which is of mechanical -> solid state nature.