From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Fri, 18 Feb 2011 12:21:33 -0500 To: 9fans@9fans.net Message-ID: <7769a67a9fbc1fae2186ff9315457e0d@ladd.quanstro.net> In-Reply-To: References: <201102181445.41877.dexen.devries@gmail.com> <201102181753.30125.dexen.devries@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: b0da4636-ead6-11e9-9d60-3106f5b1d025 > > i wonder if that is uniformly faster.  consider that > > making reads of that page coherent enough on a > > big multiprocessor and making sure there's not too > > much interprocesser skew might be slower than a > > system call. > > Real world tests show that it is consistently faster. It's probably > cached anyway. as andrey points out that's exactly the problem if you want an accurate time. also, while making gettimeofday() faster, you potentially invalidate BY2PG/BY2CL cachelines on *every* processor in the system. this has the real potential for being a problem on, say, a 256 processor system and making everything else on the system slower. linux optimization is a ratrace. you are only judged on the immediate effect on your subsystem, not the system as a whole. so unless you play the game, your system will appear to regress over time as other optimizers take resources away from you. there aren't many processor arm systems yet, but on such a system, the os will need to do the equivalent of cachedinvse() and l2cacheuwbinvse often enough to make the timing look reasonable. - erik