ten thousand small processes

Marcel Moolenaar marcel at xcllnt.net
Wed Jun 25 21:39:06 PDT 2003


On Thu, Jun 26, 2003 at 02:50:29AM -0000, D. J. Bernstein wrote:
> Jon Mini writes:
> > I'm sorry, but you are way off here.  First of all, caches are *much
> > larger* than the size of the processes you are talking about.
> 
> I'm sorry, but you are being misled by a naive model of CPU performance.
> On a typical Pentium in our department, the following program becomes
> three times faster when SPACING is changed from 4096 to 128:
*snip*
> >From an asm programmer's perspective, when FreeBSD decides to spread a
> small program's variables between
> 
>    * the beginning of a data page,
>    * the beginning of a bss page,
>    * the beginning of a malloc mmap page,
>    * the beginning of a heap page,
>    * the beginning of the next heap page,
>    * the beginning of yet another heap page,
> 
> et cetera, it is actively trying (with varying degrees of success) to
> damage cache performance in exactly the same way that this program does.

Just curious: do you happen to know if the performance hit is caused
by the second order effect of having the spacing be a multiple of
the cache associativity, thereby resulting in thrashing of a few
cache lines, and that compacting the code results in a more uniform
cache placement?
In other words: is it (sec) the spacing that counts or the interaction
of a particular "distance" with cache placement?

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel at xcllnt.net


More information about the freebsd-performance mailing list