3.1 Qué hace un compilador - historia de los compiladores

Si usted ha formado parte del mundo del cómputo de alto rendimiento desde sus inicios en la década de 1950, le ha tocado programar en varios lenguajes desde entonces. Durante la década de 1950 e inicios de la de 1960, lo hizo en lenguaje ensamblador. La escasez de memoria y las bajas velocidades de reloj hacían que cada instrucción fuera preciosa. Con pequeñas memorias, el tamaño de los programas era típicamente pequeño, así que con el lenguaje ensamblador era suficiente. Para finales de la década de 1960, los programadores comenzaron a escribir más código en un lenguaje de alto nivel como FORTRAN. Usar uno de tales lenguajes hace que el trabajo que usted realice sea más transportable, confiable y fácil de mantener. Dado el incremento en velocidad y capacidad de las computadoras, el costo de usar un lenguaje de alto nivel fue algo que la mayoría de los programadores estaban dispuestos a aceptar. En la década de 1970, si un programa gastaba una cantidad particularmente grande de tiempo en cierta rutina, o la rutina formaba parte del sistema operativo, o se trataba de una biblioteca de uso común, muy probablemente estuviera escrita en ensamblador.

Durante la última parte de la década de 1970 e inicios de la de 1980, los compiladores optimizadores continuaron mejorando hasta el punto en que el grueso de los programas de propósito general, excepto las porciones más críticas, se escribían en lenguajes de alto nivel. En promedio, los compiladores generan mejor código que la mayoría de los programadores humanos de ensamblador. A menudo ello se debe a que el compilador puede hacer un mejor uso de algunos recursos de hardware, tales como los registros. En un procesador con 16 registros, un programador debe adoptar alguna convención respecto a qué registros usar para cada cosa, con el fin de poder seguirle la pista al valor que cada uno almacena. Un compilador puede usar cada registro como le plazca, porque puede darle un seguimiento preciso al momento en que está disponible para otro uso.

Sin embargo, durante ese periodo, también evolucionó la arquitectura de las computadoras de alto rendimiento. Cray Research estaba desarrollando procesadores vectoriales en el extremo superior del espectro computacional. Los compiladores todavía no estaban listos para determinar cuándo debían emplear esas nuevas instrucciones vectoriales. Los programadores se vieron forzados a escribir lenguaje ensamblador o crear código FORTRAN muy afinado que invocaba a las rutinas vectoriales apropiadas en su código. En cierto sentido, los procesadores vectoriales hicieron girar las manecillas del reloj en el sentido inverso, hasta que comenzaron a confiar en el compilador. Los programadores nunca regresaron completamente al lenguaje ensamblador, pero su código FORTRAN comenzaba a lucir más como no-FORTRAN. Conforme maduraron las computadoras vectoriales, sus compiladores fueron progresivamente capaces de detectar cuándo podía realizarse la vectorización. Y en algún momento nuevamente se hicieron mejores que los programadores humanos en tales arquitecturas. Los nuevos compiladores reducían la necesidad de usar intensivamente directivas o extensiones del lenguaje. Los Ciclos de Livermore eran una prueba comparativa que específicamente comprobaba la capacidad del compilador para optimizar eficientemente un conjunto de ciclos. Además de ser una prueba comparativa de rendimiento, también comparaba los compiladores.

La revolución RISC descansaba en una dependencia creciente respecto al compilador. Programar en los primeros procesadores RISC, tales como el Intel i860 resultaba doloroso si se comparaba con los procesadores CISC. Sutiles diferencias en la forma de codificar un programa en lenguaje máquina podían tener un impacto significativo en el rendimiento global del programa. Por ejemplo, un programador debía contar los ciclos transcurridos entre una instrucción de carga y el uso de los resultados de la carga en una instrucción posterior de cálculo. Conforme se desarrollaron procesadores superescalares, se hizo necesario volver simultáneas ciertos pares de instrucciones, y otras debían acomodarse secuencialmente. Dado que había en el mercado un gran número de procesadores RISC distintos, los programadores no tenían tiempo de aprender tales particularidades para lograr hasta la última gota de rendimiento en cada procesador. Era más fácil mantener unidos al diseñador del procesador y el escritor del compilador (que con suerte trabajaban para la misma compañía) y hacer que discutieran a fondo la mejor forma de generar el código máquina. Y entonces cualquiera podía usar el compilador y obtener código que hiciera un uso razonablemente bueno del hardware.

El compilador se convirtió en una herramienta importante en el ciclo de diseño del procesador. Los diseñadores de procesadores tenían mucha mayor flexibilidad respecto a los tipos de cambios que podían hacer. Por ejemplo, podía suceder que un buen diseño en la siguiente revisión de un procesador ejecutase código previo 10% más lento que una revisión nueva, pero recompilando el código lo hiciera 65% más rápido. Por supuesto, era importante proporcionar dicho compilador con cada nuevo embarque de procesadores, y que dicho compilador diera ese nivel de rendimiento en una amplia variedad de código, y no sólo en una suite de pruebas de escritorio en particular.