Re: [PATCH] Simple malloc benchtest.

[OndÅej BÃlka <neleai at seznam dot cz>]

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