likely and unlikely

[Matthew Fleming]

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 at freebsd.org on behalf of Robert Watson
Sent: Sat 13-Mar-10 5:47 AM
To: Bruce Evans
Cc: Max Laier freebsd-arch at freebsd.org
Subject: Re: likely and unlikely
 

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 theres specific measurements that 
indicate they are important to have there  at the very least, pmc data, but 
ideally also benchmarking data.

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-arch at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"