Ragnar Sundblad writes:
On Mon, 23 Sep 2002 18:06:53 -0400 Jim Magee <jmagee@apple.com> wrote:
vfork() yields 100X (yes, 100 times, not percent more) the performance
of fork() in most situations on Mac OS X. So, if you can live with
vfork() requirements, please do so. Getting common tools to use it
where appropriate appears to be the trick in your case. I don't think
Linux has vfork(), so people tend to stick with just fork() in portable
code.
Is there any chance of improving fork+exec performance in the OS
since, as you say, many programs currently use fork?
FWIW, fork _used_ to be faster. I have some old lmbench numbers laying around: ---------------------------------------------------------------- Host OS Mhz null null open selct sig sig fork exec sh call I/O stat clos TCP inst hndl proc proc proc --------- ------------- ---- ---- ---- ---- ---- ----- ---- ---- ---- ---- ---- g4 Darwin 1.4 799 2.21 3.19 12.6 16.4 30.4 3.78 9.88 1576 4095 13.K g4 Darwin 5.5 797 2.26 3.15 14.5 17.8 30.4 3.82 10.2 5685 12.K 40.K g4.local. Darwin 6.0 797 1.47 2.73 17.2 20.7 27.2 3.00 10.5 7517 17.K 41.K g4 Linux 2.4.18- 799 0.42 0.69 2.52 3.79 33.6 1.23 3.08 659. 2642 12.K So it looks like somebody "fixed" something with a sledgehammer sometime between 10.1 and 10.1.5. Eg, 1.4 was only a factor of 2 slower than linux for fork and fork+exec, and just a small percent slower for running a shell. Does the update process save the old kernels off someplace? If so, I'll try to narrow this down further. I the meantime, I'm thinking about pulling the kernel off the original installation media and running 1.4 for developement. I can't afford to wait an hour for a compile which takes < 10 minutes on linux (on the same hardware). Drew _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.
participants (1)
-
Andrew Gallatin