From mboxrd@z Thu Jan 1 00:00:00 1970 Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <443A6716.5020801@lanl.gov> References: <443A6716.5020801@lanl.gov> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9B80B8DA-2156-4219-8EFF-D3DF15DA7208@telus.net> Content-Transfer-Encoding: 7bit From: Paul Lalonde Subject: Re: [9fans] Good enough approximation for ape/pcc Date: Mon, 10 Apr 2006 07:49:24 -0700 To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Topicbox-Message-UUID: 343206d2-ead1-11e9-9d60-3106f5b1d025 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10-Apr-06, at 7:09 AM, Ronald G Minnich wrote: > > There's lots of other bad stuff that happened too. Linker-sets, for > example. Or, oh, the stuff like: > if (likely(a != b)) {eatme();} Although I'm willing to claim that branch prediction hints do belong somewhere, although probably in only in assembly. One processor I'm dealing with has something like a 19 cycle branch miss penalty, on a machine where it's memory is only 7 cycles away, and with 4-way SIMD-in-a-word stuff. You can put your entire loop into those 19 cycles, and the compiler had better get the (explicit, coded, not predicted) branch hint right. I have a piece of TLB-like code that likewise needs the common case to be detected for "free" for efficiency (12 cycle lookup for a hit, >2000 for a miss), and the compiler does get it wrong, there being no loop involved. Yuck. What's the right high-level way to deal with branch prediction? I'm guessing there isn't one... Worst quote from Sony: "Think in assembler, but code in C++" Paul -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEOnB1pJeHo/Fbu1wRAs8nAJ0W/5NJTZa5mWz3FLT33JcF2l8UWgCgvEv3 ILl+kIjLRWTJlsnBlMM/3Ig= =yMJR -----END PGP SIGNATURE-----