ES2326126T3 - Sistema de generacion automatica de codigos optimizados. - Google Patents

Abstract

Sistema de generación automática de códigos optimizados (19) operativos sobre una plataforma material previamente definida (90) que comprende por lo menos un procesador (91), para un campo de aplicación predeterminado a partir de códigos fuentes (17) solicitados por unos usuarios, caracterizado porque comprende unos medios (51, 52) de recepción de secuencias de códigos simbólicos denominadas secuencias-patrones (1) representativas del comportamiento de dicho procesador (91) en términos de prestaciones, para el campo de aplicación predeterminado; unos medios (53) de recepción de parámetros estáticos (2) definidos a partir de la plataforma material previamente definida (90), de su procesador (91) y de las secuencias-patrones (1); unos medios (55) de recepción de parámetros dinámicos (7) también definidos a partir de la plataforma material previamente definida (90), de su procesador (91) y de las secuencias-patrones (1); un dispositivo de análisis (10) para establecer unas reglas de optimización (9) a partir de ensayos y de mediciones de características establecidos a partir de las secuencias-patrones (1), de los parámetros estáticos (2) y de los parámetros dinámicos (7); un dispositivo (80) de optimización y de generación de código que recibe por una parte las secuencias-patrones (1) y por otra parte las reglas de optimización (9) para examinar los códigos fuentes (17) de usuarios, detectar unos bucles optimizables, descomponer en núcleos, ensamblar e inyectar unos códigos para suministrar uno códigos optimizados (19); y unos medios (74) para reinyectar en las secuencias-patrones (1) unas informaciones procedentes del dispositivo (80) de generación y optimización de códigos y relativas a unos núcleos.

Description

Sistema de generación automática de códigos optimizados.

La presente invención tiene por objeto un sistema de generación automática de códigos optimizados operativos sobre una plataforma material previamente definida que comprende por lo menos un procesador, para un campo de aplicación predeterminado, a partir de códigos fuentes solicitados por unos usuarios (estando estos usuarios en este caso comprendidos en el amplio sentido y que incluyen unos usuarios finales, pero también unos programadores de aplicaciones o unos programadores de sistema).

Desde el origen de la informática, se han realizado numerosos trabajos referentes a los compiladores.

El principio de un compilador es analizar un código fuente descrito en un lenguaje de alto nivel y después generar su equivalente en código binario para la máquina diana. En general este proceso es efectuado estáticamente antes de la ejecución. Existen también unos interpretadores que utilizan unas tecnologías de compilación dinámica que han permitido eliminar esta última obligación ofreciendo la posibilidad de generar el código en el último momento cuando tiene lugar la ejecución.

El compilador es un elemento de la cadena de preparación de los programas. El resultado de la compilación puede ser completado por unos procedimientos ya compilados y generados (compilación separada o bibliotecas), ligados estáticamente a la carga o dinámicamente a la ejecución.

Los compiladores están en general organizados en tres fases:

1.

Generación de código intermedio: a partir del código fuente, el compilador reconoce los idiomas y genera una forma abstracta independiente del lenguaje fuente, comúnmente denominada lenguaje intermedio. Este lenguaje es independiente de la máquina diana.

2.

Optimización de alto nivel: en esta fase son agrupadas un cierto número de optimizaciones que son en general independientes de la arquitectura diana: propagación de constantes, reducción de fuerza, expresiones comunes.... Estas optimizaciones corresponden en general a unas métricas simples: disminución el número de instrucciones, simplificación de la estructura del código.

3.

Generación de código y optimización de bajo nivel; en esta fase se realizan todas la operaciones y optimizaciones propias de la máquina diana: generación y selección de las instrucciones, asignación de registros, ordenamiento de las instrucciones, etc...

\vskip1.000000\baselineskip

Las cualidades de un compilador están no solamente ligadas a la arquitectura diana (característica del código generado) sino también al lenguaje fuente (más o menos fácil de compilar) y a sus características como lógica (robustez, riqueza de las opciones, velocidad de ejecución, etc...).

Salvo el caso particular de la compilación dinámica, el conjunto de las tres fases anteriores deben ser realizadas antes de la ejecución y esto en un tiempo razonable, lo que limita por tanto la complejidad de los algoritmos de optimización que pueden ser implementados en un compilador.

Una gran parte de la búsqueda en los compiladores está por tanto en primer lugar ligada a la elección y a la definición del lenguaje fuente de alto nivel.

Las evoluciones de los compiladores están también ligadas a las evoluciones de la arquitectura de los procesadores y más precisamente a los modelos de característica que describen el comportamiento de estas arquitecturas. Como en cualquier problema de optimización, una dificultad importante es la definición de una función coste que sea representativa del tiempo de ejecución.

Los primeros juegos de instrucciones tenían unos comportamientos muy simples: el tempo de ejecución de una secuencia de instrucciones se obtenía muy simplemente como la suma de los tiempos de ejecución de cada una de las instrucciones de la secuencia. En consecuencia, el proceso de optimización era muy simple y la principal estrategia de optimización consistía en reducir el número y la complejidad de las instrucciones generadas.

La aparición de los primeros juegos de instrucciones CISC ("Complex Instruction Set Computer") ha modificado ligeramente el dato en la medida en que unas instrucciones muy complejas resultaban disponibles. El problema de optimización resultaba entonces esencialmente un problema de reconocimiento de idiomas ("pattern matching"). En esta misma categoría se pueden incluir los juegos de instrucciones vectoriales y los vectorizadores que eran capaces de reconocer los bucles que se prestaban directamente a una generación de código vectorial. Si era necesario el código fuente podía también ser transformado para hacer aparecer unas estructuras de código vectorial.

Una ruptura en las estrategias de optimización ha llegado con la introducción de los pipelines, evolución arquitectónica que recorta el tratamiento de las instrucciones en varias operaciones ejecutadas secuencialmente, a imagen de una cadena de montaje en una fábrica. Esta técnica que permite superponer la ejecución de varias instrucciones en un instante dado mejora sustancialmente las características de los sistemas, pero introduce unas desviaciones importantes en caso de "ruptura de pipeline", a consecuencia por ejemplo de la presencia de instrucción de conexión. La misma ha puesto fin así a la predictibilidad del comportamiento de un código dado. Otra ruptura importante proviene de la utilización de las jerarquías de memorias: la optimización debía entonces apoyarse en la evaluación fina de una métrica muy particular: la localidad (espacial y temporal). Sin embargo siendo simple la interacción entre el procesador y el sistema de memoria, el proceso de optimización debía tener como principal objetivo minimizar el número de "miss" (fracasos) puesto que cada fracaso añadía una penalidad al tiempo de ejecución. Debe observare sin embargo que la minimización del número de "miss" era delicado y esencialmente realizable para algunas estructuras de código simple de tipo bucle. Esta dificultad de estimación de forma estática de las propiedades de localidad conducía a utilizar unos procedimientos de optimización por gestión de los perfiles: el código era ejecutado una primera vez para determinar precisamente las propiedades de localidad (construcción de un perfil). Este perfil era entonces utilizado en una segunda pasada para efectuar las optimizaciones ligadas a la explotación de la localidad. A este nivel de complejidad arquitectónica, era ya muy difícil definir de forma simple una estrategia eficaz de optimización. Más exactamente, era extremadamente delicado saber combinar diferentes optimizaciones y esto mismo en unos casos muy simples: no existía mecanismo que permitiera modelizar/tener en cuenta de forma eficaz las características. En este marco han sido desarrolladas las técnicas de compilación iterativa que combinan ejecución y optimización de forma que generen el mejor código posible. Más precisamente, la compilación iterativa consiste en la utilización de un bucle de "transformación de código-medida de característica (estática o dinámica)." Se trata esencialmente de técnicas que permiten explorar el espacio de las transformaciones de código a menor coste para conservar sólo las soluciones que hayan dado las mejores soluciones. El coste tan elevado en tiempo de cálculo y de puesta a punto de estos procedimientos iterativos ha limitado su campo de aplicación a la optimización de bibliotecas.

Las arquitecturas RISC ("Reduced Instruction Set Computer") que utilizaban un juego de instrucciones simple y uniforme (en oposición al CISC) han visto la luz hacia la mitad de los años 80. Las primeras generaciones de procesadores RISC estaban muy limitadas en términos de funcionalidad y la calidad del código generado (en particular el ordenamiento de las instrucciones) resultaba entonces un factor clave en la carrera para la eficiencia. De manera muy similar, las arquitecturas VLIW ("Very Long Instruction Word") utilizaban unas técnicas de compilación totalmente semejantes para explotar mejor el material. Estas dos arquitecturas RISC y VLIW tenían siempre un modelo de característica siempre determinista en la medida en que globalmente las instrucciones se ejecutaban en el mismo orden que el código del programa generado, lo que simplificaba considerablemente el comportamiento de estas arquitecturas y por ello el proceso de optimización. Sin embargo, muy rápidamente, estas arquitecturas han generalizado la utilización del pipeline y de las cache de memoria para obtener mejores rendimientos (más precisamente, esto ha conducido a una mejora de las características como media y en detrimento de la predictibilidad).

La aparición de las arquitecturas superescalares (capaces de ejecutar varias instrucciones por ciclo) y sobre todo los mecanismos de tratamiento en el desorden ("Out of Order Processing") de las instrucciones han hecho aún más difíciles los procesos de optimización de las características. Además, simultáneamente las jerarquías de memorias han evolucionado rápidamente: el número de niveles ha aumentado y sobre todo diversos mecanismos que permiten administrar de forma más o menos explícita las diferentes cache (Precarga, gestión de prioridad,..) han hecho su aparición. El conjunto de estos mecanismos ha hecho el comportamiento de fracciones de código incluso muy simples (bucle con acceso a 2 ó 3 tablas) extremadamente difícil y por ello imposible de optimizar apoyándose sobre unos modelos simples de característica. Esta situación no ha hecho más que empeorar con la diferencia creciente entre las características de los procesadores y de las de las memorias.

Globalmente, en el curso de los dos últimos decenios, a nivel de la arquitectura de los procesadores, la riqueza en términos de funcionalidades se ha incrementado considerablemente. Así, el número de registros ha aumentado considerablemente: de 8 registros en estándar en las arquitecturas CISC, se ha pasado a 32 registros en las arquitecturas RISC e incluso a más de 80 registros en las arquitecturas superescalares. En la primera aproximación se puede pensar que aumentar el número de registros simplificará la optimización. En la práctica, la evolución de las memorias ha hecho la utilización de los registros aún más crucial y sobre este problema de asignación de registro, el coste de los algoritmos eficaces de asignación de registro ha aumentado considerablemente puesto que su complejidad es exponencial en función del número de registros disponibles.

En respuesta a estas evoluciones recientes, la tecnología de los compiladores ha evolucionado poco: el número de optimizaciones utilizadas evidentemente ha aumentado pero la capacidad para definir una estrategia global de optimización no ha progresado e incluso ha disminuido.

Por último, una última tendencia ha aparecido con la compilación "dinámica". El principio es simple y atrayente: la compilación dinámica (o también especialización para la ejecución) consiste en efectuar unas optimizaciones de código en el último momento, es decir en la ejecución. Una secuencia de código es adaptada ("especializada") en función de los datos de entrada (contexto de ejecución) de un programa. Un mecanismo para la ejecución "examina" el comportamiento de los programas según la frecuencia de ejecución de las secuencias de instrucciones y decide o no utilizar unas versiones optimizadas para un contexto de ejecución preciso. Este tipo de mecanismo intrínsecamente dinámico está limitado a unas técnicas de optimización poco costosas en tiempo de cálculo para su utilización puesto que no deben penalizar la ejecución de los códigos.

\newpage

Se recuerda por otra parte que una biblioteca es un conjunto de procedimientos, representativo de un campo o de una porción de este campo: los componentes de una biblioteca deben de hecho corresponder a unos procedimientos estándar frecuentemente utilizados. El concepto de biblioteca es muy antiguo, anterior a la noción de compiladores y es uno de los grandes pilares de la ingeniería lógica (reutilización de componentes). En particular, Java es uno de los ejemplos de lenguajes que utilizan muy sistemáticamente la noción de biblioteca.

Las bibliotecas pueden corresponder a diferentes niveles de abstracción del más simple al más complicado: BLAS 1 ("Basic Linear Algebra Subroutines Level I") 29 es un conjunto de operaciones muy simples que conducen a unos vectores pero que permiten expresar un gran número de algoritmos clásicos de álgebra lineal. En otro extremo, LINPACK (resp. EISPACK) es un conjunto completo de procedimientos que permiten la resolución de sistemas lineales (resp. el cálculo de vectores propios y de valores propios). Un gran número de bibliotecas han sido desarrolladas y ampliamente utilizadas en los campos particulares siguientes:

\bullet

Cálculo científico: BLAS1, BLAS2, BLAS3, BLAST, SPARSE BLAS, LINPACK, LAPACK, BLACS, PVM, MPI, etc

\bullet

Tratamiento de señal: FFTPACK, VSIPI, etc

\bullet

Gráfico: DirectX, OpenGL.

\vskip1.000000\baselineskip

El hecho de que, en un campo de aplicaciones dado, un cierto número de bibliotecas hayan sido definidas e identificadas traduce el hecho de que este campo pueda ser "sintetizado".

El mayor defecto de las bibliotecas es sin embargo que su funcionalidad está muy limitada y que inducen una utilización manual (es decir necesitan la inserción en el código fuente de una llamada explícita de procedimiento).

Las primeras generaciones de bibliotecas (que corresponden a unos procedimientos simples y de pequeño tamaño) han sido en general desarrolladas a mano en ensamblador. Esto ha sido muy a menudo el caso desde de que la característica es el criterio principal (bajo reserva evidentemente de que los procedimientos permanezcan de un tamaño razonable).

Por el contrario, a diferencia de la compilación que es globalmente un proceso "en línea" (los tiempos de compilación deben permanecer moderados), la optimización de bibliotecas es esencialmente un proceso" fuera de conexión" y puede utilizar unos procedimientos mucho más golosos en tiempo de cálculo. Así, la compilación iterativa es una excelente herramienta de optimización para el desarrollo de bibliotecas pero que solo puede ser utilizado desgraciadamente para unos códigos simples visto su peso de utilización.

En el mismo orden de ideas, la tecnología del tipo "Automatic Tuning Liner Algebra Software" permite realizar una parte de la optimización (elección de los buenos parámetros tales como los tamaños de los bloques). Desgraciadamente esta técnica es de utilización muy restringida puesto que es muy dependiente del tipo de aplicación considerado (cálculo sobre unas matrices densas, cálculos caracterizados por una gran localidad temporal). Otra técnica de generación y de optimización de código se presenta en el documento Generating Code for High-Level Operations through Code Composition por James M. Stichnoth (Agosto 1997, CMU-CS-97-165); esta técnica utiliza unas porciones previamente definidas de código (code templates) que contienen código diana y unos mandos de compilación que especifican cómo deben componerse estas porciones de código.

Las herramientas de análisis de característica existentes son muy variadas (en particular en función del objetivo buscado):

\bullet

Ensayos de características ("benchmarks"): son unos códigos más o menos representativos de un campo de aplicación y que permiten comparar las características de diversas máquinas,

\bullet

Simuladores: permiten comprender el comportamiento de una arquitectura al nivel más fino. Desgraciadamente son muy costosos, delicados de desarrollar, muy lentos y no necesariamente fieles con respecto al procesador diana.

\bullet

Modelos matemáticos: se trata de poner en ecuación la característica de la máquina. En general su utilización es extremadamente limitada y sólo son útiles para estudiar diferentes variantes simples alrededor de un mismo código muy simple.

\bullet

Herramientas de control/gestión de perfiles: estas herramientas permiten recuperar (por medio de los contadores de material esecializados) diferentes informaciones relativas a la ejecución de un programa: número de ciclos, número de miss, etc....

\newpage

Se pueden por otra parte formular las observaciones siguientes:

-

Los ensayos de característica evolucionan poco y sobre todo han resultado el objeto de envites comerciales demasiado importantes. Muy a menudo, su optimización encarnizada por los constructores falsea el alcance y la validez de los resultados obtenidos.

-

Simuladores: la explotación de sus resultados (para la optimización de código) resulta cada vez más difícil en la medida en que la arquitectura apuntada se vuelve muy compleja.

-

Modelos matemáticos: evolucionan poco y fuera del uso local mencionado anteriormente, son inutilizables. Una de las razones es que las buenas de herramientas matemáticas de modelización presuponen un comportamiento "uniformemente promediado, lo que está lejos de ser el caso en la práctica".

-

Herramientas de control/gestión de los perfiles: sufren esencialmente tres defectos: dan una información global y no una distribución de la actividad en el curso del tiempo; no permiten correlacionar código y comportamiento a nivel fino; por último, su explotación (como en el caso del simulador) es muy delicada, en razón en particular de la complejidad de la arquitectura apuntada.

\vskip1.000000\baselineskip

La presente invención prevé evitar los inconvenientes citados y permitir, para una plataforma material previamente definida que comprende por lo menos un procesador, generar de forma automática unos códigos optimizados operativos sobre esta plataforma para un campo de aplicación predeterminado a partir de códigos fuentes solicitados por unos usuarios.

De forma más particular, la invención prevé incrementar las características de sistemas informáticos de forma independiente de la elección del lenguaje fuente y esto para unos sistemas que utilizan unos procesadores cuya arquitectura puede recurrir a unas instrucciones simples o complejas y que pueden comprender un número más o menos importante de registros, de unidades funcionales y de niveles de cache.

La invención tiene asimismo por objetivo evitar las limitaciones de la cobertura funcional de las bibliotecas de programas especializados y prevé crear un sistema de generación automática de códigos optimizados para un gran número de estructuras de código próximas, que pueden presentar diferentes niveles de complejidad.

Estos objetivos son alcanzados, de acuerdo con la invención, gracias a un sistema de generación automática de códigos optimizados operativos sobre una plataforma material previamente definida que comprende por lo menos un procesador, para un campo de aplicación predeterminado a partir de códigos fuentes solicitados por unos usuarios, caracterizado porque comprende unos medios de recepción de secuencias de códigos simbólicos llamadas secuencias-patrones representativas del comportamiento de dicho procesador en términos de características, para el campo de aplicación predeterminado; unos medios de recepción de parámetros estáticos definidos a partir de la plataforma material previamente definida, de su procesador y de las secuencias-patrones; unos medios de recepción de parámetros dinámicos también definidos a partir de la plataforma material previamente definida, de su procesador y de las secuencias-patrones; un dispositivo de análisis para establecer unas reglas de optimización a partir de ensayos y de mediciones y de características establecidas a partir de las secuencias-patrones, unos parámetros estáticos y unos parámetros dinámicos; un dispositivo de optimización y de generación de código que recibe por una parte las secuencias-patrones y por otra parte las reglas de optimización para examinar los códigos fuentes de usuarios, detectar unos bucles optimizables, descomponer en núcleos, ensamblar e inyectar unos códigos para suministrar unos códigos optimizados; y unos medios para reinyectar en las secuencias-patrones unas informaciones salidas del dispositivo de generación y optimización de códigos y relativas a unos núcleos.

De forma más particular, el dispositivo de análisis comprende un generador de ensayos conectado por una parte a los medios de recepción de secuencias-patrones y por otra parte a los medios de recepción de parámetros estáticos para generar automáticamente un número elevado de variantes de ensayos que son transferidas por unos medios de transferencia para ser almacenadas en una base de las variantes; un ejercitador conectado por una parte a unos medios de transferencia para recibir las variantes de ensayos almacenadas en la base de las variantes y por otra parte a los medios de recepción de parámetros dinámicos para ejecutar las variantes de ensayos en una gama de variación de los parámetros dinámicos y producir unos resultados que son transferidos por unos medios de transferencia para ser almacenados en una base de los resultados; y un analizador conectado a unos medios de transferencia para recibir los resultados almacenados en la base de los resultados, analizar estos y deducir de ellos unas reglas de optimización que son transferidas por unos medios de transferencia a una base de reglas de optimización.

Ventajosamente, el analizador comprende unos medios de filtrado con un umbral arbitrario de la característica óptima, de manera que considere una variante de la base de los resultados como óptima en el espacio de los parámetros desde que satisface los criterios de filtrado.

Según un modo de realización preferido, el analizador comprende además unos medios de modificación de los parámetros estáticos y de los medios de modificación de los parámetros dinámicos.

\newpage

El dispositivo de optimización y de generación de código comprende un dispositivo de generación de código optimizado y un optimizador, comprendiendo este último un módulo de elección de estrategia conectado por una parte a los medios de recepción de los núcleos identificados en los códigos fuentes de origen, por otra parte a los medios de recepción de secuencias-patrones y por otra parte a unos medios de recepción de reglas de optimización para generar, para cada núcleo correspondiente a una secuencia-patrón ensayada una pluralidad de versiones de las que cada una es óptima para una cierta combinación de parámetros, y un módulo de combinación y de ensamblaje conectado a los medios de recepción de reglas de optimización, a unos medios de recepción de informaciones salidas del módulo de elección de estrategia y a unos medios de recepción de la pluralidad de las versiones, para suministrar a través de los medios de transferencia unas informaciones que comprenden las versiones optimizadas correspondientes, su zona de utilización y en caso necesario el ensayo a ejecutar para determinar dinámicamente la versión más adecuada.

Según un modo de realización opcional preferido, el sistema comprende una base de los núcleos optimizados y el módulo de combinación y de ensamblaje está conectado con la base de los núcleos optimizados por unos medios de transferencia para almacenar en esta base de los núcleos optimizados las informaciones que comprenden las versiones optimizadas, su zona de utilización y en caso necesario el ensayo a ejecutar para determinar dinámicamente la versión más adecuada.

El dispositivo de optimización y de generación de código comprende un optimizador y un dispositivo de generación de código optimizado, comprendiendo este último un módulo de detección de bucles optimizables que está conectado a unos medios de recepción de los códigos fuentes de usuarios, un módulo de descomposición en núcleos, un módulo de análisis de caso, de ensamblaje y de inyección de código que está conectado a través de los medios de transferencia con el optimizador para transmitir la identificación del núcleo detectado y unos medios de transferencia para recibir las informaciones que describen el núcleo optimizado correspondiente, estando el módulo de análisis de caso, de ensamblaje y de inyección de código estando además conectado a unos medios de provisión de los códigos optimizados.

El módulo de análisis de caso, de ensamblaje y de inyección de código puede además estar conectado a la base de los núcleos optimzadospara recibir las informaciones que describen un núcleo optimizado sin invocar el optimizador si el núcleo buscado ha sido ya almacenado.

Según una característica ventajosa, el módulo de análisis de caso, de ensamblaje y de inyección de código comprende además unos medios para añadir a las secuencias-patrones unos núcleos que han sido puestos en evidencia en este módulo de análisis de caso, de ensamblaje y de inyección de código sin tener identificación correspondiente en la base de los núcleos optimizados, ni en las secuencias-patrones.

Según un modo de realización particular, el sistema comprende un compilador y un editor de uniones para recibir un código fuente modificado salido del dispositivo de optimización y de generación del código y producir un código binario optimizado adaptado a la plataforma material.

El sistema puede comprender unos medios para transferir del código fuente unos núcleos optimizados de la base de los núcleos optimizados hacia el compilador.

Según otra variante de realización, el sistema puede comprender un compilador y un módulo de instalación para instalar sobre la plataforma material una biblioteca dinámica que contiene el conjunto de las funcionalidades de los núcleos optimizados.

La invención puede aplicarse a diferentes campos de aplicación y en particular al cálculo científico, al tratamiento de señal y al tratamiento gráfico.

Según una característica particular, las secuencias-patrones comprenden un conjunto de códigos de tipo bucle simples y genéricos especificados en un lenguaje de tipo fuente y organizados en niveles de forma jerárquica por orden de complejidad creciente del código del cuerpo de bucle.

En este caso, las secuencias-patrones comprenden unas secuencias-patrones de nivel 0 en las cuales una sola operación elemental es ensayada y corresponde a un cuerpo de bucle constituido por una sola expresión aritmética representada por un árbol de altura 0.

Como suplemento, las secuencias-patrones pueden comprender unas secuencias-patrones de nivel 1 para las cuales son consideradas y ensayadas las combinaciones de dos operaciones de nivel 0, correspondiendo las operaciones de las secuencias-patrones de nivel 1 a unos cuerpos de bucles constituidos o bien por una sola expresión aritmética representada por un árbol de altura 1, o bien por dos expresiones aritméticas, estando cada una representada por un árbol de altura 0.

Según un modo de realización posible, la secuencias-patrones comprenden además unas secuencias-patrones de nivel 2 para las cuales son consideradas y ensayadas las combinaciones de dos operaciones de nivel 1 o de tres operaciones de nivel 0.

\newpage

Los parámetros estáticos comprenden en particular el número de iteraciones del bucle para secuencia-patrón, el paso de acceso a las tablas y el tipo de operando, el tipo de instrucciones utilizadas, las estrategias de precarga, las estrategias de ordenamiento de las instrucciones y de las iteraciones.

Los parámetros dinámicos comprenden en particular la localización de los operandos de tablas en los diferentes niveles de la jerarquía memoria, la posición relativa de las direcciones de partida de las tablas y el histórico de las conexiones.

Ventajosamente, la base de los núcleos optimizados comprende unas secuencias de código fuente de tipo bucle que corresponden a unos fragmentos de código real y útil y organizados en niveles por orden de complejidad creciente.

La plataforma material previamente definida puede comprender por ejemplo por lo meno un procesador de tipo denominado Itanium^{TM} de la sociedad INTEL o por lo menos un procesador del tipo Power o Power PC^{TM} de la sociedad IBM.

Según un modo de realización posible aplicable más particularmente a los sistemas que comprenden un procesador del tipo ITANIUM^{TM}, las reglas de optimización comprenden por lo menos algunas de las reglas siguientes:

(a)

minimizar el número de Escrituras en caso de malos resultados de las Escrituras con respecto a las Lecturas,

(b)

importancia de la utilización de los pares de carga en coma flotante,

(c)

ajustar el grado de desarrollo en función de la complejidad del cuerpo de bucle,

(d)

utilizar las latencias operativas de las operaciones aritméticas,

(e)

aplicar unas técnicas de enmascarado para los vectores cortos,

(f)

utilizar unos sufijos de localidad para los accesos memoria (Lectura, Escritura, Precarga),

(g)

definir las distancias de Precarga,

(h)

efectuar una vectorización de grado 4 para evitar una parte de los conflictos de bancos L2,

(i)

tener en cuenta múltiples variantes para evitar otra parte de los conflictos de bancos L2 y los conflictos en la fila de espera de las Lecturas/Escrituras,

(j)

tener en cuenta las ganancias de características ligadas a las diferentes optimizaciones,

(k)

utilizar unas cadenas de conexión que minimizan las malas predicciones (vectores cortos),

(l)

fusionar los accesos memorias (reagrupación de los píxeles),

(m)

vectorizar los tratamientos sobre píxeles.

\vskip1.000000\baselineskip

Según otro modo de realización posible aplicable más particularmente a los sistemas que comprenden un procesador tipo Power o PowerPC^{TM}, las reglas de utilización comprenden por lo menos algunas de las reglas siguientes:

(a)

reordenar las Lecturas para reagrupar los defectos de cache,

(b)

utilizar la precarga únicamente en las Escrituras,

(c)

ajustar el grado de desarrollo en función de la complejidad del cuerpo de bucle,

(d)

utilizar las latencias operativas de las operaciones aritméticas,

(e)

utilizar unos sufijos de localidad para los accesos memoria (Lectura, Escritura, Precarga),

(f)

definir las distancias de Precarga,

(g)

tener en cuenta múltiples variantes para evitar los conflictos en las filas de espera Lectura/Escritura,

(h)

tener en cuenta las ganancias de características ligadas a las diferentes optimizaciones.

\newpage

Otras características y ventajas de la invención resaltarán de la descripción siguiente de modos particulares de realización, dada con referencia a los planos anexos, en los cuales:

- la Figura 1 es un esquema-bloque que muestra el conjunto de los módulos de un sistema de generación automática de códigos optimizados según la invención,

- la Figura 2 es una esquema-bloque que muestra de forma más detallada la constitución de un módulo de análisis de características que puede ser utilizado en el sistema de la Figura 1,

- la Figura 3 es una esquema-bloque que muestra de forma más detallada la constitución de un módulo de optimización y de generación de código que puede ser utilizado en el sistema de la Figura 1,

- la Figura 4 es un esquema-bloque que muestra un primer ejemplo de módulo de generación de código fuente modificado, asociado a unos medios de obtención de código binario optimizado para la plataforma diana interesada, y

- la Figura 5 es un esquema-bloque que muestra un segundo ejemplo de módulo de generación de código fuente modificado, asociado a unos medios de obtención de código binario optimizado para la plataforma diana interesada.

Se hará referencia en primer lugar a la Figura 1 que muestra el conjunto del sistema de generación automática de código optimizado para proporcionar, sobre una salida 73 de un módulo 80 de optimización y de generación de código, unos códigos optimizados operativos sobre una plataforma material 90 previamente definida que comprende por lo menos un procesador 91.

El sistema de generación de código optimizado está adaptado a un campo de aplicación determinado y recibe, por una entrada 71 del módulo 80, unos códigos fuentes 17 solicitados por unos usuarios, debiendo el término usuarios entenderse en el amplio sentido e incluyendo en particular los usuario finales, los programadores de aplicaciones o los programadores de sistemas.

Una secuencias de código simbólicas llamadas secuencias-patrones 1 representativas del comportamiento del procesador 91 en términos de características para el campo de aplicación considerado, son aplicadas a una entrada 52 del módulo 80 de optimización y de generación de código y a una entrada 51 de un módulo de análisis 10.

El análisis del efecto de los diversos parámetros del entorno y de la interacción entre secuencias-patrones permite situar las zonas de buenas y malas características y de aprender de ello las razones. Las secuencias-patrones no representan forzosamente unas secuencias de código real generado por los lenguajes de programación clásicos. Solamente un subconjunto de las secuencias-patrones ensayadas corresponde a unos núcleos utilizados para la optimización del código usuario.

Un bucle optimizable es una construcción de programa que codifica la representación algorítmica de una operación más o menos compleja sobre unas variables-vectores.

Un núcleo o bucle elemental constituye una forma simple de bucle optimizable. El módulo 80 del sistema según la invención permite generar automáticamente un número de núcleos optimizados sustancialmente superior al número de funciones ofrecidas por las bibliotecas especializadas matemáticas. En general, pueden ser generadas varias versiones de un mismo núcleo, siendo cada versión optimizada para una cierta combinación de parámetros de entorno.

La fase de optimización en un optimizador 12 (figura 3) consiste así en la generación automática de un conjunto o biblioteca de núcleos optimizados para la plataforma diana 90 que representa unas funcionalidades representativas del campo de aplicación.

La fase de optimización está asociada a una fase de generación de código en un generador de código 18 (figura 3) que examina el código fuente del programa usuario para detectar en el mismo los bucles optimizables a fin de forzar la utilización de núcleos optimizados en lugar y posición del código que habría generado el compilador estándar.

Están previstos unos medios 74 para reinyectar en las secuencias-patrones 1 las informaciones salidas del módulo 80.

Las fases de optimización y de generación de código están precedidas por una fase de análisis en un módulo de análisis 10 que sirve para determinar, para la plataforma material diana 90 y el campo de aplicación considerado, las reglas de optimización a respetar para obtener unas características óptimas. Una salida 57 del módulo de análisis 10 permite la transferencia de las reglas de optimización hacia una base 9 de reglas de optimización a su vez conectada, por unos medios de transferencia 18, al optimizador 12 del módulo 80.

Se describirá ahora de forma más particular el módulo de análisis 10 con referencia a la figura 2.

Unos parámetros estáticos 2 y unos parámetros dinámicos 7, identificados en función de la arquitectura del procesador 91, y más generalmente del sistema que es la base de la plataforma 90 diana de la optimización, y también en función de las secuencias-patrones, son aplicados por unos medios 53, 54 al módulo de análisis 10.

Los parámetros estáticos 2 pueden comprender en particular el número de iteraciones del bucle para cada secuencia-patrón, el paso de acceso a las tablas y el tipo de operando, el tipo de instrucciones utilizadas, las estrategias de precarga, las estrategias de ordenamiento de las instrucciones y de las iteraciones.

Los parámetros dinámicos 7 pueden comprender en particular la localización de los operandos de tablas en los diferentes niveles de la jerarquía memoria, la posición relativa de las direcciones de partida de las tablas y el histórico de las conexiones.

En el módulo 10 de análisis de características, un generador de ensayo 3 explota los datos relativos a los parámetros estáticos 2 y dinámicos 7, que le son proporcionados por los entradas 51, 53 para generar un número potencialmente muy elevado de variantes que son transferidas por unos medios de transferencia 61 hacia una base de datos de las variantes 4.

Otra herramienta automática 5 denominada ejercitador recibe, por unos medios de transferencia 62, los datos de las variantes y la base de las variantes 4, utiliza los ensayos así fabricados, los ejecuta haciendo variar en su gama de variación los parámetros dinámicos 7 proporcionados por los medios de transferencia 55 y transfiere, por unos medios de transferencia 63, las mediciones pertinentes hacia otra base de datos 6 denominada base de los resultados.

Las medidas almacenadas en la base de los resultados 6 son a su vez transferidas, por unos medios de transferencia 64, hacia un analizador 8 que, a partir de la identificación de las zonas de buena y mala característica en función del parametraje, permite la formulación de las reglas de optimización 9 que son transferidas por los medios de transferencia 57 a la base 9 de reglas de optimización.

El analizador 8 comprende también unos medios 54 de modificación de los parámetros estáticos 2 y unos medios 56 de modificación de los parámetros dinámicos, por ejemplo si se ha constatado una baja sensibilidad a las variaciones de un parámetro dado.

El analizador 8 puede comprender unos medios de filtrado con un umbral arbitrario de la característica óptima. En esta caso, una variante de la base de los resultados que no corresponde a unas características óptimas puede sin embargo ser considerada como óptima en el espacio de los parámetros, desde que satisface los criterios de filtrado.

Se describirá ahora el módulo 80 de optimización y de generación de código con referencia a la Figura 3.

El dispositivo de optimización 12 comprende un módulo 13 de elección de estrategia conectado al módulo 18 de generación de código por unos medios 92 de recepción de los núcleos identificados en los códigos fuentes de origen. El módulo 13 de elección de estrategia está además conectado a unos medios 52 de recepción de secuencias-patrones 1 y a unos medios 58 de recepción de reglas de optimización 9. El módulo 13 de elección de estrategia genera en su salida 67, para cada núcleo correspondiente a una secuencia-patrón ensayada, un conjunto 15 de n versiones de las que cada una es óptima para una cierta combinación de parámetros.

Un módulo 14 de combinación y de ensamblaje de versiones está conectado a los medios 59 de recepción de reglas de optimización 9, a unos medios 66 de recepción de informaciones salidas del módulo de elección de estrategia 13 y a unos medios 68 de recepción de la pluralidad 15 de versiones 1 a n. El módulo 14 suministra a través de los medios de transferencia 93 unas informaciones que comprenden las versione optimizadas correspondientes, su zona de utilización y en caso necesario el ensayo a ejecutar para determinar dinámicamente la versión más adecuada.

El módulo 18 de generación de código optimizado comprende un módulo 20 de detección de bucles optimizables que está conectado a unos medios 71 de recepción de los códigos fuentes 17 de usuarios. La salida 75 del módulo 20 está conectada a un módulo 22 de descomposición en núcleos cuya salida 77 está a su vez conectada a un módulo 23 de análisis de caso, de ensamblaje y de inyección de código que está conectado, a través de los medios de transferencia 92, al optimizador 12 para transmitir la identificación del núcleo detectado. El módulo 23 recibe por otra parte, por unos medios de transferencia 93, las informaciones que describen el núcleo optimizado correspondiente. El módulo 23 está también conectado a unos medios 73 de provisión de los códigos optimizados 19.

Según una variante de realización ventajosa, el módulo 80 de optimización y de generación de código comprende una base de los núcleos optimizados 16. El módulo de combinación y de ensamblaje 14 está conectado a la base de los núcleos optimizados 16 por unos medios de transferencia 79 para almacenar en esta base de los núcleos optimizados las informaciones que comprenden las versiones optimizadas, su zona de utilización y en caso necesario el ensayo a ejecutar para determinar dinámicamente la versión más adecuada. Según esta variante, el módulo 23 de análisis de caso, de ensamblaje y de inyección de código está además conectado a la base 16 de los núcleos optimizados por los medios de transferencia 72 para recibir las informaciones que describen un núcleo optimizado, sin invocar el optimizador 12, si el núcleo buscado ha sido ya almacenado en esta base 16.

Como se puede ver en la Figura 3, el módulo 23 de análisis de caso, de ensamblaje y de inyección de código comprende, demás de los medios 74 para añadir a las secuencias-patrones 1 unos núcleos que han sido puestos en evidencia en este módulo 23 sin tener la identificación correspondiente en la base 16 de los núcleo optimizados, ni en las secuencias-patrones.

La Figura 4 muestra un ejemplo particular de realización para el cual no se ha representado el optimizador 12 que queda idéntico a la variante de la figura 3 según la cual existe una base 16 de los núcleos optimizados.

En este ejemplo de realización, el módulo 18 de generación de código produce en la salida 73 del módulo 23 de análisis de caso, de ensamblaje y de inyección de código, un código fuente modificado 19 que es a continuación tratado por unas herramientas clásicas de preparación de programa 81, 82 para la obtención de código binario 83 optimizado para la plataforma diana 90.

La Figura 4 representa un ejemplo de realización que puede ser muy fácilmente utilizado. El código fuente usuario de origen 17 ha sido modificado en el seno del módulo 80 de optimización y de generación de código ya descrito más arriba, de tal manera que los bucles optimizables sean remplazados por unas llamadas a unos subprogramas, siendo el código correspondiente a estos subprogramas inyectado en el código fuente modificado 19 desde la base de los núcleos optimizados 16. El código fuente 19 así modificado contiene entonces todo lo necesario para generar un código binario optimizado 83 adaptado a la plataforma material 90, por un paso por una cadena clásica que comprende un compilador 81 y un editor de uniones 82.

Según una variante posible, del código fuente de los núcleos optimizados de la base de los núcleos optimizados 16 puede ser utilizado directamente en la etapa de compilación como biblioteca fuente de aportación. Esto está simbolizado en la figura 4 por la flecha punteada 85 que une la base de los núcleos optimizados 16 al compilador 81. Esta variante permite así evitar la inyección directa de este código fuente de los núcleos optimizados en el código fuente modificado y aligera la etapa de generación en el seno del módulo 18.

La Figura 5 representa otra variante de realización del ejemplo de realización de la Figura 4.

La variante de la Figura 5 explota la posibilidad que ofrecen algunos sistemas de explotación de instalar unas bibliotecas en forma de códigos binarios ejecutables y accesibles por unos programas de edición de uniones dinámicas en el momento de su ejecución.

En el caso de la variante de la Figura 5, no es ya necesario inyectar código desde la base de los núcleos optimizados 16 hacia el código fuente modificado 19. En contrapartida, una biblioteca dinámica que contiene el conjunto de las funcionalidades de los núcleos optimizados debe ser instalada sobre la plataforma diana 90 por medio de un compilador 181 y de un módulo de instalación 182. Se puede utilizar un solo compilador común para los compiladores 81 y 181 de la Figura 5. En esta variante de la Figura 5, la operación de instalación sólo es necesaria una sola vez para cada plataforma diana, de manera que esta variante es la más económica en términos de tratamiento global del proceso de optimización.

La utilización de un sistema de generación de código optimizado según la invención se aplica particularmente bien a los tres campos que son el cálculo científico, el tratamiento de la señal y el tratamiento gráfico.

En efecto, los códigos utilizados en estos tres campos presentan varias características CAR1 a CAR4 que son importantes para esta realización.

\circ

CAR 1: Las estructuras de tipo bucle (o "nidos de bucles") constituyen las porciones de código más consumidoras en términos de tiempo de ejecución

\circ

CAR 2: Las estructuras de datos utilizadas son en su mayor parte de tipo tabla multidimiensional y son accedidas según unos motivos muy regulares (líneas, columnas, bloques, etc)

\circ

CAR 3: Los bucles (o nidos de bucles) están en general constituidos por iteraciones independientes y paralelizables

\circ

CAR 4: El cuerpo del bucle está en general constituido por una secuencia de expresiones aritméticas y corresponde a un círculo uniforme (o casi uniforme) sobre un gran volumen de datos.

\vskip1.000000\baselineskip

Naturalmente, si bien estos tres campos del cálculo científico, del tratamiento de señal y del tratamiento gráfico poseen unos puntos comunes, los mismos presentan también ciertas grandes diferencias. Así en el campo del tratamiento de señal, los datos de tipo complejo constituyen un tipo de datos extremadamente importante que requiere unas optimizaciones específicas, mientas que la importancia de este tipo de datos es marginal en los otro dos campos. El tratamiento gráfico en cuanto a sí mismo está muy marcado por la utilización de un tipo de datos particular, los píxeles, y de una aritmética especial. Además en gráfica, la estructuración de los datos y de los algoritmos con respecto a una pantalla binimienional es fundamental.

Las cuatro características anteriores (CAR1 a CAR4) tienen unas consecuencias muy fuertes para la optimización de código y permiten el desarrollo de técnicas completamente específicas:

\circ

CAR 1 \Rightarrow las optimizaciones van de hecho a concentrarse sobre las estructuras de tipo "bucle" que presentan dos ventajas principales: repetitividad (y predictibilidad) y compacidad de representación.

\global\parskip0.950000\baselineskip

\circ

CAR 2 \Rightarrow los accesos a las tablas que representan una parte importante (incluso mayor en razón de la utilización creciente de las cache) de los tiempos de ejecución podrán fácilmente ser analizados y optimizados en razón de su regularidad

\circ

CAR 3 \Rightarrow la independencia de las iteraciones en el seno de un bucle y de nidos de bucles, permitirá la utilización (la optimización) de recorridos del espacio de iteración en función de los accesos a las tablas y esto según las características propias de la arquitectura diana. Se puede destacar que acceder a N elementos dados de una tabla puede ser realizado de N! maneras (ordenes) diferentes.

\circ

CAR 4 \Rightarrow la estructura simple del cuerpo de bucle en términos de expresiones aritméticas permitirá utilizar una aproximación sistemática y jerárquica que se apoya en la representación en forma de árboles de una expresión aritmética.

\vskip1.000000\baselineskip

La fase de análisis resulta una fase esencialmente experimental al final de la cual es preciso:

\bullet

haber determinado los puntos fuertes y los puntos débiles de la arquitectura,

\bullet

saber correlacionar característica y estructura de código,

\bullet

haber identificado las buenas estrategias de optimización, pudiendo estas ser función de diferentes parámetros ligados al código.

\vskip1.000000\baselineskip

Como ya se ha indicado, el punto de partida es un conjunto de códigos "de tipo fuente" simples pero genéricos llamados "secuencias-patrones". Estos códigos tienen una estructura de tipo bucle, indicando el término "tipo fuente" que las operaciones son especificadas a alto nivel y no a nivel ensamblador.

Estos códigos están organizados en niveles de forma jerárquica por orden de complejidad creciente del código del cuerpo de bucle de la manera siguiente:

\bullet

SECUENCIA-PATRÓN NIVEL 0: a este nivel, una sola operación elemental es ensayada, es decir que el cuerpo de bucle comprende una sola operación: lectura de un elemento de tabla, escritura de un elemento de tabla, adición flotante, etc.... Estas operaciones corresponden a unos cuerpos de bucle constituido por una sola expresión aritmética representada por un árbol de altura 0.

\bullet

SECUENCIA-PATRÓN NIVEL 1: a este nivel, son consideradas y ensayadas las combinaciones de dos operaciones de nivel 0: lectura y escritura de una tabla, lectura de dos tablas diferentes, lectura y adición sobre una tabla etc... Estas operaciones corresponden a unos cuerpos de bucles constituidos o bien por una sola expresión aritmética representada por un árbol de altura 1, o bien dos expresiones aritméticas, estando cada una representada por un árbol de altura 0.

\bullet

SECUENCIA-PATRÓN NIVEL 2: a este nivel las combinaciones de dos operaciones de nivel 1 o de tres operaciones de nivel 0 son consideradas y ensayadas: lectura de tres tablas diferentes, lectura y edición de dos tablas componente a componente y escritura del resultado en una tercera tabla, etc...

\bullet

SECUENCIA-PATRÓN NIVEL K: el nivel K puede ser fácilmente definido por recurrencia a partir de los niveles precedentes.

\vskip1.000000\baselineskip

Todas las secuencias-patrones de nivel 0 corresponden a unos códigos que son "artificiales", es decir que no traducen unos bucles "reales".

Esta organización en niveles de complejidad creciente es también utilizada en la fase de optimización.

El conjunto de las secuencias-patrones así definido es infinito.

Estas secuencias-patrones utilizan dos clases de parámetros diferentes:

\bullet

Parámetros estáticos: estos parámetros son definidos de forma estática (es decir antes de ejecución e independientemente de la ejecución). Estos parámetros estáticos están a su vez subdivididos en dos grandes subclases: parámetros estáticos de alto nivel (número de iteraciones del bucle, paso de acceso a las tablas, tipo de operando,...), parámetros estáticos de bajo nivel (utilización de instrucciones específicas, ordenamiento de las instrucciones, etc)

\bullet

Parámetros dinámicos: estos parámetros son definidos cuando tiene lugar la ejecución del bucle. Comprenden por ejemplo: localización de los operandos de tablas en la jerarquía memoria, posición relativa de las direcciones de partida de las tablas,...

\global\parskip1.000000\baselineskip

Estas dos clases de parámetros son explotadas de manera muy diferentes: los parámetros estáticos serán utilizados para generar los diferentes códigos ensayos en combinación con las variantes/ optimizaciones descritas a continuación, mientras que los parámetros dinámicos son exclusivamente utilizados cuando tiene lugar la ejecución en el banco de ensayo.

Los parámetros estáticos de alto nivel son relativamente limitados y corresponden esencialmente a los parámetros clásicos de un bucle y de tablas expresadas en un lenguaje de alto nivel (Fortran ó C por ejemplo) sin ninguna especificidad que provenga del procesador diana.

Los parámetros estáticos de bajo nivel permitirán tener en cuenta todas las especificidades ligadas al procesador (arquitectura) y al ordenamiento de las instrucciones (generador de código objeto). En efecto, las secuencias-patrones son de hecho unas abstracciones de alto nivel (definidas en un lenguaje fuente, independientes de la arquitectura del procesador previsto) y no integran en particular ninguna optimización. Para ensayarlas, en un procesador dado, es preciso generar y optimizar los códigos ensambladores correspondientes. Cuando tiene lugar esta generación, varias variantes (secuencia de instrucciones ensambladoras) serán generadas automáticamente. Todas las variantes asociadas a una misma secuencia-patrón son unos códigos semánticamente equivalentes a la secuencia-patrón de partida. Son estas variantes que serán ejecutadas y medidas. Estas variantes corresponden de hecho a diferentes técnicas de optimización de código (es decir a unos parámetros estáticos de bajo nivel). Estas optimizaciones pueden ser definidas de forma abstracta sin referencia a la estructura particular de una secuencia-patrón y constituyen la parte esencial de los parámetros estáticos de bajo nivel.

Los parámetros estáticos de bajo nivel comprenden:

\bullet

la utilización de las instrucciones de ensambladores: una misma operación a nivel fuente puede ser utilizada por diferentes secuencias de instrucciones. En particular es preciso tratar aquí las diferentes estrategias posibles para utilizar la precarga de los datos y de las instrucciones.

\bullet

la estructura del cuerpo de bucle: desarrollado(grado variable) del cuerpo de bucle,

\bullet

el ordenamiento del cuerpo de bucle: ordenamiento de las instrucciones del cuerpo de bucle (distancias de precarga, vectorización), reagrupación de los errores de cache, tratamiento de los conflictos en las filas de espera,

\bullet

el ordenamiento de las iteraciones: pipeline lógico (profundidad variable).

\vskip1.000000\baselineskip

En numerosos compiladores, los parámetros estáticos de bajo nivel descritos anteriormente corresponden a unas opciones de compilación que permiten utilizar de forma explicita la optimización prevista.

La función del generador de ensayo 3 es generar las diferentes variantes descritas anteriormente que corresponden por una parte a los parámetros estáticos de alto nivel (por ejemplo, sin acceso a las tablas) y por otra parte a los parámetros estáticos de bajo nivel.

Debe observarse que para unas secuencias-patrones de nivel 1, el número total de variantes a generar/analizar es extremadamente elevado y se cifra en varios millones. A pesar de ello, el proceso de generación y de análisis puede ser muy simplemente automatizado.

A nivel del ejercitador 5 y del almacenado 8, se trata de ensayar las características de las diferentes variantes y de seleccionar las mejores variantes/optimizaciones posibles.

Esta fase implica la generación de un gran número de resultados almacenados en la base de resultados 6. Las experimentaciones son efectuadas de forma jerárquica y entrelazada con las fases de análisis: así las primeras experimentaciones son efectuadas sobre las variantes de las secuencias-patrones de nivel 0. Al final de esta primera campaña de experimentación, una primera selección sobre las diferentes variantes puede ser efectuada en función de los resultados obtenidos. Algunas variantes pueden así ser enseguida eliminadas y no serán ya consideradas para los niveles siguientes. Esto permite limitar la explosión combinatoria del número de experiencias a realizar.

La fase de análisis d los resultados es a primera vista bastante simple de efectuar puesto una sola métrica (característica) es utilizada. De hecho una gran parte de la complejidad del proceso proviene del hecho de que, en general, la elección de las mejores variantes dependerá en gran manera de los parámetros.

Una primera selección puede ser realizada de forma muy simple calculando según las especificaciones de la arquitectura, las características óptimas para cada una de las secuencias-patrones. Por el contrario, pueden aparecer dificultades rápidamente, ligadas a las interacciones complejas entre arquitectura y códigos (incluso para unos códigos tan simples como las secuencias-patrones de nivel 0 y 1): esto se traduce por unas figuras complicadas que describen las variaciones de la característica en función de los parámetros. Estos comportamientos complejos pueden ser en primer lugar analizados utilizando unos algoritmos de tratamiento de imagen y después sintetizados calificando una variante dada para una cierta gama de parámetro. Así la fase de análisis no genera simplemente una lista que indica para cada secuencia-patrón la mejor (y única) variante/técnica de optimización: de hecho para cada secuencia-patrón, una lista de gamas de parámetros es determinada y, para cada una de estas gamas, la mejor variante/técnica de optimización es indicada: es dicha información que será llamada "regla de optimización".

El conjunto de las secuencias-patrones ensayadas es un subconjunto muy restringido del conjunto de las secuencias-patrones. Este conjunto que es utilizado a continuación para las optimizaciones se llama "conjunto de las secuencias-patrones de referencia".

En la práctica, es muy importante fijar un objetivo "razonable" de optimización: así buscar a cualquier precio el óptimo puede generar un número muy elevado de variantes mientras que relajando la obligación de óptimo y contentándose con características en una proximidad de 5 a 10% del óptimo, puede ser utilizada una sola variante para una gran gama de parámetros. Se procede para ello a un filtrado por ejemplo con un umbral de 90% de la característica óptima.

En la práctica, es suficiente ensayar y analizar solamente los niveles 0, 1 y 2 de las secuencias-patrones para liberar y validar las principales técnicas de optimización. El conjunto de referencia de las secuencias-patrones no contendrá en general secuencias de nivel superior a 3.

En efecto, el volumen de experimentaciones resulta rápidamente muy elevado en particular más allá del nivel 2.

El conjunto de las experimentaciones se presta de manera ideal para la paralelización: los ensayos pueden ser ejecutados en paralelo en 100 ó 1000 máquinas. Esta propiedad de paralelización es extremadamente útil y permite efectuar unas exploraciones sistemáticas y esto en unos tiempos aceptables.

Esta fase es completamente automatizable y los procedimientos de verificación de calidad y de coherencia de los resultados pueden ser también automatizados. La intervención humana sólo es requerida para la detección de errores/anomalías que resultan del análisis de los resultados producidos automáticamente por los procedimiento de verificación de calidad y de coherencia.

Al final de la fase de análisis, el objetivo es disponer de un gran número de códigos simples llamados "núcleos" específicamente optimizados para la arquitectura diana, apoyándose este proceso de optimización de forma esencial en las técnicas de optimización obtenidas al final de la fase de análisis.

De manera estricta, los "núcleos" son unas secuencias de código fuente de tipo bucle y constituyen un subconjunto del caso general de las secuencias-patrones. A diferencia de estas últimas, corresponden a unos fragmentos de código real y útil. Como las secuencias-patrones, están organizados en niveles por orden de complejidad creciente.

La generación/optimización de estos núcleos se desarrolla según las cuatro fases siguientes:

\circ

Correlación con una o varias secuencias-patrones de referencia: para los núcleos más simples, hay una correspondencia directa entre núcleos y secuencias-patrones, para los núcleos más complejos, el núcleo será descompuesto en varias secuencias-patrones de referencia. Esta correlación/descomposición es efectuada a nivel fuente en función de las características del cuerpo de bucle del núcleo: número de tablas, sin acceso a las tablas, etc..

\circ

Generación de código/Ordenamiento de instrucciones/optimización de instrucciones: se trata de utilizar las técnicas de optimización detectadas cuando tiene lugar la fase de análisis (en función de las secuencias-patrones correspondientes) y aplicarlas directamente a la generación/optimización de código para los núcleos. Para un mismo núcleo, podrán ser generadas varias versiones posibles y esto en función de los parámetros.

\circ

Asignaciones de registro: buen número de las técnicas de optimización utilizadas incrementan de forma sensible la presión sobre los registros disponibles. En este caso, conviene controlar la asignación del conjunto de los registros disponibles.

\circ

Experimentación/Validación: el núcleo generado y optimizado es ensayado utilizando el banco de ensayo de la fase de análisis. Al final de esta fase, es constituido un modelo simple de las características del núcleo.

\vskip1.000000\baselineskip

Con respecto a las optimizaciones clásicas utilizadas en un compilador, las optimizaciones utilizadas aquí son muy diferentes: en primer lugar las mismas son derivadas directamente de un proceso detallado de evaluación de características (efectuado cuando tiene lugar la fase de análisis) a continuación son mucho más complejas y rendibles (en particular para la asignación de registros) puesto que son ejecutadas fuera de conexión sin "obligación" de tiempo.

La utilización de las secuencias-patrones de referencia y de las reglas de generación permite tener en cuenta por una parte todas las características finas de la arquitectura (características operativas medidas y no teóricas) y por otra parte las diferentes versiones que deben ser seleccionadas en función de los parámetros.

Al final de esta fase, ha sido construida una base de datos 16 de los núcleos optimizados, que contiene no solamente los códigos generados sino también las informaciones relativas a las características y esto en función de los diferentes parámetros. Cada uno de estos núcleos es por otra parte ensayado según el procedimiento utilizado para las secuencias-patrones.

En la práctica, la base 16 de los núcleos optimizados comprende de forma sistemática y exhaustiva todos los núcleos de niveles 1, 2, 3, 4 y 5. El coste en términos de volumen de cálculo de la construcción de esta base de datos es importante pero como para la fase de análisis de características, la misma se paraleliza muy eficazmente.

La optimización del código usuario se desarrolla en tres fases.

\circ

Detección de lo bucles optimizables (módulo 20): se trata de reconocer en el seno del código fuente los bucles que pueden ser descompuestos en núcleos. Esta fase utiliza unas técnicas muy próximas a la de los paralelizadores/vectorizadores automáticos. Si es necesario, el código fuente es reestructurado para hacer aparecer el bucle en la forma más favorable para la optimización,

\circ

Análisis del bucle optimizable, descomposición en núcleos (módulo 22): apoyándose en unas técnicas de aparejamiento de configuración y de descomposición próximas a las utilizadas para la optimización de los núcleos, el bucle es descompuesto en una secuencia de núcleos.

\circ

Ensamblaje e inyección de código (módulo 23): los diferentes núcleos utilizados para la descomposición son ensamblados y reinyectados en el código fuente.

\vskip1.000000\baselineskip

El procedimiento de descomposición es en general parametrado en función de características del bucle fuente de origen.

Las optimizaciones propuestas pueden ser integradas.

\circ

o bien por un preprocesador en una cadena de compilación existente y esto de forma transparente, es decir sin que sea necesario tener acceso al código del compilador,

\circ

o bien directamente en un compilador, necesitando esto evidentemente unas modificaciones en el código del compilador.

\vskip1.000000\baselineskip

Como ya se ha indicado más arriba con referencia a la Figura 3, al final de la fase de análisis un cierto número de reglas de utilización están disponibles: estas reglas son función de la secuencia-patrón y de la gama de parámetro. En lugar de pasar por la etapa intermedia de los núcleos, una variante posible es correlacionar directamente el bucle utilizable con las secuencias-patrones y aplicar directamente las reglas de optimización sobre el bucle optimizable sin pasar por el almacenado de núcleos en una base 16 de los núcleos optimizados.

Esta variante es más simple que el paso por los núcleos y permite una utilización más flexible de las reglas de optimización. En contrapartida, debido a que es realizada esencialmente en línea, el número de variantes exploradas será necesariamente más restringido y por tanto las características obtenidas serán a priori un poco menos buenas.

Al final de la fase de optimización, el sistema ha generado unas formas optimizadas para un cierto número de bucles "optimizables" que a priori no estaban directamente disponibles en la base de los núcleos puesto que habían necesitado una descomposición. Estas formas optimizadas pueden ser almacenadas en la base 16 de los núcleos optimizados y reutilizadas a continuación. Así, la base de datos 16 de los núcleos es enriquecida automáticamente por esta forma de aprendizaje.

Claims (26)

1. Sistema de generación automática de códigos optimizados (19) operativos sobre una plataforma material previamente definida (90) que comprende por lo menos un procesador (91), para un campo de aplicación predeterminado a partir de códigos fuentes (17) solicitados por unos usuarios, caracterizado porque comprende unos medios (51, 52) de recepción de secuencias de códigos simbólicos denominadas secuencias-patrones (1) representativas del comportamiento de dicho procesador (91) en términos de prestaciones, para el campo de aplicación predeterminado; unos medios (53) de recepción de parámetros estáticos (2) definidos a partir de la plataforma material previamente definida (90), de su procesador (91) y de las secuencias-patrones (1); unos medios (55) de recepción de parámetros dinámicos (7) también definidos a partir de la plataforma material previamente definida (90), de su procesador (91) y de las secuencias-patrones (1); un dispositivo de análisis (10) para establecer unas reglas de optimización (9) a partir de ensayos y de mediciones de características establecidos a partir de las secuencias-patrones (1), de los parámetros estáticos (2) y de los parámetros dinámicos (7); un dispositivo (80) de optimización y de generación de código que recibe por una parte las secuencias-patrones (1) y por otra parte las reglas de optimización (9) para examinar los códigos fuentes (17) de usuarios, detectar unos bucles optimizables, descomponer en núcleos, ensamblar e inyectar unos códigos para suministrar uno códigos optimizados (19); y unos medios (74) para reinyectar en las secuencias-patrones (1) unas informaciones procedentes del dispositivo (80) de generación y optimización de códigos y relativas a unos núcleos.

2. Sistema según la reivindicación 1, caracterizado porque el dispositivo de análisis (10) comprende un generador de ensayos (3) conectado por una parte a los medios (51) de recepción de secuencias-patrones y por otra parte a los medios (53) de recepción de parámetros estáticos para generar automáticamente un número elevado de variantes de ensayos que son transferidas por unos medios de transferencia (61) para ser almacenadas en una base de las variantes (4); un ejercitador (5) conectado por una parte a unos medios de transferencia (62) para recibir las variantes de ensayos almacenados en la base de variantes (4) y por otra parte a los medios (55) de recepción de parámetros dinámicos para ejecutar las variantes de ensayos en una gama de variación de los parámetros dinámicos (7) y producir unos resultados que son transferidos por unos medios de transferencia (63) para ser almacenados en una base de los resultados (6); y un analizador (8) conectado a unos medios de transferencia (64) para recibir los resultados almacenados en la base de los resultados (6), analizarlos y deducir de ellos unas reglas de optimización que son transferidas por unos medios de transferencia (57) a una base de reglas de optimización (9).

3. Sistema según la reivindicación 2, caracterizado porque el analizador (8) comprende unos medios de filtrado con un umbral arbitrario de la prestación óptima, de manera que considere una variante de la base de los resultados como óptima en el espacio de los parámetros desde que satisface los criterios de filtrado.

4. Sistema según la reivindicación 2 ó 3, caracterizado porque el analizador (8) comprende además unos medios (54) de modificación de los parámetros estáticos (2) y de los medios (56) de modificación de los parámetros dinámicos (7).

5. Sistema según cualquiera de las reivindicaciones 1 a 4, caracterizado porque el dispositivo (80) de optimización y de generación de código comprende un dispositivo (18) de generación de código optimizado y un optimizador (12), comprendiendo este último un módulo de elección de estrategia (13) conectado por una parte a los medios (92) de recepción de los núcleos identificados en los códigos fuente de origen, por otra parte a los medios (52) de recepción de secuencias-patrones (1) y por otra parte a unos medios (58) de recepción de reglas de optimización (9) para generar, para cada núcleo correspondiente a una secuencia-patrón ensayada una pluralidad de versiones (15) de las que cada una es óptima para una cierta combinación de parámetros, y un módulo de combinación y de ensamblaje (14) conectado a los medios (59) de recepción de reglas de optimización (9), a unos medios (66) de recepción de informaciones procedentes del módulo de elección de estrategia (13) y a unos medios (68) de recepción de la pluralidad de las versiones (15) para suministrar a través de los medios de transferencia (93) unas informaciones que comprenden las versiones optimizadas correspondientes, su zona de utilización y en caso necesario el ensayo a ejecutar para determinar dinámicamente la versión más adaptada.

6. Sistema según la reivindicación 5, caracterizado porque comprende una base de los núcleos optimizados (16) y porque el módulo de combinación y de ensamblaje (14) está conectado a la base de los núcleos optimizados (16) mediante unos medios de transferencia (79) para almacenar en esta base de los núcleos optimizados las informaciones que comprenden las versiones optimizadas, su zona de utilización y en caso necesario el ensayo a ejecutar para determinar dinámicamente la versión más adaptada.

7. Sistema según cualquiera de las reivindicaciones 1 a 6, caracterizado porque el dispositivo (80) de optimización y de generación de código comprende un optimizador (12) y un dispositivo (18) de generación de código optimizado, comprendiendo esté último un módulo (20) de detección de bucles optimizables que está conectado a unos medios (71) de recepción de los códigos fuentes (17) de usuarios, un módulo (22) de descomposición en núcleos, un módulo (23) de análisis de caso, de ensamblaje y de inyección de código que está conectado a través de los medios de transferencia (92) con el optimizador (12) para transmitir la identificación del núcleo detectado y de los medios de transferencia (93) para recibir las informaciones que describen el núcleo optimizado correspondiente, estando además el módulo (23) de análisis de caso, de ensamblaje y de inyección de código conectado a unos medios (73) de provisión de los códigos optimizados.

8. Sistema según las reivindicaciones 6 y 7, caracterizado porque el módulo (23) de análisis de caso, de ensamblaje y de inyección de código está además conectado a la base (16) de los núcleos optimizados para recibir las informaciones que describen un núcleo optimizado sin invocar el optimizador (12) si el núcleo buscado ha sido almacenado.

9. Sistema según la reivindicación 8, caracterizado porque el módulo (23) de análisis de caso, de ensamblaje y de inyección de código comprende además unos medios (74) para añadir a las secuencias-patrones (1) unos núcleos que han sido puestos en evidencia en este módulo (23) de análisis de caso, de ensamblaje y de inyección de código sin tener identificación correspondiente en la base (16) de los núcleos optimizados, ni en las secuencias-patrones.

10. Sistema según cualquiera de las reivindicaciones 6, 8 y 9, caracterizado porque comprende un compilador (81) y un editor de uniones (82) para recibir un código fuente modificado (19) procedente del dispositivo (80) de optimzación y generación del código y producir un código binario optimizado (83) adaptado a la plataforma material (90).

11. Sistema según la reivindicación 10, caracterizado porque comprende unos medios (85) para transferir del código fuente unos núcleos optimizados de la base de los núcleos optimizados (16) hacia el compilador (81).

12. Sistema según la reivindicación 10, caracterizado porque comprende un compilador (181) y un módulo de instalación (182) para instalar sobre la plataforma material (90) una biblioteca dinámica que contiene el conjunto de las funcionalidades de los núcleos optimizados.

13. Sistema según cualquiera de las reivindicaciones 1 a 12, caracterizado porque el campo de aplicación predeterminado es el cálculo científico.

14. Sistema según cualquiera de las reivindicaciones 1 a 12, caracterizado porque el campo de aplicación predeterminado es el tratamiento de la señal.

15. Sistema según cualquiera de las reivindicaciones 1 a 12, caracterizado porque el campo de aplicación predeterminado es el tratamiento gráfico.

16. Sistema según cualquiera de las reivindicaciones 1 a 15, caracterizado porque las secuencias-patrones (1) comprenden un conjunto de códigos de tipo bucle simples y genéricos especificados en un lenguaje de tipo fuente y organizados en niveles de forma jerárquica por orden de complejidad creciente del código del cuerpo de bucle.

17. Sistema según la reivindicación 16, caracterizado porque las secuencias-patrones (1) comprenden una secuencias-patones de nivel 0 en las cuales una sola operación elemental es ensayada y corresponde a un cuerpo de bucle constituido por una sola expresión aritmética representada por un árbol de altura 0.

18. Sistema según la reivindicación 17, caracterizado porque las secuencias-patrones comprenden unas secuencias-patrones de nivel 1 para las cuales son consideradas y ensayadas las combinaciones de dos operaciones de nivel 0, correspondiendo las operaciones de las secuencias-patrones de nivel 1 a unos cuerpos de bucles constituidos o bien por una sola expresión aritmética representada por un árbol de altura 1, o bien por dos expresiones aritméticas, estando cada una representada por un árbol de altura 0.

19. Sistema según la reivindicación 18, caracterizado porque las secuencias-patrones (1) comprenden unas secuencias-patrones de nivel 2 para las cuales son consideradas y ensayadas las combinaciones de dos operaciones de nivel 1 o de tres operaciones de nivel 0.

20. Sistema según cualquiera de las reivindicaciones 16 a 19, caracterizado porque los parámetros estáticos (2) comprenden en particular el número de iteraciones del bucle para cada secuencia-patrón, el paso de acceso a las tablas y el tipo de operando, el tipo de instrucciones utilizadas, las estrategias de precarga, las estrategias de ordenamiento de las instrucciones y de las iteraciones.

21. Sistema según cualquiera de las reivindicaciones 16 a 20, caracterizado porque los parámetros dinámicos (7) comprenden en particular la localización de los operandos de tablas en los diferentes niveles de la jerarquía memoria, la posición relativa de las direcciones de partida de las tablas y el histórico de las conexiones.

22. Sistema según cualquiera de las reivindicaciones 6, 8 y 9, caracterizado porque la base de los núcleos optimizados (16) comprende unas secuencias de código fuente de tipo bucle que corresponden a unos fragmentos de código real y útil y organizados en niveles por orden de complejidad creciente.

23. Sistema según cualquiera de las reivindicaciones 1 a 12, caracterizado porque la plataforma material previamente definida (90) comprende por lo menos un procesador del tipo Itanium.

24. Sistema según cualquiera de las reivindicaciones 1 a 12, caracterizado porque la plataforma material previamente definida (90) comprende por lo menos un procesador del tipo Power o Power PC.

25. Sistema según cualquiera de las reivindicaciones 13 a 15 y según la reivindicación 23, caracterizado porque las reglas de optimización (9) comprenden por lo menos algunas de las reglas siguientes:

(a)

minimizar el número de Escrituras en caso de malos resultados de las Escrituras con respecto a las Lecturas,

(b)

importancia de la utilización de los pares de carga en coma flotante,

(c)

ajustar el grado de desarrollo en función de la complejidad del cuerpo de bucle,

(d)

utilizar las latencias operativas de las operaciones aritméticas,

(e)

aplicar unas técnicas de enmascarado para los vectores cortos,

(f)

utilizar unos sufijos de localidad para los acceso de memoria (Lectura, Escritura, Precarga),

(g)

definir las distancias de Precarga,

(h)

efectuar una vectorización de grado 4 para evitar una parte de los conflictos de bancos L2

(i)

tener en cuenta múltiples variantes para evitar otra parte de los conflictos de bancos L2 y los conflictos en la fila de espera de las Lecturas/Escrituras,

(j)

tener en cuenta las ganancias de resultados ligadas a las diferentes optimizaciones,

(k)

utilizar unas cadenas de conexión que minimizan las malas predicciones (vectores cortos),

(l)

fusionar los accesos memorias (reagrupación de los píxeles)

(m)

vectorizar los tratamientos sobre píxeles.

\vskip1.000000\baselineskip

26. Sistema según cualquiera de las reivindicaciones 13 a 15 y según la reivindicación 24, caracterizado porque las reglas de optimización (9) comprenden por lo menos algunas de las reglas siguientes:

(a)

reordenar las Lecturas para reagrupar los errores de cache,

(b)

utilizar la precarga únicamente sobre las Escrituras,

(c)

ajustar el grado de desarrollo en función de la complejidad del cuerpo de bucle,

(d)

utilizar las latencias operativas de las operaciones aritméticas,

(e)

utilizar unos sufijos de localidad para los accesos memoria (Lectura, Escritura, Precarga),

(f)

definir las distancias de Precarga,

(g)

tener en cuenta múltiples variantes para evitar los conflictos en las filas de espera Lectura/Escritura,

(h)

tener en cuenta las ganancias de rendimientos ligadas a las diferentes optimizaciones.