Re: PID Allocator Performance Results (was: Re: [UPDATE] new pid alloc...)

In message <20040208094537.GA14749_at_VARK.homeunix.com>, David Schultz writes:

>> 10nsec per operation is getting you into the territory of effective
>> TSC-timecounter resolution, RAM access time, cache miss delays
>> and all sorts of other hardware effects.
>
>To avoid jitter and timestamping overhead, I read the time only at
>the start and end of the entire sequence of 10000 operations.
>I obtained the sample variance by running the entire test three
>times, i.e.

Yes, but you have to remember that quite a lot of stuff happens
in the kernel of your iteration, and the stratification seems
to happen there.

>Nevertheless, you're definitely right about the stratification.
>
>Yes, I realize that.  I took 10 more samples of 10000 forks each
>with 5000 sleeping processes in the background and got the
>following:

>This data show a difference at the 95% confidence level, namely,
>that the NetBSD algorithm is about 1% faster on a system with 5000
>processes (and only 0.1% faster if you're looking at the total
>overhead of fork() rather than vfork().)  I think that pretty much
>rules out performance as the deciding factor between the two.

Uhm, if you are using "Student's T" you have to remember that it
is only valid for gaussian noise processes.  The stratification
we see is not any where near to gaussian.

Either way:  "tjr" should be our choice.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.