Los siguientes cambios en un sistema de cómputo, incrementan la productividad, decrementan el tiempo de respuesta, o ambas?

Transcripción

1 1.4 El papel del rendimiento Cuando se dice que una computadora es más rápida que otra, qué se quiere decir? El usuario de una computadora individual puede decir que ésta es más rápida cuando ejecuta un programa en menos tiempo, mientras que el director de un centro de cálculo puede decir que una computadora es más rápida cuando completa más tareas en una hora. El usuario de la computadora está interesado en reducir el tiempo de respuesta el tiempo transcurrido entre el comienzo y el final de un evento - denominado también tiempo de ejecución o latencia. El director del centro de cálculo está interesado en incrementar la productividad (throughput) - la cantidad total de trabajo realizado en un tiempo determinado. Ejemplo: Productividad y tiempo de respuesta. Los siguientes cambios en un sistema de cómputo, incrementan la productividad, decrementan el tiempo de respuesta, o ambas? 1. Reemplazar el procesador en una computadora con una versión más rápida. 2. Agregar un procesador a un sistema que utiliza múltiples procesadores para tareas separadas por ejemplo, el manejo de un sistema de reservaciones en una aerolínea. Respuesta: Decrementar el tiempo de respuesta casi siempre mejora la productividad. Por lo tanto, en el caso 1, tanto la productividad como el tiempo de respuesta son mejorados. En el caso 2, ninguna tarea se realizará de manera mas rápida, de manera que solo se incrementa la productividad. Sin embargo, si la demanda para el procesamiento en el segundo caso fue al menos tan grande como la productividad, el sistema debe necesariamente requerir de una cola de tareas. En este caso, al incrementar la productividad podría también mejorar el tiempo de respuesta, dado que reduciría el tiempo de espera en la cola. Así, en muchos sistemas de cómputo reales, cambiar el tiempo de ejecución afecta a la productividad y viceversa. Cuando se comparan alternativas de diseño, con frecuencia se quiere relacionar el rendimiento de dos máquinas diferentes, por ejemplo X e Y. La frase «X es más rápida que Y» se utiliza para indicar que el tiempo de respuesta o tiempo de ejecución es inferior en X con respecto a Y para una tarea dada. En particular, «X es en n veces más rápida que Y» significa Tiempo de ejecución Y Tiempo de ejecución X = n

2 El rendimiento mantiene una relación inversa al tiempo de ejecución, es decir, a un menor tiempo de ejecución se tiene un mayor rendimiento; y viceversa. Por lo que se mantiene la siguiente relación: n = 1 Tiempo de Ejecución Y Rendimiento Rendimiento X = Y = 1 Tiempo de Ejecución X Rendimiento Rendimiento Y X La frase «la productividad de X es en 1.4 veces superior que la de Y» significa que el número de tareas completadas por unidad de tiempo en la máquina X es 1.4 veces el número de tareas completadas en la máquina Y. Como rendimiento y tiempo de ejecución son recíprocos, incrementar el rendimiento hace decrecer el tiempo de ejecución. Para evitar confusiones entre los términos «incrementar» y «decrementar», habitualmente se dice «mejorar el rendimiento» o «mejorar el tiempo de ejecución» para hacer referencia a un incremento del rendimiento y una disminución del tiempo de ejecución. Ejemplo: Rendimiento relativo. Una máquina A ejecuta un programa en 10 segundos y una máquina B ejecuta el mismo programa en 15, Cuánto es mas rápida A que B? Respuesta: Si A es n veces más rápida que B significa que: o RENDIMIENTO RENDIMIENTO A = TIEMPO _ DE _ EJECUCIÓN TIEMPO _ DE _ EJECUCIÓN B n B = A n De manera que la razón de rendimiento es: 15/10 = 1.5, y A es por lo tanto, 1.5 veces más rápida que B. En resumen, el rendimiento permite la comparación de dos computadoras; aunque aparentemente este tema cae fuera de contexto en un curso de arquitectura de computadoras, mas adelante se demuestra que no es así. Por que para una misma arquitectura se analizaran tres diferentes tipos de implementaciones, y el objetivo en cada nueva implementación será alcanzar un aumento en el rendimiento.

3 De hecho, desde 1985 la industria de computadoras alcanzó un nuevo estilo de arquitectura, iniciando un período en el cual el rendimiento ha aumentado a una velocidad mucho más rápida. Al concentrar los avances en la tecnología de circuitos integrados, las mejoras en la tecnología de compiladores y las nuevas ideas arquitectónicas, los diseñadores pudieron crear una serie de máquinas que mejoraban el rendimiento, en un factor de casi 2, cada año. Estas ideas están ahora proporcionando una de las mejoras en rendimiento más significativas que las sostenidas en los últimos veinte años. Estas mejoras han sido posibles al tomar en cuenta una serie de importantes avances tecnológicos, junto a un mejor conocimiento empírico sobre la utilización de las computadoras. De esta fusión ha emergido un estilo de diseño de computadoras basado en datos empíricos, experimentación y simulación. 1.5 Métricas para determinar el rendimiento El tiempo de ejecución El tiempo es la medida del rendimiento de la computadora: la computadora que realiza la misma cantidad de trabajo en menos tiempo es la más rápida. El tiempo de ejecución de un programa se mide en segundos por programa. El tiempo se puede definir de formas distintas dependiendo de lo que se quiera contar. La definición más directa de tiempo se denomina tiempo de reloj (wall-clock time), tiempo de respuesta (response time), o tiempo transcurrido (elapsed time). Esta es la latencia para completar una tarea, incluyendo accesos a disco, accesos a memoria, actividades de entrada/salida, gastos del sistema operativo - todo. Actualmente las computadoras trabajan a tiempo compartido, de manera que un procesador puede trabajar sobre diferentes programas. En tal caso, los sistemas intentan mejorar la productividad en lugar de intentar disminuir el tiempo transcurrido para un programa individual. Por lo que es conveniente distinguir entre el tiempo transcurrido y el tiempo en que el procesador está trabajando al servicio de un programa. Con el tiempo de CPU debe reconocerse esta distinción, por lo que se debe medir el tiempo que el CPU está computando una tarea sin incluir el tiempo de espera para las E/S o para ejecutar otros programas. (Obviamente, el tiempo de respuesta visto por el usuario es el tiempo transcurrido del programa, no el tiempo de CPU). Además, el tiempo de CPU puede dividirse en: el tiempo empleado por el CPU en el programa tiempo de CPU del usuario, y el tiempo empleado por el sistema operativo realizando tareas requeridas por el programa tiempo de CPU del sistema. Estas distinciones las refleja el comando «time» de UNIX, que devuelve lo siguiente: 90,7u 12,9s 2:39 65% El tiempo de CPU del usuario es de 90,7 segundos, el tiempo de CPU del sistema es de 12,9 segundos, el tiempo transcurrido es de 2 minutos y 39 segundos (159 segundos), y el porcentaje de tiempo transcurrido que es el tiempo de CPU es

4 = 0.65 = 65% En este ejemplo, más de un tercio del tiempo transcurrido se gastó esperando las E/S o ejecutando otros programas, o ambas cosas. En ocasiones no se considera al tiempo de CPU del sistema debido a la poca precisión de los sistemas operativos para obtenerlo, por lo que resultará poco realista considerar el tiempo de CPU del sistema cuando se comparan rendimientos entre máquinas con sistemas operativos diferentes. Por otro lado, el código del sistema de algunas máquinas está incluido en el código del usuario, en otras; y ningún programa corre sin que se ejecute el sistema operativo sobre el hardware, lo que es un argumento a favor de utilizar la suma del tiempo de CPU del usuario y del tiempo de CPU del sistema como la medida del tiempo de ejecución de un programa Rendimiento del CPU La mayoría de las computadoras se construyen utilizando un reloj que funciona a una frecuencia constante. Estos eventos discretos de tiempo se denominan pulsos, pulsos de reloj, períodos de reloj, relojes, ciclos o ciclos de reloj. Los diseñadores de computadoras referencian el tiempo de un período de reloj por su duración (por ejemplo, 10 ns) o por su frecuencia (por ejemplo, 100 MHz). El tiempo de CPU para un programa puede expresarse entonces de dos formas: Tiempo de CPU = Ciclos de reloj de CPU para un programa x Duración del ciclo de reloj O Tiempo de CPU = Ciclos de reloj de CPU para un programa Frecuencia de reloj En esta última expresión queda claro que el diseñador de hardware puede mejorar el rendimiento disminuyendo la duración del ciclo de reloj o el número de ciclos de reloj requeridos por un programa. Ejemplo: Mejorando el Rendimiento. Un programa X se ejecuta en 10 segundos en una máquina A, la cual es de 400 MHz. Se intentará ayudarle al diseñador de hardware para que realice una máquina B, que ejecutará ese programa en 6 segundos. El diseñador ha determinado que es posible un incremento sustancial de la frecuencia de reloj, sin embargo, este incremento afectará al resto del CPU ocasionando que la máquina B requiera 1.2 veces la cantidad de ciclos de reloj que utilizaba la máquina A para este programa. Cuál sería la frecuencia de reloj de la máquina B?

5 Respuesta: El número de ciclos que utilizaría la máquina A para el programa X es: Tiempo de CPU A = Ciclos de Reloj de CPU A Frecuencia de Reloj A 10 segundos = Ciclos de Reloj de CPU A 400 x 10 6 ciclos/segundo Ciclos de Reloj de CPU A = 4000 x 10 6 ciclos Para la máquina B, utilizando la misma ecuación: Tiempo de CPU B = 1.2 x Ciclos de Reloj de CPU A Frecuencia de Reloj B 6 segundos = 1.2 x 4000x10 6 Ciclos Frecuencia de Reloj B De donde se obtiene: Frecuencia de Reloj B = 800 MHz, es decir, el doble de la Frecuencia de Reloj de la máquina A. El ejemplo anterior ilustra que al duplicar la frecuencia de reloj, por lo general, no reduce a la mitad el tiempo de ejecución, por que se afecta a otras etapas en el diseño del procesador, ocasionando que se requiera de una mayor cantidad de ciclos de reloj Ciclos por Instrucción (CPI) Además del número de ciclos de reloj para ejecutar un programa, también se puede contar el número de instrucciones ejecutadas - la longitud del camino de instrucciones o el recuento de instrucciones (IC, instruction count). Si se conoce el número de ciclos de reloj y el recuento de instrucciones, es posible calcular el número medio de ciclos de reloj por instrucción (CPI): Esta medida del rendimiento del CPU proporciona una nueva percepción en diferentes estilos de repertorios de instrucciones e implementaciones. Al transponer el IC en la

6 fórmula anterior, los ciclos de reloj pueden definirse como ICxCPI. Esto permite utilizar al CPI en la fórmula del tiempo de ejecución: O Tiempo de CPU = IC x CPI x Duración del ciclo de reloj IC x CPI Tiempo de CPU = Frecuencia de reloj Como demuestra esta fórmula, el rendimiento del CPU depende de tres características: ciclo de reloj (o frecuencia), ciclos de reloj por instrucción (CPI), y recuento de instrucciones (IC). No se puede cambiar ninguna de ellas sin tener en cuenta las demás, ya que las tecnologías básicas involucradas al cambiar una característica también son interdependientes: Frecuencia de reloj - Tecnología hardware y organización (Implementación); CPI - Organización y arquitectura a nivel lenguaje máquina; IC - Arquitectura al nivel lenguaje máquina y tecnología de compiladores. Ejemplo: Usando la ecuación del rendimiento. Suponga que se tienen dos implementaciones de la misma arquitectura. La máquina A tiene un tiempo de ciclo de 1 ns y un CPI de 2.0 para algún programa, y la máquina B tiene un tiempo de ciclo de 2 ns y un CPI de 1.2 para el mismo programa. Cuál máquina es más rápida para este programa y por cuanto? Respuesta: Puesto que ambas máquinas ejecutan la misma cantidad de instrucciones, sea I el recuento de Instrucciones. Por lo que se puede calcular el tiempo de CPU para cada máquina: Tiempo de CPU = IC x CPI x Duración del ciclo de reloj Tiempo de CPU A = I x 2.0 x 1 ns = 2 x I ns Tiempo de CPU B = I x 1.2 x 2 ns = 2.4 x I ns Puede verse que la máquina A es más rápida. La cantidad de rapidez se encuentra con la razón de tiempos de ejecución: RENDIMIENTO RENDIMIENTO A B TIEMPO _ DE _ EJECUCIÓN = TIEMPO _ DE _ EJECUCIÓN B A 2.4 I = 2 I = 1.2 Se concluye que la máquina A es 1.2 veces más rápida que la máquina B para este programa.

7 A veces es útil calcular el número total de ciclos de reloj de la CPU como: Ciclos de reloj de CPU = CPI i IC i Donde ICi representa el número de veces que se ejecuta alguna clase de instrucción i en un programa y CPI i representa el número medio de ciclos de reloj para la instrucción i. Esta forma puede utilizarse para expresar el tiempo de CPU como: n i= 1 n Tiempo de CPU = CPI i IC i i= 1 Duración del ciclo de reloj y el CPI global como: CPI = n i= 1 CPI i IC i Recuento de Instrucciones n = CPI i i= 1 ( IC i Recuento de instrucciones ) La última forma del cálculo de CPI multiplica cada CPI i individual por la fracción de ocurrencias en un programa. Para resultados mas reales, el CPIi debe medirse, y no obtenerse de la tabla del manual de referencia, ya que debe incluir fallos de caché y demás ineficiencias del sistema de memoria. Ejemplo: Comparando secuencias de código. Un diseñador de compiladores está tratando de decidir entre dos secuencias de código para una máquina particular. El diseñador de hardware le ha informado los siguientes hechos: La clase de Instrucción A requiere de un CPI de 1 La clase de Instrucción B requiere de un CPI de 2 La clase de Instrucción C requiere de un CPI de 3 Para una expresión de alto nivel, el escritor del compilador está considerando dos secuencias que requieren las siguientes instrucciones: Secuencia 1: 2 instrucciones de la Clase A, 1 de la clase B y 2 de la clase C. Secuencia 2: 4 instrucciones de la Clase A, 1 de la clase B y 1 de la clase C. Cuál secuencia ejecuta mas instrucciones? Cuál será más rápida? Cuál es el CPI para cada secuencia?

8 Respuesta: La secuencia 1 ejecuta = 5 instrucciones. La secuencia 2 ejecuta = 6 instrucciones. De manera que la secuencia 2 es la que ejecuta más instrucciones. La secuencia más rápida es la que requiere de una menor cantidad de ciclos de reloj, los ciclos de reloj son obtenidos con la expresión: Ciclos de reloj de CPU = CPI i IC i Ciclos de reloj de CPU 1 = (1 x 2) + (2 x 1) + (3 x 2) = 10 ciclos Ciclos de reloj de CPU 2 = (1 x 4) + (2 x 1) + (3 x 1) = 9 ciclos De manera que la secuencia 2 es más rápida. Finalmente, el CPI en cada caso se obtendrá dividiendo los ciclos requeridos por cada secuencia entre el número de instrucciones en cada secuencia: n i= 1 CPI 1 = 10/5 = 2 CPI 2 = 9/6 = MIPS y errores de utilización Hasta el momento se ha visto que la única medida fiable y consistente del rendimiento es el tiempo de ejecución de los programas reales, en esta sección se analizan otras alternativas al tiempo, propuestas como métricas para los programas reales, que presentándose como «items» medidos han conducido, eventualmente, a afirmaciones erróneas o incluso a errores en el diseño de las computadoras. Una de estas alternativas son los MIPS, o millones de instrucciones por segundo. Para un programa dado, los MIPS son sencillamente MIPS = Recuento de Instrucciones Tiempo de ejecución x 10 6 = Frecuencia de reloj CPI x 10 6 Algunos encuentran adecuada la fórmula de más a la derecha, ya que la frecuencia de reloj es fija para una máquina y el CPI, habitualmente, es un número pequeño, de forma distinta a la cuenta de instrucciones o al tiempo de ejecución. La relación de los MIPS con el tiempo es: Tiempo de ejecución = Recuento de instrucciones MIPS x 10 6

9 Como los MIPS son una frecuencia de operaciones por unidad de tiempo, el rendimiento puede especificarse como el inverso del tiempo de ejecución, de forma que máquinas más rápidas tendrán una mayor frecuencia de MIPS. La buena noticia sobre los MIPS es que son fáciles de comprender, especialmente por un cliente, y máquinas más rápidas significan un mayor número de MIPS, lo cual coincide con la intuición. El problema, cuando se utilizan los MIPS como medida para hacer comparaciones, es triple: Los MIPS son dependientes del repertorio de instrucciones, lo cual hace difícil la comparación de los MIPS de computadoras con diferentes repertorios de instrucciones; Los MIPS varían entre programas en la misma computadora; Los MIPS pueden variar inversamente al rendimiento. El ejemplo clásico, del último caso, es la variación de los MIPS en una máquina con hardware opcional de punto flotante. Como, generalmente, se emplean más ciclos de reloj por instrucción en punto flotante que por instrucción entera, los programas en punto flotante que utilizan el hardware opcional en lugar de las rutinas software de punto flotante emplean menos tiempo, pero tienen una menor frecuencia de MIPS. El software de punto flotante ejecuta instrucciones más simples, dando como resultado una mayor frecuencia de MIPS, pero se ejecuta tantas veces que el tiempo global de ejecución es mayor. Incluso es posible ver tales anomalías con compiladores optimizados. Ejemplo: Error en la aplicación de MIPS Para un programa X, un compilador generó la siguiente distribución de Instrucciones: Tipo de instrucción Frecuencia de una instrucción Ciclos de reloj por instrucción (CPI) Operaciones de ALU 43 % 1 Cargas 21 % 2 Almacenamientos 12 % 2 Saltos 24 % 2 Tabla 1.1 Distribución de Instrucciones para el programa X El compilador se optimiza de manera que para el mismo programa descarta el 50% de las instrucciones de la ALU aunque no pueda reducir cargas, almacenamientos, ni saltos. Ignorando las prestaciones del sistema y suponiendo una duración del ciclo de reloj de 2-ns (frecuencia de reloj 500-MHz) Cuál es la frecuencia en MIPS para el código optimizado frente al código sin optimizar? Están los resultados en MIPS de acuerdo con los del tiempo de ejecución?

10 Respuesta: Puesto que ya se conoce la frecuencia del reloj, para encontrar el valor de MIPS se requiere encontrar los CPIs del código sin optimizar y del código optimizado. Para ello es posible usar la expresión: CPI = n i= 1 CPI i IC i /Recuento de Instrucciones Aunque se desconoce el total de instrucciones, esto no importa por que este valor se eliminará. Por simplicidad, se asumirá que el programa sin optimizar está formado por 100 instrucciones, de manera que: entonces CPI sin optimizar = {(43x1) + (21x2) + (12x2) + (24x2)} / 100 = 1.57 MIPS sin optimizar = (500MHz)/(1.57x10 6 ) = Para el código optimizado: CPI optimizado = {((43/2)x1) + (21x2) + (12x2) + (24x2)} / (100-43/2) = 1.73 ya que la mitad de las instrucciones de la ALU están descartadas y el total de instrucciones se reduce por las instrucciones que faltan de la ALU. Entonces MIPS optimizado = 500MHz/(1.73x106) = Es evidente que el código optimizado requiere de un tiempo menor por que se ejecutan menos instrucciones (considerando al tiempo de ejecución, puede deducirse que el código optimizado es 1.5 veces más rápido que el código sin optimizar), sin embargo su frecuencia en MIPS es inferior: 289 contra Ejemplos como éste muestran que los MIPS pueden fallar al dar una visión verdadera del rendimiento, ya que no reflejan el tiempo de ejecución. Para compensar esta carencia, otra alternativa al tiempo de ejecución es utilizar una máquina particular, con una estimación convenida sobre los MIPS, como punto de referencia. Los MIPS Relativos para una máquina M se definen con base en una máquina de referencia como sigue: MIPS M = Tiempo referencia Tiempo M x MIPS referencia Donde:

11 Tiempo referencia - es el tiempo de ejecución de un programa en la máquina de referencia; Tiempo M - es el tiempo de ejecución del mismo programa en la máquina que se va a medir; MIPS referencia - es la estimación convenida sobre los MIPS de la máquina de referencia. En los años ochenta, la máquina de referencia dominante era la VAX-11/780, que se denominó máquina de 1-MIPS. Si una máquina era mas rápida que la máquina 1-MIPS en la ejecución una programa por 5 veces - esta máquina tenía 5 MIPS Relativos. La duda que surgió fue que si, en la máquina más antigua deberían ejecutarse las ediciones más modernas del compilador y sistema operativo, o si este software debe fijarse para que la máquina de referencia no sea más rápida a lo largo del tiempo. Existe también la tentación de generalizar de una estimación de los MIPS relativos utilizando un «benchmark» a tiempo de ejecución relativo (un «benchmark» es un programa de evaluación desarrollado para la comparación del rendimiento de computadoras, en relación con el tiempo que se requiere para su ejecución), aún cuando pueda haber amplias variaciones en el rendimiento relativo MFLOPS y errores de utilización Otra alternativa popular al tiempo de ejecución son los millones de operaciones en punto flotante por segundo, abreviadamente megaflops o MFLOPS, pero siempre pronunciado «megaflops». La fórmula de los MFLOPS es simplemente la definición del acrónimo: MFLOPS = Número de operaciones de punto flotante de un programa Tiempo de ejecución x 10 6 Evidentemente, una estimación en MFLOPS depende de la máquina y del programa. Como los MFLOPS se pensaron para medir el rendimiento en punto flotante, no son aplicables fuera de ese rango. Como ejemplo extremo, los compiladores, tienen una estimación de MFLOPS próxima a cero sin que importe lo rápida que sea la máquina, ya que raramente utilizan aritmética en punto flotante. El término MFLOPS está basado en las operaciones en lugar de las instrucciones, y se pensó para que fuera una comparación buena entre diferentes máquinas. La creencia es que el mismo programa corriendo en computadoras diferentes debe ejecutar un número diferente de instrucciones, pero el mismo número de operaciones en punto flotante. Desgraciadamente, los MFLOPS no son fiables, porque el conjunto de operaciones en punto flotante no es consistente con las máquinas. Por ejemplo, el CRAY C90 no tiene instrucción de dividir, mientras que Pentium de Intel tiene división, raíz cuadrada, seno y coseno. Otro problema observado es que la estimación en MFLOPS cambia no sólo en la mezcla de operaciones de enteros y punto flotante sino también en la mezcla de operaciones rápidas y lentas de punto flotante. Por ejemplo, un programa con el 100% de sumas en punto flotante tendrá una estimación mayor que un programa con el 100% de divisiones en punto flotante.

12 Además, como cualquier otra medida de rendimiento, la estimación en MFLOPS para un único programa no puede generalizarse para establecer una métrica única de rendimiento para una computadora. Como los MFLOPS normalizados representan realmente una constante dividida por el tiempo de ejecución para un programa específico y entrada específica, los MFLOPS son redundantes con el tiempo de ejecución, la principal medida de rendimiento. De manera distinta al tiempo de ejecución, es tentador caracterizar una máquina con una única estimación en MIPS o MFLOPS sin nombrar un programa, sin especificación la entrada/salida, sin descripción las versiones de los sistemas operativos y compiladores. Finalmente, los MFLOPS no son una medida útil para todos los programas. 1.6 Otros tópicos relacionados con el rendimiento Programas para evaluar el rendimiento Un usuario de computadoras que ejecuta los mismos programas día tras día sería el candidato perfecto para evaluar una nueva computadora. Para evaluar un nuevo sistema simplemente compararía el tiempo de ejecución de su carga de trabajo habitual (workload) - la mezcla de programas y órdenes del sistema operativo que los usuarios ejecutan en una máquina. Sin embargo, pocas veces ocurre esta feliz situación. La mayoría de veces se debe confiar en otros métodos para evaluar las máquinas, y con frecuencia, en otros evaluadores, esperando que estos métodos predigan el rendimiento de la nueva máquina. Hay cuatro niveles de programas utilizados en estas circunstancias, listados a continuación en orden decreciente de precisión. 1. Programas reales (Real programs). - Aunque el comprador puede no conocer qué fracción de tiempo se emplea en estos programas, sabe que algunos usuarios los ejecutarán para resolver problemas reales. Ejemplos son compiladores de C, software de tratamiento de textos como TeX, y herramientas CAD como Spice. Los programas reales tienen entradas, salidas y opciones que un usuario puede seleccionar cuando está ejecutando el programa. 2. «Núcleos» (Kernels). - Se han hecho algunos intentos para extraer pequeñas piezas claves de programas reales y utilizarlas para evaluar el rendimiento. «Livermore Loops» y «Linpack» 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 «núcleos» son adecuados para aislar el rendimiento de las características individuales de una máquina para explicar las razones de las diferencias en los rendimientos de programas reales. 3. Benchmarks reducidos (Toy benchmarks). - 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 Criba de Eratóstenes, Puzzles, y Ordenamiento Rápido (Quicksort) son populares porque son pequeños, fáciles de introducir y de ejecutar casi en cualquier computadora.

13 4. Benchmarks Sintéticos.- Análogos en filosofía a los «núcleos», los «benchmarks sintéticos» 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 «núeleos», ningún usuario ejecuta los benchmarks sintéticos porque no calculan nada que ningún usuario pueda utilizar. Los benchmarks sintéticos están, en efecto, aún más lejos de la realidad porque el código de los «núcleos» se extrae de programas reales, mientras que el código sintético se crea artificialmente para determinar un perfil medio de ejecución. Los benchmarks sintéticos no son parte de programas reales, mientras que los demás pueden serlo Conjuntos de benchmarks Recientemente ha llegado a ser popular juntar una colección de benchmarks para intentar comparar el rendimiento de computadoras con una variedad de aplicaciones. Por supuesto, tales conjuntos son tan buenos como los benchmarks individuales que los constituyen. No obstante, una ventaja dominante de tales conjuntos es que la debilidad de algún programa de prueba es disminuida por la presencia de otros benchmarks. El conjunto más popular y comprensivo de los benchmarks es la colección de SPEC (System Performance Evaluation Cooperative). La SPEC fue creada por un grupo de compañías de computadoras en 1989 para definir, crear y mantener un conjunto de programas que permitan evaluar el rendimiento de las computadoras modernas. En lo que refiere a CPUs, la colección más nueva de SPEC se denomina CPU2006. Es una colección diseñada para proporcionar medidas del rendimiento que puedan ser usadas para comparar cargas de trabajo de cómputo intensivo en diferentes sistemas de cómputo. SPEC CPU2006 contiene dos suites de benchmarks: CINT2006 para medir y comparar el rendimiento de cómputo intensivo con enteros, y CFP2006 para medir y comparar el rendimiento de cómputo intensivo con números en punto flotante. Existe otra colección denominada SPEC CPU2002, y aunque actualmente aún se dispone de los benchmarks con sus correspondientes resultados, SPEC plantea retirarla en el Colecciones que han sido retiradas son CPU95 y CPU92. Además de la evaluación del rendimiento de la CPU, SPEC organiza otras colecciones de benchmarks en función de las aplicaciones que se vayan a ejecutar en alguna máquina particular, así se tienen colecciones para: Aplicaciones con gráficos Cómputo de alto rendimiento Clientes/Servidor en Java Servidores de Correo Electrónico Sistemas de archivos en red Rendimiento en la potencia

14 Servidores WEB Mas información de la organización SPEC se encuentra en: Principio cuantitativo para aumentar el rendimiento: Acelerar el caso común Quizá el principio más importante y generalizado del diseño de computadoras sea acelerar el caso común: al realizar un diseño, favorecer el caso frecuente sobre el infrecuente. Este principio también se aplica cuando se determina cómo emplear recursos, ya que el impacto de hacer alguna ocurrencia más rápida es mucho mayor si la ocurrencia es frecuente. Mejorar el evento frecuente en lugar del evento raro, evidentemente, también ayudará a aumentar el rendimiento. Además, el caso frecuente es, a menudo, más simple y puede realizarse de forma más rápida que el caso infrecuente. Por ejemplo, cuando se suman dos números en la CPU, es natural esperar que el desbordamiento sea una circunstancia infrecuente y, por tanto, es factible mejorar el rendimiento optimizando el caso más común de ausencia de desbordamiento. Este hecho puede alentar la situación en la que se presente un desbordamiento, pero si este caso es infrecuente, el rendimiento global mejorará al optimizar el caso normal. Al aplicar este sencillo principio, se deberá evaluar que casos son frecuentes y cómo se puede mejorar el rendimiento haciéndolos más rápidos. Una ley fundamental, denominada Ley de Amdahl, puede utilizarse para cuantificar este principio Ley de Amdahl El aumento de rendimiento que puede obtenerse al mejorar alguna parte de una computadora puede calcularse utilizando la Ley de Amdahl. La Ley de Amdahl establece que 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. La Ley de Amdahl define la ganancia de rendimiento o aceleración (speedup) que puede lograrse al utilizar una característica particular. Si para una máquina es posible realizar una mejora que, cuando se utilice, aumente su rendimiento. La aceleración está dada por la relación: Aceleración de rendimiento = Rendimiento de la tarea completa utilizando la mejora cuando sea posible Rendimiento de la tarea completa sin utilizar la mejora

15 Alternativamente: Aceleración de rendimiento = Tiempo de ejecución de la tarea sin utilizar la mejora Tiempo de ejecución de la tarea completa utilizando la mejora cuando sea posible La aceleración indica la rapidez con que se realizará una tarea utilizando una máquina con la mejora con respecto a la máquina original. La Ley de Amdahl da una forma rápida de calcular la aceleración, que depende de dos factores: La fracción del tiempo que pueda utilizarse para aprovechar la mejora. Por el ejemplo, si en un programa que tarda 60 segundos, durante 20 segundos puede utilizarse la mejora, la fracción será 20 /60. Este valor, que se llama Fracción mejorada, es siempre menor o igual que 1. La optimización lograda por el modo de ejecución mejorado; es decir, cuánto más rápido se ejecutaría la tarea si solamente se utilizase el modo mejorado. Este valor es el tiempo del modo original con respecto al tiempo del modo mejorado. Si el modo mejorado toma 2 segundos para alguna porción de programa que puede usar el modo completamente mientras que el modo original tomaba 5 segundos para la misma porción de programa, la mejora es 5/2. Este valor es siempre mayor que 1 y se llama Aceleración mejorada. El tiempo de ejecución utilizando la máquina original con el modo mejorado será el tiempo empleado utilizando la parte no mejorada de la máquina más el tiempo empleado utilizando la parte mejorada. Tiempo de ejecución nuevo = Tiempo de ejecución antiguo x ( 1 Fracción ) mejorada + Fracción Aceleración mejorada mejorada La aceleración global es la relación de los tiempos de ejecución: Tiempo de ejecución antiguo 1 Aceleración global = Tiempo de ejecución nuevo = ( 1 Fracción ) mejorada + Fracción Aceleración mejorada mejorada

16 Ejemplo: Aplicación de la Ley de Amdahl Se tiene una máquina en la cual se hicieron arreglos en hardware para alcanzar una mejora que se ejecuta diez veces más rápida que la máquina original, pero sólo es utilizable el 40% del tiempo. Cuál es la aceleración global lograda al incorporar la mejora? Respuesta Fracción mejorada = 0.4 Aceleración mejorada = 10 Aceleración global = 1/( /10) = Un corolario importante de la Ley de Amdahl es que si una mejora sólo es utilizable por una fracción de una tarea, no es posible aumentar la velocidad de la tarea más que el recíproco de 1 menos esa fracción. Un error común al aplicar la Ley de Amdahl es confundir la «fracción de tiempo para utilizar una mejora» con la «fracción de tiempo después de que se utiliza la mejora». Si, en lugar de medir el tiempo que podría utilizar la mejora en un cálculo, midiésemos el tiempo después que se ha utilizado la mejora, los resultados serían incorrectos. La Ley de Amdahl puede servir como guía para ver cómo una mejora aumenta el rendimiento y cómo distribuir los recursos para mejorar la relación costo/rendimiento. El objetivo, claramente, es emplear recursos de forma proporcional al tiempo que se requiere en cada parte.

17 TAREA 2 1. Se plantea comparar dos sistemas diferentes: S1 y S2. El sistema S1 cuesta 10, 000 dólares y el sistema S2 15, 000. Se han realizado las siguientes medidas sobre estos sistemas: Programa Tiempo en S1 Tiempo en S segundos 5 segundos 2 3 segundos 4 segundos Se dice que una máquina es más efectiva en coste que otra si la razón de rendimiento dividida por el coste es mayor. a. Un usuario sólo se interesa por el rendimiento del programa 1. Qué máquina es más efectiva en coste para correr sólo el programa 1? En cuánto? b. Otro usuario está preocupado por la productividad de los sistemas, cuando se midieron con una carga de trabajo igual de los programas 1 y 2. Qué sistema tiene mejor rendimiento para esa carga de trabajo? En cuánto? Qué sistema es más efectivo en coste para esa carga de trabajo? En cuánto? c. Sin embargo, otro usuario tiene los siguientes requerimientos para los sistemas: el programa 1 debe ejecutarse 200 veces cada hora. El tiempo restante puede utilizarse para correr el programa 2. Si el sistema tiene suficientes prestaciones para correr el programa 1 el número de veces requerido por hora, el rendimiento se mide por la productividad del programa 2. Qué sistema es más rápido para esta carga de trabajo? Qué sistema es más efectivo en coste? d. Considere que en los dos sistemas y programas se hicieron las siguientes medidas adicionales: Programa Instrucciones ejecutadas en S1 Instrucciones ejecutadas en S x x 10 6 Calcule la velocidad de ejecución de las instrucciones (instrucciones por segundo) para cada máquina cuando corre el programa 1. e. Si la frecuencia de reloj del sistema S1 es 20 MHz y la del reloj del sistema S2 es 30 MHz, encuentre los ciclos de reloj por instrucción (CPI) para el programa 1 en ambos sistemas, utilizando los datos de las dos tablas. f. Suponiendo que el CPI para el programa 2 en cada máquina es igual al CPI del programa 1 (calculado en el inciso e), encontrar el recuento de instrucciones para correr el programa 2 en cada máquina (utilice los tiempos de la tabla 1).

18 2. Suppose that when Program A is running, the user CPU time is 3 seconds, the elapsed wallclock time is 4 seconds, and the system performance is 10 MFLOP/sec. Assume that there are no other processes taking any significant amount of time, and the computer is either doing calculations in the CPU or doing I/O, but it can't do both at the same time. We now replace the processor with one that runs six times faster, but doesn't affect the I/O speed. What will the user CPU time, the wallclock time, and the MFLOP/sec performance be now? 3. You are on the design team for a new processor. The clock of the processor runs at 200 MHz. The following table gives instruction frequencies for Benchmark B, as well as how many cycles the instructions take, for the different classes of instructions. For this problem, we assume that (unlike many of today's computers) the processor only executes one instruction at a time. Instruction type Frequency Cycles Loads & Stores 30% 6 cycles Arithmetic instructions 50% 4 cycles All others 20% 3 cycles a. Calculate the CPI for Benchmark B. b. The CPU execution time on the benchmark is exactly 11 seconds. What is the native MIPS processor speed for the benchmark in millions of instructions per second? c. The hardware expert says that if you double the number of registers, the cycle time must be increased by 20%. What would the new clock speed be (in MHz)? d. The compiler expert says that if you double the number of registers, then the compiler will generate code that requires only half the number of Loads & Stores. What would the new CPI be on the benchmark? e. How many CPU seconds will the benchmark take if we double the number of registers (taking into account both changes described above)?