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