\subsubsection{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 o el uso de la cache entre otros.
Independientemente de la herramienta que esté en uso, {\it Valgrind} toma el control del programa desde el inicio
y, de esta manera, el programa se ejecuta en una CPU creada por el propio {\it Valgrind}.

Antes de iniciar la ejecución de un programa, el código se instrumentaliza por el propio {\it Valgrind}.
Dependiendo del plugin que se vaya a usar, la instrumentalización se adapta al resultado que se espera obtener.



%   - 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?
Las arquitecturas soportadas son x86, AMD64 y PPC32 siempre bajo sistema operativo Linux.
En las arquitecturas x86 y AMD64 no hay soporte para las instrucciones 3DNow!\footnote{3DNow! es una extensión multimedia creada por AMD, implementada a partir del AMD k6-2 la cual es un añadido de instrucciones SIMD al tradicional conjunto de instrucciones x86, para obtener mayor rendimiento en el procesamiento vectorial.}.
Otra limitación  es referente a la gestión de memoria.
Sin en vez de usar las instrucciones de gestión de memoria estándares (malloc/free/delete/new) se usan instrucciones personalizadas, aunque debería funcionar, puede que haya errores a la hora de chquear la memoria.

%  - 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?
El plugin que nos interesa para nuestro proyecto es {\it Callgrind}.
Callgrind es un profiler que se basa en la simulación de los niveles de cahce I1, D1 y L2.
El resultado de {\it Callgrind} es un fichero de salida en el cual se informa  de los fallos de caché, accesos a memoria y acumulación de instrucciones ({\it instruction accruing}) para cada línea del código fuente.


%   - 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, habPPCria 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.


