Date: Sat, 13 Mar 2010 06:41:07 -0800 From: "Matthew Fleming" <matthew.fleming@isilon.com> To: "Robert Watson" <rwatson@FreeBSD.org>, "Bruce Evans" <brde@optusnet.com.au> Cc: Max Laier <max@love2party.net>, freebsd-arch@freebsd.org Subject: RE: likely and unlikely Message-ID: <06D5F9F6F655AD4C92E28B662F7F853E021D4D26@seaxch09.desktop.isilon.com> References: <hndbed$vok$1@dough.gmane.org> <20100312122559.GU8200@hoeg.nl> <20100312124258.GE1738@mole.fafoe.narf.at> <201003121513.38721.max@love2party.net> <20100313200155.O22734@delplex.bde.org> <alpine.BSF.2.00.1003131346270.51476@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?06D5F9F6F655AD4C92E28B662F7F853E021D4D26>