From owner-freebsd-arch@FreeBSD.ORG Sat Mar 13 14:41:07 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 B5BFF106566B; Sat, 13 Mar 2010 14:41:07 +0000 (UTC) (envelope-from matthew.fleming@isilon.com) Received: from seaxch09.isilon.com (seaxch09.isilon.com [74.85.160.25]) by mx1.freebsd.org (Postfix) with ESMTP id 93E4B8FC14; Sat, 13 Mar 2010 14:41:07 +0000 (UTC) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 13 Mar 2010 06:41:07 -0800 Message-ID: <06D5F9F6F655AD4C92E28B662F7F853E021D4D26@seaxch09.desktop.isilon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: likely and unlikely Thread-Index: AcrCs8mioc28j9AzRwiAolnlcr7qfgABnN1b References: <20100312122559.GU8200@hoeg.nl> <20100312124258.GE1738@mole.fafoe.narf.at> <201003121513.38721.max@love2party.net> <20100313200155.O22734@delplex.bde.org> From: "Matthew Fleming" To: "Robert Watson" , "Bruce Evans" Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Max Laier , 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: Sat, 13 Mar 2010 14:41:07 -0000 Apologies for the top-post but this web mail client doesnt know anything = else. I would think that, from a theoretical POV, you also would want to force = branch prediction around optional code thats rarely enabled. We use it = at Isilon for our internal profiling tool, so the execution cost of = compiling in the profiler is minimized unless its turned on, and also = for our logging macros, so that the cost of always compiling in checks = against log predicates is minimized. The only example I remember from Linux was actually a clever one: the = idle thread assumes there is a real thread to schedule, using = likely/unlikely, even though practically speaking they got the = prediction "wrong". The reason is that, if the idle thread is going to = continue to run, the cost of an incorrect branch prediction is not = relevant, but if there is real work to do why waste time on a pipeline = flush due to incorrect prediction. Thanks, matthew -Original Message- From: owner-freebsd-arch@freebsd.org on behalf of Robert Watson Sent: Sat 13-Mar-10 5:47 AM To: Bruce Evans Cc: Max Laier freebsd-arch@freebsd.org Subject: Re: likely and unlikely =20 On Sat, 13 Mar 2010, Bruce Evans wrote: >> My point is: Handle with care!!! Trust your compiler/CPU = predictors/... -=20 >> most of the time, they are smarter than you are ) > > These macros may have useful 15-25 years ago for i386, i486 and = Pentium1,=20 > since CPU branch predictors were either nonexistent or not so good. = After=20 > that, CPU branch predictors became quite good. The macros should have = been=20 > mostly unused 15-25 years ago too, since they optimize for = unreadability and=20 > unwritability. Fortunately they are rarely used in FreeBSD. They = were=20 > imported from NetBSD in 2003 where they are used more (306 instances = in 2005=20 > NetBSD /sys vs 28 instances in 2004 FreeBSD /sys there are 2208 = instances=20 > of likely() in 2004 linux-2.6.10). I think it would be reasonable to expect that people deploy branch = prediction=20 macros (as with prefetch, etc) only where theres specific measurements = that=20 indicate they are important to have there at the very least, pmc data, = but=20 ideally also benchmarking data. Robert N M Watson Computer Laboratory University of Cambridge _______________________________________________ freebsd-arch@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"