%Información extraída del libro de arquitectura de computadores \cite{biblioC:Arquitectura}.
\chapter{Arquitectura Computadores}

Tanto en este capítulo como en el siguiente están los conceptos que he extraído de los respectivos libros.
Los conceptos que al final se queden en la memoria estarán repartidos entre los distintos capítulos y secciones ya creadas y tanto este capítulocomo el siguiente, desaparecerán.


\section{Rendimientos y costes} %%cap. 1 & 2

Nuestro interés en este capítulo del libro es la definición de términos relacionados con la medida del tiempo de ejecución de un programa,
el desglose del tiempo de ejecución global,
el cálculo de rendimiento de un programa
y formas de calcular dicho rendimiento.

Esto iría en la sección de "medidas de eficiencia" de nuestra memoria.



- Tiempo de respuesta o Latencia: Tiempo transcurrido entre el comienzo y el final de un evento.

- Productividad o Throughput: Cantidad total de trabajo realizado en un tiempo determinado. También conocido como ancho de banda.

- Los términos <<tiempo de respuesta>>, <<tiempo de ejecución>> y <<productividad>> se utilizan cuando se está desarrollando una tarea de cálculo completa.

- Los términos <<latencia>> y <<ancho de banda>> se usan cuando se habla de un sistema de memoria.

- La latencia depende de una serie de factores no deterministicos, como lo que el disco esté haciendo en el instante de la petición de E/S y del número de tareas que estén esperando acceder al disco. Estos valores son variables, con lo cual, se suele hablar del tiempo medio de respuesta de un acceso al disco.

- Si comparamos dos tiempos de ejecución, para saber la diferencia de velocidad entre una y otra de manera porcentual, se usa la formula:

\begin{displaymath}
n=100*\frac{Rendimiento_x - Rendimiento_y}{Renidimiento_y}
\end{displaymath}

- Una forma de optimizar procesos es {\bf acelerar los casos comunes}. Por ejemplo, en el caso de sumar dos números en la CPU, el caso menos probable es que haya overflow, por lo tanto, optimizamos el caso más común (que no haya overflow) para que sea más eficiente. Esto causará que, cuando haya overflow, el proceso será más lento, pero como este caso es infrecuente, la optimización global habrá mejorado.

- Ley de Amdahl: {\it La mejora obtenida en el rendimiento al utilizar algún modo de ejecución más rápido, está limitada por la fracción de tiempo que se pueda utilizar ese modo más rápido}. Esta ley define la ganancia de rendimiento o aceleración (speed up) que puede lograrse al utilizar una característica particular.

$
Aceleracion de rendimiento =
\frac{Rendimiento de la tarea completa utilizando la mejora cuando sea posible}
{Rendimiento de la tarea completa sin utilizar la mejora}=
\frac{Tiempo de ejecucion de la tarea sin utilizar la mejora}
{Tiempo de ejecucion de la tarea completa utilizando la mejora cuando sea posible}
$


- Localidad de referencia: los programas tienden a reutilizar los datos e instrucciones que han utilizado recientemente. Una regla empírica, muy corroborada, es que un programa emplea el 90 por 100 de su tiempo de ejecución en el 10 por 100 del código.
Esto implica que basándose en el paso reciente del programa, se puede predecir que instrucciones y datos utilizará un programa.

- Una vez se ha establecido un conjunto de requerimientos funcionales, el arquitecto debe intentar optimizar el diseño.
Que el diseño elefido sea óptimo depende de la métrica elegida.
Las métricas más comunes involucran coste, rendimiento, fiabilidad y tolerancia a fallos.

\subsection{Rendimiento}
%%Esto va a medidas de eficiencia
% - El rendimiento se suele medir como una frecuencia de eventos por segundo, ya que el tiempo más bajo significa mayor rendimiento.
% 
% - Tiempo de reloj, tiempo de respuesta o tiempo transcurrido (elapsed time): LAtencia para completar una tarea, incluyendo accesos a disco, accesos a memoria, actividades E/S, gastos del sistema operativo.
% Sin embargo, como en multiprogración, la CPU trabaja sobre otro programa mientras espera las E/S y, necesariamente, puede no minimizar el tiempo transcurrido de un programa;
% es necesario un término que tenga en cuenta esta actividad.
% 
% - Tiempo de CPU: mide el tiempo que la CPU está calculando sin incluir el tiempo de espera para las E/S o para ejecutar otros programas.
% El tiempo de CPU puede dividirse en tiempo empleado por la CPU en el programa (tiempo de usuario)
% y tiempo empleado por el sistema operativo realizando tareas requeridad por el programa (tiempo de sistema).

- Rendimiento del sistema, se utiliza para referenciar el tiempo transcurrido en un sistema no cargado(¿?),
mientras que el tendimiento de la CPU se refiere al tiempo de CPU del usuario.


- La mayoría de los computadores se construyen utilizando un reloj que funciona a una frecuencia constante.
Estos eventos discretos de tiempo se denominan pulsos, períodos o ciclos de reloj.

$
Tiempo_CPU = Ciclos * T_Ciclo
$


$
Tiempo_CPU=\frac{Ciclos}{Frec_Ciclo}
$

Ciclos: ciclos de reloj de CPU para un programa
T: duración del ciclo de reloj
Frec: frecuencia de reloj


%%es necesario comentar MIPS  y MFLOPS??


\subsubsection{Elección de programas para evaluar el rendimiento}

El candidato perfecto para calcular el rendimiento de un computador es el usuario habitual.
Sin embargo, como el usuario no suele realizar esta tarea, hay programas que realizan esta evaluación.
Hay cuatro niveles de programas utilizados en estas circunstancias, listados a continuación en orden decreciente de precisión de la previsión.


\begin{itemize}
\item {\it Programas (Reales)}: Aunque el comprador puede no conocer que fracción de tiempo se emplea en estos programas, sabe que algunos ususarios los ejecutarán para resolver problemas reales.
Ejemplos son compiladores de C, software de tratamiento de textos como \LaTeX y herramientas CAD como Spice.
Los programas reales tienen entradas, salidas y opciones que un usuario puede seleccionar cuando está ejecutando el programa.

\item{\it Núcleos (Kernels)}: Se han hecho algunos intentos para extraer ciertas piezas clave de  programas reales y utilizarlas para evaluar el rendimiento.
<<Livermore Loops>> y <<Limpack>> son los ejemplos mejor conocidos.
De forma distinta a los programas reales,ningún usuario puede correr los programas <<núcleo>>;
únicamente se emplean para evaluar el rendimiento.
los nucleos son adecuados para aislar el rendimiento de las caracterisiticas individuales de una máquina para espliar las razones de la diferencia en los rendimientos de programas reales.

\item {\it Benchmarks reducidos (toys)}: Los benchmarks reducidos, normalmente, tienen entre 10 y 100 líneas de código y producen un resultado que el usuario conoce antes de ejecutarlos.
Programas como la <<Criva de Eratóstenes>>, <<Puzzle>> y <<Clasificación rápida>> son populares porque son pequeños.
Fáciles de introducir y ejecutar en cualquier computador.
El mejor uso de estos programas es empezar asignaciones de programación.

\item {\it Benchmarks sintéticos}: Análogos en filosofía a los <<nucleos>>,
los <<benchmark sinteticos>> intentan determinar la frecuencia media de operaciones y operandos de un gran conjunto de programas.
Whetstone y Dhrystone son benchmarks sintéticos populares.
Igual que ocurre con los nucleos, ningún usuario ejecuta los benchmarks sintéticos porque no calculan nada que ningún usuario pueda utilizar.
Los benchmarks sintéticos están aún más lejos de la realidad porque el código de los nucelos se extrae de programas reales, mientras que el códifo sintético se crea artificalmente para determinar un perfil medio de ejecución.
Los benchmarks sintéticos no son partes de programas reales, mientras que los demás pueden serlo.

\end{itemize}


%%%iba a comentar costes de arquitecturas, pero esto no sé si sería alejarse mucho del tema a tratar.

\subsection{Falacias y pifias}

- {\it Las métricas independientes del hardware predicen el rendimiento}.
Es falso que la velocidad y el tamaño del código tengan una relación directa.
El tamaño del código es importante en el caso que el espacio de memoria sea limitado, pero un código corto no implica una ejecución más eficiente.
El motivo es que el tiempo de ejución también depende del tipo de instrucciones usada ya que no todas las instrucciones tardan el mismo número de ciclos.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Diseño de instrucciones} %%cap. 3
\label{sec:disInstr}
El objetivo que nos interesa de este capítulo es mostrar los diferentes caminos existentes para optimizar un código.
Para ello hacemos una introducción a las diferentes formas de organizar las instrucciones,
a los 3 tipos de almacenamiento más comunes
y a los tipos de operaciones existentes
para terminar con una tabla en la que se muestre como afectan las modificaciones de diferentes niveles en la optimización del sistema.


- Las instrucciones se clasifican generalmente en 5 dimensiones dependiendo del papel que juegan en diferenciar los repertorios de instrucciones.
\begin{itemize}
\item Almacenamiento de operandos en la CPU:
Además de en memoria ¿dónde se encuentran los operandos?
\item Número de operandos explñicitos por instrucción:
¿Cuántos operandos son designados explícitamente en una instruccion tipica?
\item Posición del operando:
¿Puede cualquier operando de una instrucciond ela ALU estar localizado en memoria o deben algunos o todos los operandos estar en la memoria interna de la CPU?
Si un operando está localizado en memoria,¿cómo es especifica la posición en memoria?
\item Operaciones:
¿Qué operaciones se proporcionan en el repertorio de instrucciones?
\item Tipo y tamaño de operandos:
¿Cuál es el tipo de tamaño de cada operando y cómo se especifica?
\end{itemize}


3 tipos de almacenamiento interno de la CPU
\begin{itemize}
\item Pila
\item Acumulador
\item Conjunto de registros
\end{itemize}

Características de pila, acumulador y registros:

- Los registros permiten una ordenación más flexible que las pilas o acumuladores a la hora de evaluar expresiones.

- Los registros pueden utilizarse para que contengan variables.
Cuando las variables están ubicadas en registros, se reduce el tráfico de memoria, se acelera el programa (los registros son más rapidos que la memoria )y mejora la densidad del código (ya que un registro se puede nombrar con menos bits que una posición de memoria).

- los tres tipos más comunes de  máquinas de registros de propósito general son:
\begin{itemize}
\item Registro-Registro
\item Registro-Memmoria
\item Memoria-memoria
\end{itemize}

\subsection{Direccionamiento de memoria}

- Dependiendo del modo de redireccionamiento, podremos reducir significativamente el recuento de instrucciones. (pag 106)


pag 123 ----> tipos principales de optimizaciones y ejemplos de cada clase

pag 124 ---->efectos de rendimiento de varios niveles de optiimización.



\section{Utilización de instrucciones con diferentes arquitecturas} %%cap. 4

Este capítulo nos sirve para realizar una comparativa entre diferentes arquitecturas y cómo varían las instrucciones para cada una de ellas.

Este capítulo irá relacionado con Valgrind, ya que Valgrind fija la arquitectura en 386, con lo cual, nos libraríamos de estas diferencias.


\section{Diseño de la jerarquía de memoria} %%cap. 8

Este capitulo tb iría relacionado con Valgrind ya que de aquí podemos extraer información de tipos de memoria, tipos de cache y optimizaciones posibles.
 
