[PATCH] Simple malloc benchtest.
Ondřej Bílka
neleai@seznam.cz
Mon Dec 23 13:32:00 GMT 2013
On Mon, Dec 23, 2013 at 02:36:27PM +0530, Siddhesh Poyarekar wrote:
> On Sat, Dec 21, 2013 at 04:33:03PM +0100, OndÅej BÃlka wrote:
> > +void
> > +do_test (size_t size)
> > +{
> > + timing_t start, stop, cur;
> > + const int iters = 1<<18;
> > +
> > + unsigned int r_seed = 42;
> > + void *ary[iters];
> > + size_t sizes[iters];
> > + size_t idx[iters];
> > +
> > + for (int i = 0; i < iters; i++)
> > + {
> > + ary[i] = NULL;
> > + sizes[i] = size + rand_r (&r_seed) % (7 * size);
> > + idx[i] = rand_r (&r_seed) % (iters / 64);
> > + }
> > +
> > + printf ("\n allocations in range %lu-%lu:", size, 8 * size);
> > +
> > + TIMING_NOW (start);
> > +
> > + for (int i = 0; i < iters; ++i)
> > + {
> > + free (ary[idx[i]]);
> > + ary[idx[i]] = malloc (sizes[i]);
> > + }
> > +
> > + for (int i = 0; i < iters; ++i)
> > + free (ary[i]);
> > +
> > + TIMING_NOW (stop);
> > + TIMING_DIFF (cur, start, stop);
> > + TIMING_PRINT_MEAN ((double) cur, (double) iters);
>
> In addition to Wills concerns, I'd also like to see a simple
> evaluation of fragmentation resulting from a sequence of allocations
> and frees. To get that you'll need to keep some blocks un-freed -
> choosing those blocks would be another interesting problem.
>
You cannot do that, you would repeat same mistake that plagued allocator
research in seventies, allocation patterns are simply different than
simulations and all that you would get from that measurement is is meaningles garbage,
see following link:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97.5185&rep=rep1&type=pdf
More information about the Libc-alpha
mailing list