Re: [Fwd: Re: execv bug???]
Re: [Fwd: Re: execv bug???]
- Subject: Re: [Fwd: Re: execv bug???]
- From: Jonas Maebe <email@hidden>
- Date: Mon, 28 Jan 2008 13:24:34 +0100
On 28 Jan 2008, at 04:23, Jordan K. Hubbard wrote:
n Jan 27, 2008, at 2:46 PM, Jonas Maebe wrote:
That's more or less true for Linux, but not for Mac OS X at least
up till 10.4.x (I haven't benchmarked on 10.5 yet). Compiling our
compiler with itself, which involves about 173 (v)fork+execs from a
single compiler run to assemble&link all the files, is 20% to 25%
slower with fork instead of vfork on a G4, and 35% to 40% on a G5
(32 bit processes in both cases) on 10.4.x. And for clarity: this
is relative to the entire time needed for compiling+assembling
+linking everything (on the G5: 24 vs 15 seconds), not some
academic mbench-like speed difference between the fork and vforks.
It would be interesting to benchmark this in 10.5 as well, given a
number of changes to the relevant code,
I don't have a PPC with 10.5 yet, but I'll try when I have the chance.
I'll also check fork vs vfork on my MacBook (which can only run 10.5).
but the original poster who noted that vfork() was deprecated was
correct. At some point, I would not be at all surprised to see a
"#define vfork fork" in unistd.h so that code path can be deprecated
entirely.
What about backwards compatibility for already compiled binaries?
Since libSystem is not a framework, I'm not sure how this can be
ascertained should vfork also be removed from the library itself.
Jonas
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden