A fairly simple - but not perfectly accurate - test case would be to
run ksh93 on Linux and Solaris and let it call /bin/true in a loop.
The numbers which follow are for identical ksh93 versions built with
the same gcc version and /bin/true a simple main() { return 0 ;}:
1. Timing values for Solaris B134 on bare metal hardware:
time ksh -c 'integer i ; for (( i=0 ; i < 100000 ; i++ )) ; do /bin/true ; done'
real 9m29.75s
user 0m8.55s
sys 2m46.89s
2. Timing values for Linux on the same hardware:
time ksh -c 'integer i ; for (( i=0 ; i < 100000 ; i++ )) ; do /bin/true ; done'
real 1m26.964s
user 0m12.314s
sys 0m42.831s
Olga
On Wed, Jul 14, 2010 at 8:37 PM, James Carlson <[email protected]> wrote:
> [email protected] wrote:
>> On Wed, Jul 14, 2010 at 12:32:26AM -0500, Nicolas Williams wrote:
>>> One possible improvement that comes to mind would be a private vforkx()
>>> flag to request that threads in the parent other than the one calling
>>> vforkx() not be stopped. The child would have to be extremely careful
>>> to not call malloc() or do anything that might disturb the state of the
>>> parent beyond the current stack frame, which is why such a flag would
>>> have to be private and undocumented. But this should not be considered
>>> until someone first shows that posix_spawn() performance is a problem
>>> and that the parent thread stop/resume overhead is the biggest ticket
>>> item.
>>
>> It's significantly more complicated than that. You'd have to ensure
>> that there are no race conditions between the atfork handlers, rtld,
>> libc, and any application specific locking. The vfork manual is already
>> pretty clear that all bets are off should you use this in a
>> multi-threaded application:
>>
>> The use of vfork() or vforkx() in multithreaded applica-
>> tions, however, is unsafe due to race conditions that can
>> cause the child process to become deadlocked and conse-
>> quently block both the child and parent process from execu-
>> tion indefinitely.
>>
>> A solution that creates a new process without a call to fork is the best
>> idea I've heard so far. Unfortunately, as Bart has already observed,
>> it's a lot of work for a gain that has yet to be quantified.
>
> Plus, the original poster was apparently mostly concerned about ksh93's
> performance, and making the heavy MT case work faster won't help that
> application a bit, because ksh93 isn't making use of threads.
>
> I think having the original poster come up with a test case of interest
> (something that runs significantly faster on "all other platforms") and
> then gathering basic data on that test case (where does a profiler say
> the system is spending its time?) would be a much better plan then
> speculating wildly on which magic new system call will make everything
> run better.
>
> --
> James Carlson 42.703N 71.076W <[email protected]>
> _______________________________________________
> on-discuss mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/on-discuss
>
--
, _ _ ,
{ \/`o;====- Olga Kryzhanovska -====;o`\/ }
.----'-/`-/ [email protected] \-`\-'----.
`'-..-| / http://twitter.com/fleyta \ |-..-'`
/\/\ Solaris/BSD//C/C++ programmer /\/\
`--` `--`
_______________________________________________
perf-discuss mailing list
[email protected]
