9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Uriel <uriel99@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] Calling vac from C
Date: Fri, 20 Feb 2009 17:17:04 +0100	[thread overview]
Message-ID: <5d375e920902200817w3863fe8ayf39f4dc14267d067@mail.gmail.com> (raw)
In-Reply-To: <a118bfa1b7624fc83a8dd72e4a0b2036@quanstro.net>

One of the main costs of dynamic linking is making fork much slower.
Even on linux statically linked binaries fork a few magnitude orders
faster than dynamically linked ones.

The main source of anti-fork FUD turns out to be the alleged
'solution' to a problem that didn't exist until the geniuses at Sun
decided dynamic linking was such a wonderful idea.

On linux with ancient hardware one can do hundreds of forks per second
without any problems, it works great for werc[1], and it is amusing to
see people inventing hacks like fcgi and writing pthreaded web servers
to avoid as much as one fork call per request, when making hundreds of
them is a non-issue.

An example of how one mistake in systems design(introduction of
dynamic linking) leads to even greater mistakes down the road
(pthreads, fcgi, all kinds of hacks to avoid fork), and people never
steps back to think if the original design decision was really worth
it.

Peace

uriel

[1]: http://werc.cat-v.org

On Fri, Feb 20, 2009 at 4:41 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> I believe that
>> 1) Its too much trouble parsing the output everytime.
>
> i don't buy that.  that takes very little code.  since you
> have evidently already written the code, the cost
> is zero.
>
> (if you're worried about runtime, i measure parsing
> time at 338ns on a core i7 920.  cf. attached digestspd.c)
>
>> 2) Calling some function from an included library will be faster.
>
> maybe.  are you sure that it matters?  i measure
> base fork/exec latency on a 1.8ghz xeon5000 at 330µs.
> (files served from the fileserver, not a ram disk.)
> the attached fork.c and nop.c were used to do the
> measurement.  i measure vac throughput at ~3mb/s
> for small files from a brand new venti running from a
> ramdisk.  the venti was tiny with 5mb isect and 100mb
> arenas, and empty.  at that rate, 330µs will cost you
> 1038 bytes, or 0.3%.
>
> remember that dynamic linking isn't free.  that cost
> assumes that dynamic linking is free, and it is not.
>
> - erik



  reply	other threads:[~2009-02-20 16:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-19  9:53 anooop.anooop
2009-02-19 12:55 ` erik quanstrom
2009-02-20  9:53 ` anooop.anooop
2009-02-20 15:41   ` erik quanstrom
2009-02-20 16:17     ` Uriel [this message]
2009-02-20 16:47       ` erik quanstrom
2009-02-24  6:10         ` Ben Calvert
2009-02-24 15:54 erik quanstrom
2009-02-24 16:15 ` Roman V. Shaposhnik
2009-02-24 16:22 erik quanstrom
     [not found] <ac072e66c823fd6d649593efec9e221b@quanstro.net>
2009-02-24 16:32 ` Roman V. Shaposhnik
2009-02-24 17:01 erik quanstrom
     [not found] <c9aea65e7f058933edc0a22e931ea675@quanstro.net>
2009-02-24 17:17 ` Roman V. Shaposhnik

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=5d375e920902200817w3863fe8ayf39f4dc14267d067@mail.gmail.com \
    --to=uriel99@gmail.com \
    --cc=9fans@9fans.net \
    /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;
as well as URLs for NNTP newsgroup(s).