Thread (4 messages) 4 messages, 3 authors, 2007-01-18

Re: [PATCH 2/4] libata-core.c: add another IRQ calls

From: Mikael Pettersson <hidden>
Date: 2007-01-17 09:45:54
Also in: linux-ide

On Tue, 16 Jan 2007 17:04:27 -0500, Jeff Garzik wrote:
Alan wrote:
quoted
Jeff - at some point we could eliminate a lot of the NULL checks like
these by having the registration code fill in the defaults where
appropriate ?
libata policy up until this point has been to require all drivers fill 
in the hook, either with the commonly-used default, or with their own 
variant.  Thus, no NULL checks for required hooks, and you get an oops 
if you fail this requirement.  I like that better than defaults buried 
inside libata-core, where it is easier for programmers to forget them.

But actually, it's an open question for the compiler guys whether this 
case is preferred:

if (ap->ops->hook)
	ap->ops->hook(foo, bar);
else
	commonly_used_default(foo, bar);

or this:

ap->ops->hook(foo, bar);

With advanced branch prediction in modern CPUs, ISTR the first case may 
be worth considering, even with the branch.
Indirect function calls incur at least two main costs:
- the 'call *' instruction itself suffers from poor branch
  prediction unless the HW is clever and the call patterns
  are highly biased -- most machines have worse branch
  predictors for indirect jumps than for direct jumps
- the compiler must generate code for setting up parameters
  and spilling the caller's registers, and for reloading the
  caller's registers after the call

If there is a highly common case, the code for that case
is available, and the code is cheap to execute (doesn't
require too many additional variables), then having an
explicit test + inline code is preferred. If any of these
conditions isn't met, then I wouldn't bother converting
the call to the if/inline/call combo.

There are compilers for OOP languages that routinely use
rewrites like the one above in order to optimise method calls.

/Mikael
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help