Hollis Blanchard wrote:
> I believe the point Alan was trying to make is not that we should have
> more or less inlines, but we should have smarter inlines. I.E. don't
> just inline a function to "make it fast"; think about the implications
> (and ideally measure it, though I think that becomes problematic when so
> many other factors can affect the benefit of a single inlined function).
> The specific example he gave was inlining code on the fast path, while
> accepting branch/cache penalties for non-inlined code on the slow path.
>
But you cannot make this kind of decisions universal.
Some kind of compromise should be found between arch-mantainers and
subsystem-mantainers.
Or beat GCC developer hard so they finally will produce good
optimizing compiler ;-)
Or ask all kernel developpers to work one hour per week on GCC
optimization - I bet GCC will outperform everything else in industry in
less that one year ;-)))
To remind: source of the problem is not inlines, problem is the
compiler, which cannot read our minds yet and generate code we were
expected it to generate.
P.S. Offtopic. As I see it Linux & Linus have made the decision of
optimization. Linux after all is capitalismus creation: who has more
money do control everything. Server market has more money - they do more
work on kernel and they systems are not that far from developers'
workstations - so Linux gets more and more server/workstation oriented.
This will fit desktop market too - if your computer was made to run
WinXP AKA exp(bloat) - it will be capable to run any OS. Linus repeating
'small is beatiful' sounds more and more like crude joke...
As for embedded market - it is already in deep fork and far far away
from vanilla kernels... Vanilla really not that relevant to real world...
-
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 : Thu Jul 31 2003 - 22:00:26 EST