From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Fri, 18 Feb 2011 10:46:51 PST." References: <201102181445.41877.dexen.devries@gmail.com> <201102181753.30125.dexen.devries@gmail.com> <7769a67a9fbc1fae2186ff9315457e0d@ladd.quanstro.net> From: Bakul Shah Date: Fri, 18 Feb 2011 11:15:09 -0800 Message-Id: <20110218191509.552355B77@mail.bitblocks.com> Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: b112c290-ead6-11e9-9d60-3106f5b1d025 On Fri, 18 Feb 2011 10:46:51 PST Rob Pike wrote: > The more you optimize, the better the odds you slow your program down. > Optimization adds instructions and often data, in one of the > paradoxes of engineering. In time, then, what you gain by > "optimizing" increases cache pressure and slows the whole thing down. You need a feedback loop. Uncontrolled anything is a recipe for disaster. Optimizations need to be `judicious' but that requires experience, profiling and understanding but the trend seems to be away from that..... On a slightly different tangent, 9p is simple but it doesn't handle latency very well. To make efficient use of long fat pipes you need more complex mechanisms -- there is no getting around that fact. rsync & hg in spite of their complexity beat the pants off replica. Their cache behavior is not very relevant here. Similarly file readahead is usually a win. > C++ inlines a lot because microbenchmarks improve, but inline every > modest function in a big program and you make the binary much bigger > and blow the i-cache. That's a compiler fault. Surely modern compilers need to be cache aware? ideally a smart compiler treats `inline' as a hint at most, just like `register'.