From owner-freebsd-arch@FreeBSD.ORG Fri Mar 19 14:42:23 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47079106566B; Fri, 19 Mar 2010 14:42:23 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.freebsd.org (Postfix) with ESMTP id D69B78FC1B; Fri, 19 Mar 2010 14:42:22 +0000 (UTC) Received: from c122-106-146-195.carlnfd1.nsw.optusnet.com.au (c122-106-146-195.carlnfd1.nsw.optusnet.com.au [122.106.146.195]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o2JEgFBx016952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Mar 2010 01:42:17 +1100 Date: Sat, 20 Mar 2010 01:42:15 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Scott Long In-Reply-To: Message-ID: <20100320012752.B1181@delplex.bde.org> References: <201003121513.38721.max@love2party.net> <20100313200155.O22734@delplex.bde.org> <20100318.161117.658811636873842325.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: max@love2party.net, rwatson@freebsd.org, freebsd-arch@freebsd.org Subject: Re: likely and unlikely X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 14:42:23 -0000 On Thu, 18 Mar 2010, Scott Long wrote: > On Mar 18, 2010, at 4:11 PM, M. Warner Losh wrote: >> In message: >> Robert Watson writes: >> : >> : On Sat, 13 Mar 2010, Bruce Evans wrote: >> : >> : >> My point is: Handle with care!!! Trust your compiler/CPU >> : >> predictors/... - most of the time, they are smarter than you are ;) >> : > >> : > These macros may have useful 15-25 years ago for i386, i486 and >> : > Pentium1, since CPU branch predictors were either nonexistent or not >> : > so good. After that, CPU branch predictors became quite good. The >> : > macros should have been mostly unused 15-25 years ago too, since they >> : > optimize for unreadability and unwritability. Fortunately they are >> : > rarely used in FreeBSD. They were imported from NetBSD in 2003 where >> : > they are used more (306 instances in 2005 NetBSD /sys vs 28 instances >> : > in 2004 FreeBSD /sys; there are 2208 instances of likely() in 2004 >> : > linux-2.6.10). >> : >> : I think it would be reasonable to expect that people deploy branch >> : prediction macros (as with prefetch, etc) only where there's specific >> : measurements that indicate they are important to have there -- at the >> : very least, pmc data, but ideally also benchmarking data. >> >> They are more useful on architectures where you have branches that >> tell the CPU if they are likely or unlikely to be taken... > > And that's a very good point, one that Bruce really failed to address. Not only > is branch prediction useful for MIPS and ARM, I suspect that it's also useful > for Atom. I addressed it indirectly :-) : The useful use of these macros is limited to: - the 1% or 0.1% of CPUs that are not amd64 or i386 - on these CPUs, the small percentage of code that runs in the kernel (since userland is out of scope for this discussion and much harder to optimize globally since it is much larger) - the small percentage of kernel code that is MD (since these optimizations are very MD and I hope no one one plans to tangle MI code with ifdefs for them) This gives a very small target for optimization and difficulties measuring the effect. Most systems shouldn't spend most of the time in the kernel. It is easy to think of specialized systems which are exceptions but hard to think of any that spend much time in their MD part, except in copyin/out which should already be optimized. Bruce