Re: [patch 00/2] improve .text size on gcc 4.0 and newer compilers

[Linus Torvalds <torvalds@osdl.org>]

On Thu, 5 Jan 2006, Linus Torvalds wrote:
> 
> That way the "profile data" actually follows the source code, and is thus 
> actually relevant to an open-source project. Because we do _not_ start 
> having specially optimized binaries. That's against the whole point of 
> being open source and trying to get users to get more deeply involved with 
> the project.

Btw, having annotations obviously works, although it equally obviously 
will limit the scope of this kind of profile data. You won't get the same 
kind of granularity, and you'd only do the annotations for cases that end 
up being very clear-cut. But having an automated feedback cycle for adding 
(and removing!) annotations should make it pretty maintainable in the long 
run, although the initial annotations migh only end up being for really 
core code.

There's a few papers around that claim that programmers are often very 
wrong when they estimate probabilities for different code-paths, and that 
you absolutely need automation to get it right. I believe them. But the 
fact that you need automation doesn't automatically mean that you should 
feed the compiler a profile-data-blob.

You can definitely automate this on a source level too, the same way 
sparse annotations can help find user access problems. 

There's a nice secondary advantage to source code annotations that are 
actively checked: they focus the programmers themselves on the issue. One 
of the biggest advantages (in my opinion) of the "struct xyzzy __user *" 
annotations has actually been that it's much more immediately clear to the 
kernel programmer that it's a user pointer. Many of the bugs we had were 
just the stupid unnecessary ones because it wasn't always obvious.

The same is likely true of rare functions etc. A function that is marked 
"rare" as a hint to the compiler to put it into another segment (and 
perhaps optimize more aggressively for size etc rather than performance) 
is also a big hint to a programmer that he shouldn't care. On the other 
hand, if some branch is marked as "always()", that also tells the 
programmer something real.

So explicit source hints may be more work, but they have tons of 
advantages. Ranging from repeatability and distribution to just the 
programmer being aware of them.

In other projects, maybe people don't care as much about the programmer 
being aware of what's going on - garbage collection etc silent automation 
is all wonderful. In the kernel, I'd rather have people be aware of what 
happens.

		Linus
-
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/