2012-01-27 12 views
8

Estoy usando callgrind para crear perfiles de una aplicación de subprocesos múltiples de Linux y, en general, está funcionando muy bien. Empiezo con la instrumentación desactivada (--instr-atstart = no) y luego, una vez que la configuración está lista, la enciendo con callgrind_control -i en. Sin embargo, cuando cambio ciertas configuraciones para tratar de perfilar una parte diferente de la aplicación, comienza a funcionar extremadamente lento incluso antes de encender la instrumentación. Básicamente, parte del código que tomaría unos segundos con la operación normal toma más de una hora con callgrind (instrumentación desactivada). ¿Alguna idea de por qué podría ser así y cómo llevar a cabo la depuración/resolución de la lentitud?callgrind lento con la instrumentación desactivada

+0

¿Cuáles son las "ciertas configuraciones para tratar de perfilar una parte diferente de la aplicación"? – jpalecek

+0

user779, puede verificar la velocidad de la aplicación con la herramienta ["nul" de valgrind] (http://valgrind.org/docs/manual/nl-manual.html) y con [Lackey tool of valgrind] (http: //valgrind.org/docs/manual/lk-manual.html)? – osgx

+0

@jpalecek: todo lo que quiero decir es que los usuarios pueden habilitar/deshabilitar características por configuración y habilitando algunas de las características (se explorará recursivamente para obtener más detalles sobre un conjunto de objetos y eso generará muchos más cálculos) comienza a rastrear . – naumcho

Respuesta

10

Callgrind es una herramienta, construida en valgrind. Valgrind es básicamente un traductor binario dinámico (libVEX, parte de valgrind). Decodificará cada instrucción y JIT-compilará en la secuencia de algunas instrucciones de la misma CPU.

Como sé, no hay forma de habilitar esta traducción (en la implementación valgrind) para el proceso en ejecución, por lo que la traducción dinámica está habilitada en todo momento, desde el inicio del programa. No se puede apagar también.

Las herramientas se crean en valgrind agregando algunos códigos de instrumentación. La herramienta "Nul" (nulgrind) es la herramienta que no agrega instrumentación. Pero cada herramienta usa valgrind y la traducción dinámica está activa todo el tiempo. Encender y apagar en callgrind es simplemente encender y apagar la instrumentación adicional.

CPU virtual, implementado por Valgrind es limitado, hay una lista (incompleta) de limitaciones http://valgrind.org/docs/manual/manual-core.html#manual-core.limits La mayoría de las limitaciones se refieren a operaciones de punto flotante, y se pueden emular incorrectamente.

¿El cambio está relacionado con las operaciones de coma flotante? ¿O con otras limitaciones enumeradas?

También debe saber que "Valgrind serializa la ejecución de modo que solo se ejecuta un subproceso a la vez". (de la misma página manual-core.html)

+0

PD: la sobrecarga nulgrind (instrumentación básica libVEX) es enorme. Nulgrind se estima que es 2-10 veces más lento que el código nativo (por ejemplo, en http://os.inf.tu-dresden.de/papers_ps/vee08-pohle.pdf); cualquier otra herramienta en vlagrind es más lenta que nulgrind. Callgrind con el modo apagado funcionará a la velocidad de nulgrind; callgrind activado se ejecutará varias veces más lento. – osgx

Cuestiones relacionadas