[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