From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 23 Feb 2009 22:10:41 -0800 From: Ben Calvert To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-Reply-To: <845e587b6874e243258b49863d4011c4@quanstro.net> Message-ID: References: <845e587b6874e243258b49863d4011c4@quanstro.net> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [9fans] Calling vac from C Topicbox-Message-UUID: a782eba8-ead4-11e9-9d60-3106f5b1d025 On Fri, 20 Feb 2009, erik quanstrom wrote: > 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. about 5 years ago i took a class on performance tuning Solaris. The instructor claimed that fork was expensive because accounting is never really turned off, just piped to /dev/null. there is no accounting overhead for threads. I never bothered to verify this, but now that this comes up, I'd tempted. > - erik