Re: [Fwd: Re: execv bug???]
Re: [Fwd: Re: execv bug???]
- Subject: Re: [Fwd: Re: execv bug???]
- From: "Jordan K. Hubbard" <email@hidden>
- Date: Sun, 9 Mar 2008 13:37:10 -0700
Thanks for re-running these numbers. It's quite helpful.
I don't remember the conclusions from last time we discussed this, but
was there are reason why posix_spawn(2) was also not under
consideration for this? Clearly it's the inheritor of vfork()'s
mantle, but there may be a reason why you are unable to use it on
MacOSX that I'm forgetting.
- Jordan
On Mar 9, 2008, at 10:31 AM, Jonas Maebe wrote:
On 28 Jan 2008, at 04:23, Jordan K. Hubbard wrote:
On 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 finally got around to benchmarking this again. All tests below are
under 10.5.2, compiling our compiler with itself. In all cases these
are "native" compilations (i.e., an i386 compiler compiling an i386
compiler, an x86_64 compiler compiling an x86_64 compiler etc), and
the assembler gets its input via a pipe.
When the compiler is told not to assembler/link, it generates a
shell script with a the necessary calls to the assembler and linker
to assemble/link everything. The time needed to complete this script
is what is timed in the second item for each case below.
MacBook 2.2GHz, 1GB ram (November 2007):
* 32 bit (200 invocations of the assembler + 1 of the linker, 216480
loc):
- compile to assembler files without assembling or linking: 8.7 secs
- assemble+link using shell script: 2.6 secs
- compile + assemble + link (vfork): 10.6 secs
- compile + assemble + link (fork): 13.2 secs
-> fork makes the total 24.5% slower
* 64 bit (179 invocations of the assembler + 1 of the linker, 201171
loc)
- compile to assembler files without assembling or linking: 6.1 secs
- assemble+link using shell script: 2.1 secs
- compile + assemble + link (vfork): 8.2 secs
- compile + assemble + link (fork): 11.4 secs
-> fork makes the total 39% slower
Dual G5 1.8 GHz, 3 GB ram:
* 32 bit (171 invocations of the assembler + 1 of the linker, 177620
loc)
- compile to assembler files without assembling or linking: 16.1 secs
- assemble+link using shell script: 4.2 secs
- compile + assemble + link (vfork): 19.7 secs
- compile + assemble + link (fork): 28.4 secs
-> fork makes the total 44.1% slower
* 64 bit (164 invocations of the assembler + 1 of the linker, 172379
loc)
- compile to assembler files without assembling or linking: 18 secs
- assemble+link using shell script: 3.9 secs
- compile + assemble + link (vfork): 21.1 secs
- compile + assemble + link (fork): 33.4 secs
-> fork makes the total 53.6% slower
So at least for my use case, there doesn't appear to be much of an
improvement (at least not for ppc; I don't have any numbers for x86
for 10.4.x).
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
_______________________________________________
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