public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "J.A. Magallón" <jamagallon@ono.com>
To: linux-kernel@vger.kernel.org
Subject: Re: Kernel Development & Objective-C
Date: Mon, 3 Dec 2007 22:39:02 +0100	[thread overview]
Message-ID: <20071203223902.1194aa69@werewolf> (raw)
In-Reply-To: <20071203211353.GA4009@1wt.eu>

On Mon, 3 Dec 2007 22:13:53 +0100, Willy Tarreau <w@1wt.eu> wrote:

...
> 
> It just depends how many times a second it happens. For instance, consider
> this trivial loop (fct is a two-function array which just return 1 or 2) :
> 
>         i = 0;
>         for (j = 0; j < (1 << 28); j++) {
>                 k = (j >> 8) & 1;
>                 i += fct[k]();
>         }
> 
> It takes 1.6 seconds to execute on my athlon-xp 1.5 GHz. If, instead of
> changing the function once every 256 calls, you change it to every call :
> 
>         i = 0;
>         for (j = 0; j < (1 << 28); j++) {
>                 k = (j >> 0) & 1;
>                 i += fct[k]();
>         }
> 
> Then it only takes 4.3 seconds, which is about 3 times slower. The number
> of calls per function remains the same (128M calls each), it's just the
> branch prediction which is wrong every time. The very few nanoseconds added
> at each call are enough to slow down a program from 1.6 to 4.3 seconds while
> it executes the exact same code (it may even save one shift). If you have
> such stupid code, say, to compute the color or alpha of each pixel in an
> image, you will certainly notice the difference.
> 
> And such poorly efficient code may happen very often when you blindly rely
> on function pointers instead of explicit calls.
> 
...
> 
> You are forgetting something very important : once you start stacking
> functions to perform the dirty work for you, you end up with so much
> abstraction that even new stupid code cannot be written at all without
> relying on them, and it's where the problem takes its roots, because
> when you need to write a fast function and you notice that you cannot
> touch a variable without passing through a slow pinhole, your fast
> function will remain slow whatever you do, and the worst of all is that
> you will think that it is normally fast and that it cannot be written
> faster.
> 

But don't forget that OOP is just another way to organize your code,
and let the language/compiler do some things you shouldn't de doing,
like fill an vtable pointer, that are error prone.

And of course everything depends on what language you choose and how
you use it.
You could write an equally effcient kernel in languages like C++,
using C++ abstractions as a high level organization, where
the fast paths could be coded the right way; we are not talking about
C# or Java, where even a sum is a call to an overloaded method.
Its the difference between doing school-book push and pops to lists,
and suddenly inventing the splice operator...

--
J.A. Magallon <jamagallon()ono!com>     \               Software is like sex:
                                         \         It's better when it's free
Mandriva Linux release 2008.1 (Cooker) for i586
Linux 2.6.23-jam03 (gcc 4.2.2 (4.2.2-1mdv2008.1)) SMP Sat Nov

  reply	other threads:[~2007-12-03 21:39 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-29 12:14 Kernel Development & Objective-C Ben Crowhurst
2007-11-30 10:02 ` Xavier Bestel
2007-11-30 10:09   ` KOSAKI Motohiro
2007-11-30 10:20     ` Xavier Bestel
2007-11-30 10:54       ` Jan Engelhardt
2007-11-30 14:21         ` David Newall
2007-11-30 23:31           ` Bill Davidsen
2007-11-30 23:40             ` Alan Cox
2007-12-01  0:05               ` Arnaldo Carvalho de Melo
2007-12-01 18:27               ` Bill Davidsen
2007-12-01 18:18                 ` Alan Cox
2007-12-03  1:23                   ` Bill Davidsen
2007-11-30 22:52     ` J.A. Magallón
2007-11-30 10:29 ` Loïc Grenié
2007-11-30 11:16   ` Ben Crowhurst
2007-11-30 11:36     ` Karol Swietlicki
2007-11-30 14:37     ` Lennart Sorensen
2007-12-08  8:54     ` Rogelio M. Serrano Jr.
2007-11-30 23:19   ` J.A. Magallón
2007-11-30 23:53     ` Nicholas Miell
2007-12-01  0:31     ` Al Viro
2007-12-01  0:34       ` Al Viro
2007-12-01  1:09       ` J.A. Magallón
2007-12-01 19:55       ` Avi Kivity
2007-12-04 17:54     ` Lennart Sorensen
2007-12-04 21:10       ` Avi Kivity
2007-12-04 21:24       ` J.A. Magallón
2007-11-30 11:37 ` Matti Aarnio
2007-11-30 14:34 ` Lennart Sorensen
2007-11-30 15:26   ` Kyle Moffett
2007-11-30 18:40     ` H. Peter Anvin
2007-11-30 19:35       ` Kyle Moffett
2007-12-01 20:03     ` Avi Kivity
2007-12-02 19:01       ` Andi Kleen
2007-12-03  5:12         ` Avi Kivity
2007-12-03  9:50           ` Andi Kleen
2007-12-03 11:46             ` Avi Kivity
2007-12-03 11:50               ` Andi Kleen
2007-12-03 21:13               ` Willy Tarreau
2007-12-03 21:39                 ` J.A. Magallón [this message]
2007-12-03 21:57                   ` Alan Cox
2007-12-04 21:47                     ` J.A. Magallón
2007-12-04 22:20                       ` Diego Calleja
2007-12-05 10:59                         ` Giacomo A. Catenazzi
2007-12-04 21:07                 ` Avi Kivity
2007-12-04 22:43                   ` Willy Tarreau
2007-12-05 17:05                     ` Micro vs macro optimizations (was: Re: Kernel Development & Objective-C) Avi Kivity
2007-12-03 12:35           ` Kernel Development & Objective-C Gilboa Davara
2007-12-03 12:44             ` Gilboa Davara
2007-12-03 16:28             ` Casey Schaufler
2007-12-04 17:50             ` Lennart Sorensen
2007-12-05 10:31               ` Gilboa Davara
2007-12-01 19:59   ` Avi Kivity
2007-12-02 19:44     ` Jörn Engel
2007-12-03 16:53     ` Lennart Sorensen
2007-11-30 15:00 ` Chris Snook
2007-12-01  9:50   ` David Newall

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=20071203223902.1194aa69@werewolf \
    --to=jamagallon@ono.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox