Am Sonntag, 12. Januar 2003 23:34 schrieb Rob Wilkens:
> On Sun, 2003-01-12 at 17:18, Aaron Lehmann wrote:
> > These are usually error conditions. If you inline them, you will have
> > to jump *over* them as part of the normal code path. You don't save
>
> You're wrong. You wouldn't have to jump over them any more than you
> have to jump over the "goto" statement. They would be where the goto
> statement is. Instead of the goto you would have the function.
That exactly is the problem. If they are where the goto would be
they needlessly fill the CPU's pipeline, take up space in L1 and use
up bandwidth on the busses.
A goto is much shorter than a cleanup.
And you would have to jump. Any control structure will result in one
or more conditional jumps in the assembler code (or conditional instructions)
Turning "if (a) goto b;" into a single branch instruction is trivial.
The best the compiler can do with
if (a) {
cleanup();
return err;
}
is putting the conditional code on the end of the function.
So in the best case the compiler can generate almost equivalent code
at a cost of maintainability.
> > any instructions, and you end up with a kernel which has much more
> > duplicated code and thus thrashes the cache more. It also makes the
>
> If that argument was taken to it's logical conclusion (and I did, in my
> mind just now), no one should add any code the grows the kernel at all.
Correct. If you mean that literally, you've grasped an important concept.
You grow the kernel only with good cause.
And you look where you add the code. Additional device drivers don't hurt.
A computed jump is still only one computed jump. Additional code in common
code paths of the core hurts a lot.
For the inner loops of core code there are two considerations, size and
reducing jumps.
Regards
Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jan 15 2003 - 22:00:42 EST