\section{Resultados}
\FloatBarrier
\pagebreak
\subsection{Blur Gaussiano}

A diferencia del filtro HSL la l\'ogica de procesamiento de ambas implementaciones del blur \textbf{no} depende del tipo de im\'agenes, por lo que se procedi\'o a realizar unas pruebas preliminares con distintas imagenes aleatorias y mon\'ocromas. Los tiempos de ejecuci\'on de dichas imagenes resultaron ser similar, habiendo peque\~nas diferencias aleatorias que se relacionaron con otras actividades que pudo haber estado realizando el sistema operativo. Por lo que se eligi\'o una de esas im\'agenes al azar para realizar el resto de las pruebas.

Como se menciona en las hip\'otesis del blur, se puede observar que deb\'ido al calculo adicion\'al que realiza la implementaci\'on de \textbf{Blur 2} al momento de procesar las \'ultimas columnas de la imagen, en el cual se vuelven a procesar una cantidad de p\'ixeles que causa que en im\'agenes peque\~nas se obtenga un rendimiento similar a la implementaci\'on de \textbf{Blur 1} o \textbf{C}. En im\'agenes m\'as grandes ese procesamiento repetido se vuelve despreciable y se puede apreciar la ganancia de velocidad al realizar muchas menos operaciones de lectura.

Se encontr\'o que en el caso de procesamiento de la im\'agen de $16x16$ el tiempo de ejecuci\'on fue generalmente mayor, se intent\'o buscar las causas de dicho comportamiento, pero solamente se pudo encontrar que las mismas no dependen, en general del algoritmo de procesamiento.%, sino del tiempo asignado por el CPU para la tarea. Esto es lo que causa que la desviaci\'on sea tan grande en este caso.

En un principio resulta extra\~no el comportamiento de la implementaci\'on $1$, en la cual los tiempos dieron muy similares a los de la implementaci\'on \emph{C}, aunque la misma realiza menos lecturas de memoria. Deducimos, entonces, que debido a la cantidad de saltos condicionales que posee dicha implementaci\'on el procesador no puede realizar un manejo de prefetch \'optimo, provocando m\'as estados de espera. Mientras que en la implementaci\'on \emph{C} el compilador realiza optimizaciones y el procesamiento es m\'as secuencial, lo que puede aumentar su performance.

En el resto de los casos el comportamiento es el esperado y solo var\'ia en funci\'on del tamaño de la imagen. Se conjetura entonces que el rendimiento de los algoritmos est\'a ligado a la cantidad de lecturas de memoria, y muy fuertemente a la cantidad de saltos condicionales en medio del procesamiento.

En la figura \ref{fig:figure_blur} se puede observar los resultados de las pruebas realizadas con los diferentes tama\~nos de imagen.

\begin{figure}[htpb]
    \centering
    \caption{Tiempo de ejecuci\'on de im\'agenes arbitrarias para el filtro blur }
    \label{fig:figure_blur}
    \includegraphics[width=0.75\columnwidth]{include/figure_blur}
\end{figure}

\FloatBarrier
\subsection{Diferencia de Im\'agenes}

En la primera prueba, para poder notar diferencias significativas, en los tests se modific\'o el c\'odigo de la aplicaci\'on para ejecutar 500 veces cada filtro, de esta manera se evita cargar nuevas instancias de los programas y calcular un tiempo incorrecto debido a la carga de d\'isco de las im\'agenes, cache de disco, la invocaci\'on de tareas, y se puede evaluar el uso de cache.

Los tests se corrieron utilizando la herramienta \emph{perf} y obteniendo los datos de cache, instrucciones y otras operaciones para ayudar en la generaci\'on de las conclusiones. \\
Se utilizaron im\'agenes de diferentes tama\~nos para simular distintos casos y estudiar el comportamiento del filtro. Como el filtro no consiste, ni tiene l\'ogica que dependa del tipo de im\'agen (aleatoria, alto contraste, etc) nos basamos espec\'ificamente en tama\~nos. \\
Cada prueba se ejecut\'o 10 veces y se calcul\'o el promedio para el gr\'afico y la desviaci\'on est\'andar que se obtuvo.

En cada ejecuci\'on se utiliz\'o un valor de merge de \emph{0, 0.13, 0.23, 0.33333, 0.4999, 0.5, 0.6542223, 0.75, 0.99999, 1} para probar los diferentes valores, pero se encontr\'o que no se obtienen cambos significantes al modificar dichos valores.

En la figura \ref{fig:figure_blur} se puede observar los tiempos y resultados.

\begin{figure}[htpb]
    \centering
    \caption{Tiempo de ejecuci\'on de im\'agenes arbitrarias, para el filtro merge con valores arbitrarios }
    \label{fig:figure_merge}
    \includegraphics[width=0.75\columnwidth]{include/figure_merge}
\end{figure}

En la mayor\'ia de los casos los cache-references rondaban el $75.0\%$ mientras que los cache-mises se mantenian menores a $0.05\%$. \\
Puede observarse lo que se hab\'ia predecido en la hip\'otesis, que los tiempos de ejecuci\'on comparados a la implementaci\'on \emph{C} son muchos menores en ambos casos de Assembler, posiblemente a la menor cantidad de lecturas de memoria. \\
Debido a que entra ambas implementaciones en Assembler poseen la misma cantidad de lecturas de memoria se puede conjeturar que la diferencia entre ambas implementaciones se debe a las operaciones extras de conversi\'on que se realiza en la implementaci\'on $1$ y a que se procesa de a 1 p\'ixel por instrucci\'on. En la implementaci\'on $2$ hay aproxim\'adamente un $20\%$ de instrucciones menos por p\'ixel a procesar que en la implementaci\'on $1$, hecho que puede observarse por los resultados.

Se vi\'o que el tiempo de ejecuci\'on en una imagen de $512x512$ es mucho mayor que $1024x1024$, en especial en la implementaci\'on en C, viendo los datos del cache no pudimos llegar a la conclusi\'on de por que puede funcionar mas lento, ya que los valores son normales y consistentes con las imagenes de $128x128$ y $1024x1024$.