site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Thanks for re-running these numbers. It's quite helpful. - 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: Jonas _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/jkh%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... 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. 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). This email sent to jkh@apple.com This email sent to site_archiver@lists.apple.com