programa - Comparación de rendimiento del mecanismo de asignación de memoria de C++(tcmalloc vs. jemalloc)

tipos de particiones de disco duro (6)

Hay una discusión bastante buena sobre los asignadores aquí:

http://www.reddit.com/r/programming/comments/7o8d9/tcmalloca_faster_malloc_than_glibcs_open_sourced/

Tengo una aplicación que asigna mucha memoria y estoy considerando usar un mejor mecanismo de asignación de memoria que malloc.

Mis principales opciones son: jemalloc y tcmalloc. ¿Hay algún beneficio en usar alguno de ellos sobre el otro?

Hay una buena comparación entre algunos mecanismos (incluido el mecanismo de propiedad del autor, sin bloqueo) en http://locklessinc.com/benchmarks.shtml y menciona algunos pros y contras de cada uno de ellos.

Dado que ambos mecanismos están activos y en constante mejora. ¿Alguien tiene alguna idea o experiencia sobre el desempeño relativo de estos dos?

Recientemente he considerado tcmalloc para un proyecto en el trabajo. Esto es lo que observé:

Gran rendimiento mejorado para el uso intensivo de malloc en un entorno multihilo. Lo usé con una herramienta en el trabajo y el rendimiento mejoró casi el doble. La razón es que en esta herramienta había algunos subprocesos que realizan asignaciones de objetos pequeños en un bucle crítico. Usando glibc, el rendimiento sufre debido a, creo, bloquear las contenciones entre las llamadas malloc / free en diferentes hilos.
Desafortunadamente, tcmalloc aumenta la huella de memoria. La herramienta que mencioné anteriormente consumiría dos o tres veces más memoria (medida por el tamaño máximo del conjunto residente). El aumento de la huella no nos sirve, ya que en realidad estamos buscando formas de reducir la huella de la memoria.

Al final, he decidido no utilizar tcmalloc y, en su lugar, optimizar el código de la aplicación directamente: esto significa eliminar las asignaciones de los bucles internos para evitar las contenciones malloc / free lock. (Para los curiosos, usar una forma de compresión en lugar de usar grupos de memoria).

La lección para usted sería que debe medir cuidadosamente su aplicación con cargas de trabajo típicas. Si puede pagar el uso de memoria adicional, tcmalloc podría ser excelente para usted. Si no, tcmalloc sigue siendo útil para ver lo que obtendría al evitar las llamadas frecuentes a la asignación de memoria a través de subprocesos.

Si recuerdo correctamente, la principal diferencia fue con los proyectos multihilo.

Ambas bibliotecas intentan descontar la adquisición de memoria al hacer que los hilos seleccionen la memoria de diferentes cachés, pero tienen diferentes estrategias:

jemalloc (utilizado por Facebook) mantiene un caché por hilo
tcmalloc (de Google) mantiene un grupo de cachés, y los subprocesos desarrollan una afinidad "natural" para un caché, pero pueden cambiar

Esto llevó, una vez más si recuerdo correctamente, a una diferencia importante en términos de gestión de subprocesos.

jemalloc es más rápido si los subprocesos son estáticos, por ejemplo, utilizando grupos
tcmalloc es más rápido cuando se crean / destruyen hilos

También existe el problema de que, debido a que jemalloc nuevas memorias caché para dar cabida a las nuevas identificaciones de hilos, tener un pico repentino de hilos lo dejará con (en su mayoría) cachés vacíos en la siguiente fase de calma.

Como resultado, recomendaría tcmalloc en el caso general, y reservaría jemalloc para usos muy específicos (baja variación en el número de subprocesos durante la vida útil de la aplicación).

También puedes considerar usar el recolector de basura conservador Boehm . Básicamente, reemplazas cada malloc en tu código fuente con GC_malloc (etc ...), y no te molestes en llamar free . El GC de Boehm no asigna memoria más rápidamente que malloc (es casi igual, o puede ser un 30% más lento), pero tiene la ventaja de tratar con zonas de memoria inútiles de forma automática, lo que puede mejorar su programa (y ciertamente facilita la codificación, ya que no te importa nada más gratis). Y el GC de Boehm también se puede used como asignador de C ++.

Si realmente piensa que malloc es demasiado lento (pero debería hacer un punto de referencia; la mayoría de malloc -s toma menos de microsegundos), y si comprende completamente el comportamiento de asignación de su programa, puede reemplazar algunos malloc-s con su asignador especial (que podría, por ejemplo, obtener memoria del kernel en grandes porciones utilizando mmap y administrar la memoria por su cuenta). Pero creo que hacer eso es un dolor. En C ++ tiene el concepto de allocator y std::allocator_traits , con la mayoría de las plantillas de containers estándar aceptando dicho asignador (vea también std::allocator ), por ejemplo, el segundo argumento de plantilla opcional para std::vector , etc.

Como otros sugirieron, si cree que malloc es un cuello de botella, puede asignar datos en trozos (o usar arenas), o simplemente en una matriz.

A veces, la implementación de un recolector de basura de copia especializado (para algunos de sus datos) podría ayudar. Considere quizás MPS .

Pero no olvide que la optimización prematura es mala, y haga una evaluación comparativa y un perfil de su aplicación para entender exactamente dónde se pierde el tiempo.

Tenga en cuenta que, de acuerdo con la página de inicio ''nedmalloc'', los asignadores del sistema operativo moderno son bastante rápidos ahora:

"Windows 7, Linux 3.x, FreeBSD 8, Mac OS X 10.6 contienen asignadores de tecnología de punta y es probable que ningún asignador de terceros los mejore significativamente en los resultados del mundo real"

http://www.nedprod.com/programs/portable/nedmalloc

Por lo tanto, es posible que pueda simplemente recomendar la actualización de sus usuarios o algo así :)

Tu publicación no menciona el subprocesamiento, pero antes de considerar mezclar los métodos de asignación de C y C ++, investigaría el concepto de grupo de memoria. BOOST tiene uno bueno.