Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Jun 2003 22:15:43 -0700
From:      Bakul Shah <bakul@bitblocks.com>
To:        "D. J. Bernstein" <djb@cr.yp.to>
Cc:        freebsd-performance@freebsd.org
Subject:   Re: ten thousand small processes 
Message-ID:  <200306260515.h5Q5FhPF020045@bitblocks.com>
In-Reply-To: Your message of "26 Jun 2003 02:50:29 -0000." <20030626025029.71392.qmail@cr.yp.to> 

next in thread | previous in thread | raw e-mail | index | archive | help
> On a typical Pentium in our department, the following program becomes
> three times faster when SPACING is changed from 4096 to 128:
> 
>    #define SPACING 4096
>    char data[8 * SPACING];
>    main()
>    {
>      int i;
>      for (i = 0;i < 10000000;++i) {
>        data[0] = data[SPACING];
>        data[2 * SPACING] = data[3 * SPACING];
>        data[4 * SPACING] = data[5 * SPACING];
>        data[6 * SPACING] = data[7 * SPACING];
>      }
>    }

When SPACING is changed from 4096 to 128, this program runs
ten times faster on a pentium pro.  It runs two times _slower_
on an Athlon XP+.  It runs at about the same speed on a PIII.

All one can say is performance is sensitive to data spacing +
processor architecture and you have to tune your programs for
a given machine.

Instead of complaining about wasting 78 megabytes and arguing
about why various proposed solutions fall short and why your
way is the best, why don't you come up with a patch that
saves space for small programs?  If *you* are not willing to
`casually piss away large fractions of a gigabyte of RAM' it's
up to *you* to solve the problem!  If you expect others to
do this for you, you are going about it the wrong way.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200306260515.h5Q5FhPF020045>