All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ihar \"Philips\" Filipau" <filia@softhome.net>
To: linux-kernel@vger.kernel.org
Subject: Re: [uClinux-dev] Kernel 2.6 size increase - get_current()?
Date: Fri, 25 Jul 2003 17:37:39 +0200	[thread overview]
Message-ID: <3F214EC3.9010804@softhome.net> (raw)
In-Reply-To: <dbTZ.5Z5.19@gated-at.bofh.it>

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...


       reply	other threads:[~2003-07-25 15:21 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <d2nx.4QV.15@gated-at.bofh.it>
     [not found] ` <dbTZ.5Z5.19@gated-at.bofh.it>
2003-07-25 15:37   ` Ihar "Philips" Filipau [this message]
2003-07-25 20:46     ` OT: Vanilla not for embedded?! Re: Kernel 2.6 size increase - get_current()? Mike Fedyk
2003-07-25 20:43       ` Andre Hedrick
2003-07-27 11:57       ` Ihar "Philips" Filipau
2003-07-27 13:05         ` Francois Romieu
2003-07-24  8:27 [uClinux-dev] " Ihar "Philips" Filipau
2003-07-24 11:50 ` David McCullough
     [not found] <cwQJ.3BO.29@gated-at.bofh.it>
     [not found] ` <cypH.5dM.35@gated-at.bofh.it>
     [not found]   ` <cyza.5lN.13@gated-at.bofh.it>
     [not found]     ` <cArg.74D.11@gated-at.bofh.it>
2003-07-24  8:13       ` Ihar "Philips" Filipau
2003-07-25  7:25         ` Denis Vlasenko
2003-07-25 18:36         ` bill davidsen
  -- strict thread matches above, loose matches on Subject: below --
2003-07-23 18:46 Kernel 2.6 size increase Bernardo Innocenti
2003-07-23 20:22 ` [uClinux-dev] " David S. Miller
2003-07-23 20:27   ` Christoph Hellwig
2003-07-23 22:35     ` [uClinux-dev] Kernel 2.6 size increase - get_current()? Bernardo Innocenti
2003-07-23 22:37       ` Alan Cox
2003-07-23 23:00         ` Bernardo Innocenti
2003-07-24  5:06           ` David McCullough
2003-07-24 11:28             ` Alan Cox
2003-07-24 12:04               ` David McCullough
2003-07-24 14:48                 ` Alan Cox
2003-07-25 18:25                 ` bill davidsen
2003-07-24 15:30               ` Hollis Blanchard
2003-07-24 19:37                 ` Alan Cox
2003-07-24 19:51                   ` Hollis Blanchard
2003-07-24 21:20                     ` J.A. Magallon
2003-07-25  4:22                       ` Otto Solares
2003-07-25 14:38                         ` Hollis Blanchard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3F214EC3.9010804@softhome.net \
    --to=filia@softhome.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.