c - 分配大块时 Hoard 性能严重下降

Question

我在“C”中编写了下面的示例程序，它是动态内存密集型的，并尝试对“glibc”默认分配器与 Hoard 分配器进行相同的基准测试(就所用时间而言)。

  1 #include <stdio.h>
  2 #include <stdlib.h>
  3
  4 #define NUM_OF_BLOCKS   (1 * 4096)
  5
  6 void *allocated_mem_ptr_arr[NUM_OF_BLOCKS];
  7
  8 int
  9 main (int argc, char *argv[])
 10 {
 11     void *myblock = NULL;
 12
 13     int count, iter;
 14
 15     int blk_sz;
 16
 17     if (argc != 2)
 18     {
 19         fprintf (stderr, "Usage:./memory_intensive <Block size (KB)>\n\n");
 20         exit (-1);
 21     }
 22
 23     blk_sz = atoi (argv[1]);
 24
 25     for (iter = 0; iter < 1024; iter++)
 26     {
 27         /*
 28          * The allocated memory is not accessed (read/write) hence the residual memory
 29          * size remains low since no corresponding physical pages are being allocated
 30          */
 31         printf ("\nCurrently at iteration %d\n", iter);
 32         fflush (NULL);
 33
 34         for (count = 0; count < NUM_OF_BLOCKS; count++)
 35         {
 36             myblock = (void *) malloc (blk_sz * 1024);
 37             if (!myblock)
 38             {
 39                 printf ("malloc() fails\n");
 40                 sleep (30);
 41                 return;
 42             }
 43
 44             allocated_mem_ptr_arr[count] = myblock;
 45         }
 46
 47         for (count = 0; count < NUM_OF_BLOCKS; count++)
 48         {
 49             free (allocated_mem_ptr_arr[count]);
 50         }
 51     }
 52 }

作为此基准测试事件的结果，我得到了以下结果( block 大小、默认分配器已用时间、Hoard 已用时间):

1. '1K' '4.380s' '0.927s'
2. '2k' '8.390s' '0.960s'
3. '4k' '16.757s' '1.078s'
4. '8k' '16.619s' '1.154s'
5. '16k' '17.028s' '13m 6.463s'
6. '32k' '17.755s' '5m 45.039s'

可以看出，当 block 大小 >= 16K 时，Hoard 性能会严重下降。是什么原因？我们可以说 Hoard 不适用于分配大块的应用程序吗？

Answer 1

http://locklessinc.com/benchmarks_allocator.shtml 上有一些不错的基准测试和解释。 :

For small allocaitons, it still performs similarly to tcmalloc. However, beyond about 64KiB, it drops drastically in performance. It uses a central "hoard" to redistribute memory between threads. This presents a bottle-neck as only one thread at a time can be using it. As the number of threads increases, the problem gets worse and worse.