\subsection{Proceso de desarrollo del TP}
\label{subsec:intro-desarrollo}
El proceso de desarrollo del \textbf{TP} consistió en realizar en primera instancia un rápido prototipado en Matlab/RStudio/Scilab (dependiendo de la disponibilidad de la computadora que se usara en ese momento; de ahora en más, me referiré a esos programas como \textbf{MRS}) de algoritmos y ecuaciones que se pudieran encontrar en Internet de diversos efectos. 

El uso de esos programas como primer acercamiento a un efecto facilitaba enormemente el trabajo, pues al utilizar un lenguaje de muy alto nivel se simplificaba el manejo de la lectura y escritura de los archivos, el espacio en memoria para los mismos, la manipulación de los datos (poder trabajar sobre un vector entero con una sola operación, por ejemplo), etc.\vspace{\baselineskip}

Una vez certificado que con ese algoritmo se consiguiera el efecto auditivo deseado, se pasó a desarrollarlo en \textbf{C}, siempre verificando que el resultado final de la señal coincidiera con el obtenido en \textbf{MRS}. Como utilizar el comando \textit{diff} de UNIX directamente sobre los archivos no siempre daba el resultado querido (aventuro a decir que por diferencias de aproximación entre \textbf{MRS} y \textbf{C}), se optó por otra metodología utilizando el programa \textbf{Audacity}, que se explicará en la sección \fullref{subsec:chequeo-diferencias}.\vspace{\baselineskip}

Obtenido el resultado deseado utilizando \textbf{C}, se pasó finalmente a programar el mismo algoritmo en \textbf{Assembler}, haciendo uso de las instrucciones que ofrece el conjunto de instrucciones SSE para manejar múltiples datos con una única instrucción (SIMD). Se utilizaron instrucciones incluidas hasta la extensión SSE4 (en particular por \textit{PTEST}, y \textit{ROUNDPS}/\textit{ROUNDSS}). 
Luego de obtener en \textbf{Assembler} un código que parecía aceptable (es decir, que no terminara abruptamente con un segfault), se comenzó con un proceso iterativo de corrección, mediante la comparación del archivo de audio obtenido con el de \textbf{C}, utilizando \textbf{Audacity} como se mencionó previamente. Las diferencias entre ambos muchas veces provenían de casos bordes; los problemas encontrados a lo largo del desarrollo del TP se tratarán en la sección \fullref{subsec:desarrollo-problemas}.\vspace{\baselineskip}

El objeto de la programación en \textbf{C} además de Assembler, si bien implica el ''doble'' de trabajo, se debe a dos puntos en particular. En primer medida, era una buena manera de poder bajar el nivel del código original en \textbf{MRS}, despojándolo de las bondades que dichas herramientas ofrecen. Por otro lado, tener el código en \textbf{C} sirve también para comparar la mejora de rendimiento con el uso de las instrucciones SIMD. \vspace{\baselineskip}

Para calcular el rendimiento en ambos lenguajes se utilizó la librería \textit{tiempo.h} utilizada por la cátedra en el \textbf{TP N\degree 2} del 1er. Cuatrimestre de 2011. Cuando los resultados con la misma no eran satisfactorios (p.ej., \textbf{Assembler} era más lento que \textbf{C}), se procedió a utilizar una herramienta de profiling (\textbf{callgrind} en conjunto con \textbf{KCacheGrind}, se hablará de ellas más adelante) para poder identificar dónde exactamente estaban las secciones lentas del código en \textbf{Assembler}, y poder tomar medidas para resolverlo. De los casos puntuales donde se utilizó esto se hablará en las secciones \fullref{sec:desarrollo}, \fullref{sec:resultados} y \fullref{sec:analisis}.\vspace{\baselineskip}

Se desarrolló también una rudimentaria interfaz gráfica para tratar de evitar la utilización de la línea de comandos (en particular por la cantidad de argumentos que hay que manipular para los diversos efectos) y que la utilización del programa sea más amigable. Se hablará de ella en la sección \fullref{subsec:gui}.
 
