\section{Valgrind/Callgrind/Kcachegrind}
\label{sec:callgrind}

Como hemos comentado en el apartado \label{sec:valgrind}, Valgrind es un simulador de ejecución de binarios que permite usar plugins 
para instrumentar diferentes aspectos tales como el uso de memoria, problemas 
de concurrencia, el uso de la cache...

Como la ejecución es simulada, el resultado es independiente de factores tales como 
la ejecución de programas concurrentes o
la arquitectura y la plataforma reales en las que se está trabajando.
Ésto implica que los resultados obtenidos en diferentes ejecuciones sean comparables

Varios ejemplos de plugins serían {\it Memcheck}, {\it Addrcheck}, {\it Massif} o {\it Helgrind}. 
%Addrcheck, a lightweight cousin of Memcheck, running much faster and requiring less memory, but catching fewer types of bugs.
%Massif, a heap-profiler.
%Helgrind, a tool capable of detecting race conditions in multithreaded code.
El plugin que cubre las necesidades del proyecto presentado es {\it Callgrind}.
{\it Callgrind} es un profiler que calcula el tiempo de ejecución en ciclos de procesador con diferentes niveles de granularidad.
%Se podria entender que la granularidad del tiempo de ejecucion es el programa 
%entero. En el fondo el tiempo de ejecucion es de cada instruccion 
%maquina/instruccion fuente/ metodo. 
El uso de {\it Callgrind} es conveniente por varios motivos.
Primeramente, porque el usuario puede configurar las dependencias que se tendrán en cuenta para evaluar la eficiencia del código.
Algunas de estas dependencias son la simulación de cache, el tipo de llamadas o los saltos en el código.
Otra ventaja de {\it Callgrind} es que el fichero de salida esta estructurado por funciones.
La estructuración del fichero agiliza el proceso de parseo y la toma de los costes de cada uno de los tests de eficiencia.

{\it Kcachegrind} es una herramienta que permite visualiza el fichero de salida de {\it Callgrind} mediante gráficos y relaciona cada una de las líneas de coste del fichero de salida con las líneas de código correspondiente.
El formato de comunicacion entre {\it Callgrind} y {\it Kcachegrind}, no es un formato pensado para que lo lean humanos, es dificil de leer pero muy facil de parsear.



%- Por un lado la descripcion de la herramienta, incluida su relacion con 
%KCachegrind, que es necesario para que el lector entienda de que se le habla. 
%No es necesario que entres muy a fondo. Con lo que has dicho filtrando las 
%valoraciones, y introduciendo kcachegrind y relacionandolo con callgrind 
%mediante el fichero que genera.
%
%- Despues separaria una frase breve de porque esa herramienta es util para el 
%proyecto. No pondria ventajas, solo, brevemente que papel juega en tu 
%sistema. 
%        'Valgrind nos permitira obtener medidas fiables y repetibles de la
%         eficiencia de porciones concretas del codigo.' 
%Es una frase que deberia de poder empalmarse por ejemplo, con la que digas en 
%cppunit: 
%       'Cppunit nos permitira organizar los casos de tests en test suites,
%        gestionara su ejecucion ordenada. Tambien facilita el compartir 
%        codigo de configuracion y limpieza entre casos de test.'
%Si ambos parrafos los resaltas de un mismo modo especial (\begin{citation}) 
%demostraras bastante control sobre lo que estas escribiendo.
%
%- Seguiria, ahora si, con las ventajas, pero tambien con los defectos pero lo 
%haria desde el punto de vista de que tiene en cuenta y, sobretodo, no tiene 
%en cuenta en la simulacion. Algunos aspectos a considerar (si hay cosas que 
%no te suenan no te pongas nervioso, ya los hablaremos):
%
%   - Que arquitecturas y sistemas operativos. Que arquitecturas soporta dentro 
%de la familia intel (i386, i586, PPro, P2/3/4, IA64, AMD...) y con que 
%limitaciones? Como se consideran las Instrucciones vectoriales (MMX, SSE...)? 
%Es realista su simulacion? Como se consideran las llamadas a sistema de 
%linux?
%
%   - Simulacion de cache.  L1? L2? Cache de datos? Cache de instrucciones? 
%Politica de reemplazo (write thru...)? Como de realista es el modelo (x10, 
%x100...)? En un escenario real, afectaria el multiproceso o el multitheading 
%a la cache? La cache por defecto es la tipica? Varia mucho si cambias la 
%cache?
%
%   - Instrucciones: Cuentan mas unas que otras? En que se diferencia ese 
%modelo de la realidad? 
%
%   - Pipeline: La verdad es que no se si se tiene en cuenta, habria que 
%mirarlo. Que se cuenta? Los ciclos de la instruccion, o los ciclos en 
%pipeline? El coste de algunas instrucciones a veces se enmascaran con otras 
%mas largas y a veces hace que se ejecuten instrucciones que no deberian.
%
%    - Jumps: Sabemos que hay opciones pero no sabemos que hacen. Los jumps 
%provocan fallos en cache de instrucciones, se tienen en cuenta? Cuando la 
%ejecucion  pipeline supone que un condicional tomara una rama y toma la otra 
%el coste asociado se tiene en cuenta? Es realista?
%
%   - Excepciones: Dado que son externals al programa (menos las fallo de cache 
%y similares) no creo que valgrind las tenga que simular. Pero hay que 
%comentarlo.
%
%   - ...algo que me deje, igual estoy siendo demasiado exhaustivo pero algo de 
%esto debe entrar. Entenderas que dar respuesta a este tipo de preguntas o a 
%otras por el estilo demostrara tu talla como ingeniero.
%
%   - Y lo matas con una micro conclusion de porque las ventajas nos solucionan 
%problemas y porque las limitaciones ya nos estan bien a nosotros (si hace 
%falta pregunta a tus usuarios).
%
%- Finalmente, ahora si, pondria como de practica es la herramienta 
%(consideraciones mas de ingenieria tecnica): Tarda mucho en ejecutarse, 
%ofrece mucha informacion util, usa un formato no leible a los humanos (que 
%tuvimos que echar mano al codigo fuente de kcachegrind para entenderlo),  que 
%despues de eso se hizo una documentacion del formato (o fue antes?), como de 
%accesible ha sido la comunidad (esto no es tan de tecnica, pero esta dentro 
%del tema hands on, guardate algo para las conclusiones)....



