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

From: Poul-Henning Kamp <phk_at_phk.freebsd.dk>
Date: Sun, 08 Feb 2004 09:42:59 +0100
In message <20040208080630.GA14364_at_VARK.homeunix.com>, David Schultz writes:
>I spent some time today benchmarking the various proposed pid
>allocators.  The full results, along with pretty pictures and a
>more complete analysis, are at:
>
>	http://people.freebsd.org/~das/pbench/pbench.html  [1]

You _do_ realize that the difference between "tjr" and "net" in the
bottom plot is not statistically significant ?

Stratification is visibly present from approx 1500 pids and up, and
ends up being responsible for 1/3rd of the difference by the time
you get to 5000 pids.

(The tell-tale sign here is that the two data sets both fall on two
mostly straight lines in a random looking pattern, with practically
no measurements hitting the interval between the two lines.)

If we assume the stratification has linearity with number of pids,
which I think looks reasonable, and we read the right hand edge as
half a second and the left hand edge as zero, we find:

	    (.5 - 0) [second]
  -------------------------------------- = 10 [nsec] / [iteration*pid]
  10000 [iterations] * (5000 - 0) [pids]

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.

So all in all, I would say that you have proven that "tjr" and "net"
are better than "old", but not that there is any statistically
significant performance difference between them.

In that case, simplicity is a wonderful selection criteria, and I'll
second your recommendation for "tjr" on that basis.

Poul-Henning

-- 
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.
Received on Sat Feb 07 2004 - 23:44:01 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:42 UTC