Re: [9fans] Calling vac from C

[erik quanstrom <quanstro@quanstro.net>]

On Fri Feb 20 11:18:41 EST 2009, uriel99@gmail.com wrote:
> 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.

very generally, i agree with the direction of your
post.  but i do remember things a bit differently.

iirc, this went the other way 'round.  fork itself
was very expensive on sun hardware in the early
90s if one had some memory mapped.  sun mmus
had issues.  i benchmarked a vax 11/780 vs a sun
670mp.  the 4x50mhz 670mp was scheduled to replace the
1x5mhz (?) vaxen.  the vax forked maybe 10x faster when no
memory was allocated.  however, when a moderate
amount of memory was allocated, the vax pounded
the sun by many (3, i think) of magnitude.

i posted this info way back when, but can't find
a reference.

threading became a really hot topic at the time,
too.  maybe just coincidence, but i'm sure it didn't
hurt to be able to show such great improvement.

the fork test run on my underpowered p3 machine
gets 1800µs/fork-exec.  since the p3 does 1836 bogomips
and the i7 does 43173, it's safe to assume that linux
has fine fork performance, given a reasonable amount
of shared libraries.

it would be very interesting if someone would
see how fork performance relates to the size and
number of dynamic libraries.  i'm not sure i know
how to do this without devoting weeks to the project.

- erik