PT1704476E - Sistema de geração automática de códigos optimizados - Google Patents

Description

ΕΡ 1 704 476/PT

DESCRIÇÃO "Sistema de geração automática de códigos optimizados" O presente invento tem por objecto um sistema de geração automática de códigos optimizados operacionais numa plataforma material predefinida que compreende, pelo menos, um processador, para um domínio de aplicação predeterminado, a partir de códigos fonte submetidos pelos utilizadores (estando estes utilizadores compreendidos aqui em sentido lato e incluindo os utilizadores finais, mas também programadores de aplicações ou programadores do sistema).

Desde a origem da informática, que tem sido realizado muito trabalho relativamente aos compiladores. O princípio de um compilador é de analisar um código fonte descrito numa linguagem de alto nível e de gerar o seu equivalente em código binário para a máquina alvo. Em geral, este processo é efectuado de forma estática antes da execução. Também existem interpretadores que realizam tecnologias de compilação dinâmica, os quais têm permitido ultrapassar este último constrangimento ao proporcionar a possibilidade de gerar o código no momento da execução. O compilador é um elemento da cadeia de preparação dos programas. O resultado da compilação pode ser concluído pelos procedimentos já compilados e gerados (compilação separada ou bibliotecas), ligados de forma estática ao carregamento ou dinamicamente à execução.

Os compiladores estão, em geral, organizados em três fases: 1. Geração de código intermédio: a partir do código fonte, o compilador reconhece os idiomas e gera uma forma abstracta independente da linguagem fonte, habitualmente denominada linguagem intermédia. Esta linguagem é independente da máquina alvo. 2. Optimização de alto nível: nesta fase é reagrupado um certo número de optimizações, as quais são em geral 2

ΕΡ 1 704 476/PT independentes da arquitectura alvo: propagação de constantes, redução de força, expressões comuns.... Estas optimizações correspondem em geral às métricas simples: diminuição do número de instruções, simplificação da estrutura do código. 3. Geração de código e optimização de baixo nível; nesta fase são realizadas todas as operações e optimizações próprias da máquina alvo: a geração e a selecção de instruções, a alocação de registos, o ordenamento das instruções, etc.

As qualidades de um compilador não estão apenas ligadas à arquitectura alvo (desempenho do código gerado) mas também à linguagem fonte (mais ou menos fácil de compilar) e às suas características no que respeita ao suporte lógico (robustez, riqueza de opções, velocidade de execução, etc.)

Salvo o caso particular da compilação dinâmica, o conjunto de três fases acima deve ser realizado antes da execução e num tempo razoável, o que do mesmo modo limita a complexidade dos algoritmos de optimização, os quais podem ser implementados num compilador.

Uma grande parte da pesquisa nos compiladores está, por isso, em primeiro lugar ligada à escolha e à definição da linguagem fonte de alto nível.

As evoluções dos compiladores estão igualmente ligadas às evoluções da arquitectura dos processadores e, mais precisamente, aos modelos de desempenho que descrevem o comportamento destas arquitecturas. Como em qualquer problema de optimização, uma dificuldade importante é a definição de uma função de custo, que seja representativa dos tempos de execução.

Os primeiros conjuntos de instruções tinham comportamentos muito simples: os tempos de execução de uma sequência de instruções eram obtidos de forma tão simples como a soma dos tempos de execução de cada uma das instruções da sequência. Em consequência, o processo de optimização era muito simples e a principal estratégia de optimização 3 ΕΡ 1 704 476/ΡΤ consiste em reduzir o número e a complexidade das instruções geradas. A aparição dos primeiros conjuntos de instruções CISC ("Complex Instruction Set Computer") modificou ligeiramente os dados, na medida em que ficaram disponíveis instruções muito complexas. O problema da optimização tornou-se então essencialmente um problema de reconhecimento de idiomas ("pattern matching"). Nesta mesma categoria, pode-se incluir os conjuntos das instruções vectoriais e os vectorizadores, os quais eram capazes reconhecer os ciclos, os quais contribuíam directamente para uma geração de código vectorial. Em caso de necessidade, o código fonte podia também ser transformado para fazer aparecer as estruturas de código vectorial.

Uma ruptura nas estratégias de optimização ocorreu com a introdução de encadeamento, evolução arquitectural, a qual corta o tratamento das instruções em várias operações executadas de forma sequencial, à imagem de uma cadeia de montagem numa fábrica. Esta técnica, a qual permite sobrepor a execução de várias instruções num dado instante melhora sensivelmente o desempenho dos sistemas, mas introduz desvios importantes em caso de "ruptura" do encadeamento, a seguir, por exemplo, à presença da instrução de salto. Deste modo a mesma põe fim à previsibilidade do comportamento de um dado código. Uma outra ruptura importante vem da utilização de memórias hierárquicas: a optimização devia então apoiar-se na avaliação fina de uma métrica muito particular: a localização (espacial e temporal). No entanto, a interacção entre o processador e o sistema memória sendo simples, o processo de optimização devia ter por objectivo principal minimizar o número de "miss" (perdas) porque cada perda adiciona uma penalidade ao tempo de execução. Deve ser notado, no entanto, que a minimização do número de "miss" era delicada e, no essencial, realizável para as estruturas de código simples tipo ciclo. Esta dificuldade de estimar de forma estática propriedades de localização conduzia à utilização de métodos de optimização por gestão de perfis: o código era executado uma primeira vez para determinar precisamente as propriedades de localização (construção de um perfil). Este perfil era então utilizado num segundo passo para efectuar as 4

ΕΡ 1 704 476/PT optimizações ligadas à exploração da localização. A este nível de complexidade de arquitectura, era já muito difícil definir de forma simples uma estratégia eficaz de optimização. Mais exactamente, era extremamente delicado saber combinar diferentes optimizações e mesmo nos casos muito simples: não existia um mecanismo que permitisse modelar/tomar em consideração de forma eficaz os desempenhos. É neste quadro que foram desenvolvidas as técnicas de compilação iterativa que combinam execução e optimização de forma a gerar o melhor código possível. Mais precisamente, a compilação iterativa consiste em realizar um ciclo de "transformação de código-medida de desempenho (estático ou dinâmico)". Trata-se essencialmente de técnicas que permitem explorar o espaço de transformações de código com menor custo para apenas manter as soluções que deram os melhores resultados. O custo muito elevado em tempos de cálculo e de concretizar estes métodos iterativos limitou o seu campo de aplicação à optimização de bibliotecas.

As arquitecturas RISC ("Reduced Instruction Set Computer"), as quais utilizam um conjunto de instruções simples e uniformes (por oposição à CISC) surgiram em meados dos anos 80. As primeiras gerações de processadores RISC eram muito limitadas em termos de funcionalidade e qualidade do código gerado (em particular o ordenamento das instruções) tornaram-se então num factor chave na corrida ao desempenho. De forma muito semelhante, as arquitecturas VLIW ("Very Long Instruction Word") utilizavam técnicas de compilação completamente semelhantes para explorar o melhor possível o material. Estas duas arquitecturas RISC e VLIW tinham sempre um modelo de desempenho simples determinista na medida em que globalmente as instruções se executavam na mesma ordem que o código do programa gerado, o que simplificava consideravelmente o comportamento destas arquitecturas e, por esse motivo, o processo de optimização. No entanto, muito rapidamente estas arquitecturas generalizaram a utilização do encadeamento e das memórias intermediárias para obterem os melhores desempenhos (mais precisamente, isto conduziu a uma melhoria dos desempenhos em média e em detrimento da previsibilidade). 5 ΕΡ 1 704 476/ΡΤ A aparição de arquitecturas super escalares (capazes de executar várias instruções por ciclo) e sobretudo os mecanismos de processamento fora de ordem ("Out of Order Processing") das instruções tornaram ainda mais difíceis os processos de optimização de desempenhos. Além disso, em simultâneo as memórias hierárquicas evoluíram rapidamente: o número de níveis aumentou e sobretudo os diversos mecanismos que permitiam gerar de forma mais ou menos explícita as diferentes memórias intermediárias (pré-carregamento, gestão de prioridade, ...) apareceram. O conjunto destes mecanismos tornou o comportamento de fracções de código mesmo as mais simples (ciclos com acesso a 2 ou 3 tabelas) extremamente difícil e por isso mesmo impossível de optimizar por se basearem em modelos simples de desempenho. Esta situação apenas se agrava com o crescente afastamento entre os desempenhos dos processadores e das memórias.

Globalmente, no decurso das últimas duas décadas, ao nível da arquitectura dos processos, a riqueza em termos de funcionalidades cresceu de forma considerável. Deste modo o número de registos aumentou de forma considerável: 8 registos passaram por norma nas arquitecturas CISC, para 32 registos nas arquitecturas RISC e mesmo a mais de 80 registos nas arquitecturas super escalares. Na primeira abordagem pode-se pensar que aumentar o número de registos vai simplificar a optimização. Na prática, a evolução das memórias tornou a utilização de registos ainda mais crucial e neste problema de alocação de registo, o custo dos algoritmos eficazes de alocação de registo aumentou consideravelmente devido à sua complexidade é exponencial em função do número de registos disponíveis.

Em resposta a estas evoluções recentes, a tecnologia dos compiladores evoluiu pouco: o número de optimizações realizadas aumentou certamente mas a capacidade de definir uma estratégia global de optimização não progrediu e até diminuiu.

Por fim, uma última tendência apareceu com a compilação "dinâmica". O princípio é simples e atractivo: a compilação dinâmica (ou ainda especialização na execução) consiste em efectuar optimizações de código no último instante, isto é na 6

ΕΡ 1 704 476/PT execução. Uma sequência de código é adaptada ("especializada") em função dos dados de entrada (contexto de execução) de um programa. Um mecanismo de execução "examina" o comportamento dos programas de acordo com a frequência de execução das sequências de instruções e decide ou não realizar as versões optimizadas para um contexto de execução preciso. Este tipo de mecanismo intrinsecamente dinâmico está limitado às técnicas de optimização e económicas em tempos de cálculo na sua realização devido às mesmas não penalizarem a execução dos códigos.

Recorda-se, por outro lado, que uma biblioteca é um conjunto de procedimentos, representativos de um dominio ou de uma porção desse dominio: os componentes de uma biblioteca devem de facto corresponder a estes procedimentos padrão frequentemente utilizados. O conceito de biblioteca é muito antigo, anterior à noção de compilador e é um dos grandes pilares do génio do suporte lógico (reutilização de componentes) . Em particular, Java é um dos exemplos de linguagens, as quais utilizam de forma muito sistemática a noção de biblioteca.

As bibliotecas podem corresponder a diferentes níveis de abstracção dos mais simples aos mais complicados: blas 1 ("Basic Linear Álgebra Subroutines Levei I") é um conjunto de operações muito simples baseado em vectores mas que permite exprimir um grande número de algoritmos clássicos de álgebra linear. No outro extremo, LINPACK (resp. EISPACK) está um conjunto completo de procedimentos que permitem a resolução de sistemas lineares (resp. o cálculo de vectores próprios e de valores próprios) . Um grande número de bibliotecas foi desenvolvido e largamente utilizado nos seguintes domínios particulares:

• Cálculo Científico: BLAS1, BLAS2, BLAS3, BLAST, SPARSE BLAS, LINPACK, LAPACK, BLACS, PVM, MPI, etc. • Processamento de sinal: FFTPACK, VSIPI, etc.

Gráfico: DirectX, OpenGL. 7

ΕΡ 1 704 476/PT Ο facto de, num dado domínio de aplicações, ter sido definido e identificado um certo número de bibliotecas traduz o facto de que este domínio pode ser "sintetizado". A maior defeito das bibliotecas é, no entanto, que a sua funcionalidade é muito limitada e que as mesmas induzem uma utilização manual (isto é, necessitam da inserção no código fonte de uma chamada explícita de procedimento).

As primeiras gerações de bibliotecas (que correspondiam a procedimentos simples e de pequena dimensão) foram, em geral, desenvolvidas à mão num integrador. Este é muitas vezes o caso em que o desempenho é o maior critério (sob reserva certamente de que os procedimentos se mantenham numa dimensão razoável).

Pelo contrário, de forma diferente da compilação, a qual é globalmente um processo "em linha" (os tempos de compilação devem manter-se moderados), a optimização de bibliotecas é, no essencial, um processo "fora de ligação" e pode utilizar métodos muito mais consumidores de tempo de cálculo. Deste modo, a compilação iterativa é uma excelente ferramenta de optimização para o desenvolvimento de bibliotecas, mas a qual pode apenas, infelizmente, ser utilizada para códigos simples tendo em conta o seu peso de utilização.

Na mesma ordem de ideias, a tecnologia tipo "Automatic Tuning Linear Álgebra Software" permite realizar uma parte da optimização (escolha de bons parâmetros tais como as dimensões dos blocos).

Infelizmente, esta técnica é de utilização muito restrita devido à mesma ser muito dependente do tipo de aplicação considerada (cálculo em matrizes densas, cálculos caracterizados por uma localização temporal muito forte). Uma outra técnica de geração e optimização de código é apresentada no documento "Generating Code for High-Level Operations through Code Composition" de James M. Stichnoth (Agosto de 1997, CMU-CS-97-165); esta técnica utiliza porções predefinidas de código (modelos de código), as quais contêm código alvo e comandos de compilação que especificam o modo como estas porções de código se devem compor. 8

ΕΡ 1 704 476/PT

As ferramentas de análise de desempenho existentes são muito variadas (em particular em função do objectivo procurado): • Testes de desempenho ("benchmarks"): trata-se de códigos mais ou menos representativos de um domínio de aplicação e os quais permitem comparar os desempenhos de diversas máquinas. • Simuladores: permitem apreender o comportamento de uma arquitectura ao nivel mais fino. Infelizmente são muito caros, dificeis de desenvolver, muito lentos e nem sempre fiáveis em relação ao processador alvo. • Modelos matemáticos: trata-se de colocar em equação o desempenho da máquina. Em geral a sua utilização é extremamente limitada e são úteis apenas para estudar diferentes variantes simples em torno de um mesmo código muito simples. • Ferramentas de controlo/gestão de perfis: estas ferramentas permitem recuperar (através de computadores de material especializado) diferentes informações relativas à execução de um programa: número de ciclos, número de perdas, etc.

Pode-se, por outro lado formular as seguintes observações:

Os testes de desempenho evoluem pouco e sobretudo tornaram-se o objecto de apostas comerciais muito importantes. Com frequência, a sua optimização obstinada pelos construtores falseia a comunicação e a validade dos resultados obtidos. - Simuladores: a exploração dos seus resultados (para a optimização de código) torna-se cada vez mais difícil na medida em que a arquitectura alvo se tornou muito complexa. - Modelos matemáticos: evoluíram pouco e com excepção da utilização local referida acima, não são 9

ΕΡ 1 704 476/PT utilizáveis. Uma das razões é que as boas ferramentas matemáticas de modelação pressupõem um comportamento "uniformemente médio", o que está longe de ser o caso prático. - Ferramentas de controlo/gestão de perfis: sofrem no essencial de três defeitos: dão uma informação global e não uma distribuição da actividade ao longo do tempo; não permitem correlacionar o código e o comportamento ao nível fino; enfim, a sua exploração (como no caso do simulador) é muito delicada, por causa, em particular, da complexidade da arquitectura alvo. O presente invento visa resolver os inconvenientes referidos e permitir, através de uma plataforma material predefinida que compreende, pelo menos, um processador, gerar automaticamente códigos optimizados operacionais nesta plataforma para um domínio de aplicação predeterminado a partir de códigos fonte submetidos pelos utilizadores.

De forma mais particular, o invento visa aumentar o desempenho de sistemas informáticos de forma independente da escolha da linguagem fonte e para os sistemas que realizam processadores cuja arquitectura pode apelar a instruções simples ou complexas e as quais podem compreender um número mais ou menos importante de registos, de unidades funcionais e de níveis de memória intermediária. O invento tem igualmente por objecto evitar as limitações da cobertura funcional das bibliotecas de programas especializados e visa criar um sistema de geração automática de códigos optimizados para um grande número de estruturas de código vizinhas, as quais podem apresentar diferentes níveis de complexidade.

Estes objectivos são conseguidos, de acordo com o invento, graças a um sistema de geração automático de códigos optimizados operacionais numa plataforma material predefinida que compreende, pelo menos, um processador, para um domínio de aplicação predeterminado a partir de códigos fonte submetidos pelos utilizadores, caracterizado por compreender 10 ΕΡ 1 704 476/ΡΤ meios de recepção de sequências de códigos simbólicos ditas sequências-padrão representativas do comportamento do dito processador em termos de desempenho, para o domínio da aplicação predeterminada; meios de recepção de parâmetros estáticos definidos a partir da plataforma material predefinida, do seu processador e das sequências-padrão; meios de recepção de parâmetros dinâmicos igualmente definidos a partir da plataforma material predefinida, do seu processador e das sequências-padrão; um dispositivo de análise para estabelecer regras de optimização a partir de testes e de medidas de desempenho estabelecidas a partir das sequências-padrão, parâmetros estáticos e parâmetros dinâmicos; um dispositivo de optimização e de geração de código que recebe por um lado as sequências-padrão e por outro as regras de optimização para examinar os códigos fonte dos utilizadores, detectar os ciclos que podem ser optimizados, decompor em núcleos, montar e injectar códigos para fornecer códigos optimizados; e meios para injectar de novo nas sequências-padrão informações fornecidas pelo dispositivo de geração e optimização de códigos e relativos aos núcleos.

De forma mais particular, o dispositivo de análise compreende um gerador de testes ligado por um lado aos meios de recepção de sequências-padrão e por outro lado aos meios de recepção de parâmetros estáticos para gerar automaticamente um número elevado de variantes de testes, os quais são transferidos pelos meios de transferência para serem armazenados numa base de variantes; um dispositivo de exercícios ligado por um lado aos meios de transferência para receber as variantes de testes armazenados na base de variantes e por outro lado meios de recepção de parâmetros dinâmicos para executar as variantes de testes numa gama de variação dos parâmetros dinâmicos e produzir resultados, os quais são transferidos para os meios de transferência para serem armazenados numa base de resultados; e um analisador ligado aos meios de transferência para receberem os resultados armazenados na base dos resultados, analisar os mesmos e deduzir as regras de optimização, as quais são transferidas pelos meios de transferência numa base de regras de optimização. 11

ΕΡ 1 704 476/PT

De forma vantajosa, o analisador compreende meios de filtragem num limite arbitrário do desempenho óptimo, de forma a considerar uma variante da base dos resultados como óptima no espaço dos parâmetros desde que a mesma satisfaça os critérios de filtragem.

De acordo com um modo de realização preferido, o analisador compreende além disso meios de modificação dos parâmetros estáticos e meios de modificação dos parâmetros dinâmicos. O dispositivo de optimização e geração de código compreende um dispositivo de geração de código optimizado e um optimizador, compreendendo este último um módulo de escolha estratégica ligado por um lado aos meios de recepção dos núcleos identificados nos códigos fonte de origem, por outro lado os meios de recepção de sequências-padrão e por outro lado os meios de recepção de regras de optimização para gerar, para cada núcleo correspondente a uma sequência-padrão testada uma pluralidade de versões em que cada uma é óptima para uma certa combinação de parâmetros, e um módulo de combinação e montagem ligado aos meios de recepção de regras de optimização, nos meios de recepção de informações emitidas do módulo de escolha de estratégia e nos meios de recepção da pluralidade de versões, para fornecer através dos meios de transferência as informações que compreendem as versões optimizadas correspondentes, a sua zona de utilização e se for o caso o teste a executar para determinar dinamicamente a versão mais adequada.

De acordo com um modo de concretização opcional preferido, o sistema compreende uma base de núcleos optimizados e o módulo de combinação e de montagem está ligado à base dos núcleos optimizados pelos meios de transferência para armazenar nesta base de núcleos optimizados as informações que compreendem as versões optimizadas, a sua zona de utilização e se for o caso, o teste a executar para determinar dinamicamente a versão mais adequada. O dispositivo de optimização e geração de código compreende um optimizador e um dispositivo de geração de 12 ΕΡ 1 704 476/ΡΤ código optimizado, compreendendo este último um módulo de detecção de ciclos que podem ser optimizados, o qual está ligado aos meios de recepção dos códigos fonte dos utilizadores, um módulo de decomposição em núcleos, um módulo de análise de caso, de montagem e injecção de código, o qual está ligado através dos meios de transferência ao optimizador para transmitir a identificação do núcleo detectado e meios de transferência para receber as informações que descrevem o núcleo optimizado correspondente, estando o módulo de análise de caso, de montagem e de injecção de código por outro lado ligado aos meios de fornecimento dos códigos optimizados. O módulo de análise de caso, de montagem e de injecção de código pode, por outro lado, estar ligado à base dos núcleos optimizados para receber as informações que descrevem um núcleo optimizado sem invocar o optimizador se o núcleo procurado já foi armazenado.

De acordo com uma característica vantajosa, o módulo de análise de caso, de montagem e de injecção de código compreende por outro lado meios para acrescentar às sequências-padrão os núcleos, os quais foram colocados em evidência neste módulo de análise de caso, de montagem e de injecção de código sem ter a identificação correspondente na base dos núcleos optimizados, nem nas sequências-padrão.

De acordo com um modo de concretização particular, o sistema compreende um compilador e um editor de ligações para receber um código fonte refeito emitido pelo dispositivo de optimização e geração do código e produzir um código binário optimizado adaptado à plataforma material. O sistema pode compreender meios para transferir o código fonte dos núcleos optimizados da base e núcleos optimizados para o compilador.

De acordo com outra variante de concretização, o sistema pode compreender um compilador e um módulo de instalação para instalar na plataforma material, uma biblioteca dinâmica que contém o conjunto das funcionalidades dos núcleos optimizados. 13 ΕΡ 1 704 476/ΡΤ Ο invento pode ser aplicado a diferentes dominios de aplicação e, em particular, ao cálculo cientifico, ao processamento de sinal e ao processamento gráfico.

De acordo com uma caracteristica particular, as sequências-padrão compreendem um conjunto de códigos tipo ciclo simples e genéricos especificados numa linguagem tipo fonte e organizados em níveis de forma hierárquica por ordem de complexidade crescente do código do corpo do ciclo.

Neste caso, as sequências-padrão compreendem sequências-padrão de nível 0 nas quais apenas uma operação elementar é testada e que corresponde a um corpo de ciclo constituído por uma única expressão aritmética representada por uma árvore de altura 0.

Em complemento, as sequências-padrão podem compreender sequências-padrão de nível 1 para as quais são consideradas e testadas as combinações de duas operações de nível 0, as operações das sequências-padrão de nível 1 que correspondem aos corpos de ciclos constituídos quer por uma única expressão aritmética, representada por uma árvore de altura 1, quer por duas expressões aritméticas, sendo cada uma representada por uma árvore de altura 0.

De acordo com um modo de concretização possível, as sequências-padrão compreendem por outro lado as sequências-padrão de nível 2 para as quais são consideradas e testadas as combinações de duas operações de nível 1 ou de três operações de nível 0.

Os parâmetros estáticos compreendem, em particular, o número de iterações do ciclo para cada sequência-padrão, o passo de acesso às tabelas e o tipo de operando, o tipo de instruções utilizadas, as estratégias de pré-carregamento, as estratégias de ordenamento das instruções e das iterações.

Os parâmetros dinâmicos compreendem, em particular, a localização das tabelas de operandos nos diferentes níveis da memória hierárquica, a posição relativa dos endereços de partida das tabelas e o histórico de saltos. 14

ΕΡ 1 704 476/PT

De forma vantajosa, a base dos núcleos optimizados compreende as sequências de código fonte tipo ciclo que correspondem aos fragmentos de código real e útil e organizados em níveis por ordem de complexidade crescente. A plataforma material predefinida pode compreender, por exemplo, pelo menos, um processador do tipo denominado ItaniumMR da sociedade INTEL ou, pelo menos, um processador tipo Power ou Power PC^ da sociedade IBM.

De acordo com um modo de concretização possível que pode ser aplicado de forma mais particular aos sistemas que compreendem um processador tipo ITANIUMmr, as regras de optimização compreendem, pelo menos, algumas das regras seguintes: a) minimizar o número de escritas em caso de mau desempenho das escritas em relação às leituras, b) importância da utilização de pares de carregamento em vírgula flutuante, c) ajustar o grau de desenvolvimento em função da complexidade do corpo do ciclo, d) utilizar as latências operacionais das operações aritméticas, e) aplicar técnicas de dissimulação para os vectores curtos, f) utilizar sufixos de localização para os acessos à memória (Leitura, Escrita, Pré-carregamento), g) definir as distâncias de pré-carregamento, h) efectuar uma vectorização de grau 4 para evitar uma parte dos conflitos de bancos L2, i) tomar em consideração as múltiplas variantes para evitar uma outra parte dos conflitos de bancos L2 e os conflitos da fila de espera de leituras/escritas, 15 ΕΡ 1 704 476/ΡΤ j) tomar em consideração os ganhos de desempenho ligados às diferentes optimizações, k) utilizar as cadeias de salto que minimizam as más previsões (vectores curtos), l) fundir os acessos a memórias (reagrupamento de pixéis), m) vectorizar os processamentos em pixéis.

De acordo com um outro modo de concretização possível que pode ser aplicado de forma mais particular aos sistemas que compreendem um processo tipo Power ou Power PC , as regras de optimização compreendem, pelo menos, algumas das regras seguintes: a) reordenar as leituras para reagrupar as faltas de memória intermediária, b) reutilizar o pré-carregamento apenas nas escritas, c) ajustar o grau de desenvolvimento em função da complexidade do corpo de ciclo, d) utilizar as latências operacionais das operações aritméticas, e) utilizar sufixos de localização para os acessos à memória (Leitura, Escrita, Pré-carregamento), f) definir as distâncias de pré-carregamento, g) tomar em consideração as múltiplas variantes para evitar os conflitos nas filas de espera de leitura/escrita, h) tomar em consideração os ganhos de desempenho ligados às diferentes optimizações. 16

ΕΡ 1 704 476/PT

Outras características e vantagens do invento surgirão da descrição seguinte de modos particulares de concretização, feita com referência aos desenhos em anexo, nos quais: - a FIG. 1 é um diagrama de blocos, que mostra o conjunto de módulos de um sistema de geração automática de códigos optimizados, de acordo com o invento, - a FIG. 2 é um diagrama de blocos, que mostra, de forma mais detalhada, a constituição de um módulo de análise de desempenhos, que pode ser realizado no sistema da FIG. 1, - a FIG. 3 é um diagrama de blocos, que mostra, de forma mais detalhada, a constituição de um módulo de optimização e de geração de código que pode ser realizado no sistema da FIG. 1, - a FIG. 4 é um diagrama de blocos, que mostra um primeiro exemplo de módulo de geração de código fonte refeito, associado aos meios de obtenção de código binário optimizado para a plataforma alvo considerada, e a FIG. 5 é um diagrama de blocos, que mostra um segundo exemplo de módulo de geração de código fonte refeito, associado aos meios de obtenção de código binário, optimizado para a plataforma alvo considerada.

Será feita, em primeiro lugar, referência à FIG. 1, a qual que mostra a montagem do sistema de geração automática de código optimizado para fornecer, através de uma saída 73 de um módulo 80 de optimização e de geração de código, os códigos optimizados operacionais numa plataforma material 90 predefinida que compreende, pelo menos, um processador 91. O sistema de geração de código optimizado está adaptado a um domínio de aplicação determinado e recebe, por uma entrada 71 do módulo 80, os códigos fonte 17, submetidos pelos utilizadores, o termo utilizadores deve ser entendido 17

ΕΡ 1 704 476/PT em sentido lato e inclui, em particular, os utilizadores finais, os programadores das aplicações ou os programadores de sistemas.

As sequências de código simbólicas ditas sequências-padrão 1, representativas do comportamento do processador 91 em termos de desempenho para o dominio da aplicação considerada, são aplicadas a uma entrada 52 do módulo 80 de optimização e de geração de código e a uma entrada 51 de um módulo de análise 10. A análise do efeito dos diversos parâmetros do ambiente e da interacção entre sequências-padrão permite situar as zonas de bom e de mau desempenho e de compreender as razões. As sequências-padrão não representam forçosamente sequências de código real gerado pelas linguagens de programação clássicas. Apenas um sub-conjunto de sequências-padrão testadas correspondem aos núcleos utilizados para a optimização do código de utilizador.

Um ciclo, que pode ser optimizado, e uma construção de programa codificam a representação algorítmica de uma operação mais ou menos complexa nas variáveis-vectores.

Um núcleo ou ciclo elementar constitui uma forma simples de ciclo optimizável. O módulo 80 do sistema de acordo com o invento permite gerar automaticamente um número de núcleos optimizados sensivelmente superior ao número de funções proporcionadas pelas bibliotecas especializadas matemáticas. Em geral, várias versões do mesmo núcleo podem ser geradas, sendo cada versão optimizada por uma certa combinação de parâmetros de ambiente. A fase de optimização num optimizador 12 (FIG. 3) consiste, deste modo, na geração automática de um conjunto ou biblioteca de núcleos optimizados para a plataforma alvo 90 que representa funcionalidades representativas do domínio da aplicação. A fase de optimização está associada a uma fase de geração de código num gerador de código 18 (FIG. 3), o qual examina o código fonte do programa utilizador para aí 18

ΕΡ 1 704 476/PT detectar os ciclos que podem ser optimizados afim de forçar a utilização de núcleos optimizados em vez do código que teria gerado o compilador padrão.

Estão previstos meios 74 para injectarem de novo as informações do módulo 80 nas sequências-padrão 1.

As fases de optimização e de geração de código são precedidas por uma fase de análise num módulo de análise 10, o qual serve para determinar, para a plataforma material alvo 90 e para o domínio da aplicação considerado, as regras de optimização a respeitar para se obter os desempenhos óptimos. Uma saida 57 do módulo de análise 10 permite a transferência das regras de optimização através de uma base 9 de regras de optimização, ela própria ligada, pelos meios de transferência 18, ao optimizador 12 do módulo 80.

Vai agora ser descrito, de forma mais particular, o módulo de análise 10 com referência à FIG. 2.

Os parâmetros estáticos 2 e os parâmetros dinâmicos 7, identificados em função da arquitectura do processador 91, e, de forma mais geral, do sistema, o que está na base da plataforma 90 alvo da optimização e, do mesmo modo, em função das sequências-padrão, são aplicados pelos meios 53, 54 no módulo de análise 10.

Os parâmetros estáticos 2 podem compreender, em particular, o número de iterações do ciclo para cada sequência-padrão, o passo de acesso às tabelas e o tipo de operando, o tipo de instruções utilizadas, as estratégias de pré-carregamento, as estratégias de ordenamento das instruções e das iterações.

Os parâmetros dinâmicos 7 podem compreender, em particular, a localização de tabelas de operandos nos diferentes níveis da memória hierárquica, a posição relativa dos endereços de partida das tabelas e o histórico dos saltos.

No módulo 10 de análise de desempenhos, um gerador de teste 3 exporta os dados relativos aos parâmetros estáticos 2 19 ΕΡ 1 704 476/ΡΤ e dinâmicos 7, os quais são fornecidos ao mesmo pelas entradas 51, 53 para gerar um número potencialmente muito elevado de variantes, as quais são transferidas pelos meios de transferência 61 através de uma base de dados das variantes 4.

Uma outra ferramenta automática 5 denominada dispositivo de exercícios recebe, pelos meios de transferência 62, os dados das variantes e a base das variantes 4, realiza os testes produzidos deste modo, executa os mesmos ao fazer variar na sua gama de variação os parâmetros dinâmicos 7 fornecidos pelos meios de transferência 55 e transfere, pelos meios de transferência 63, as medidas pertinentes através de uma outra base de dados 6 denominada base de resultados.

As medidas armazenadas na base de resultados 6 são elas próprias transferidas, pelos meios de transferência 64, através de um analisador 8, o qual, a partir da identificação das zonas de bom e mau desempenho em função da parametrização, permitem a formulação das regras de optimização 9, as quais são transferidas pelos meios de transferência 57 na base 9 de regras de optimização. O analisador 8 compreende igualmente meios 54 de modificação dos parâmetros estáticos 2 e meios 56 de modificação dos parâmetros dinâmicos, por exemplo, se tiver sido constatada uma fraca sensibilidade às variações de um dado parâmetro. O analisador 8 pode compreender meios de filtragem com um limite arbitrário do desempenho óptimo. Neste caso, uma variante da base dos resultados, os quais não correspondem aos desempenhos óptimos, pode contudo ser retida como óptima no espaço dos parâmetros, desde que a mesma satisfaça os critérios de filtragem.

Será agora descrito o módulo 80 de optimização e de geração de código com referência à FIG. 3. O dispositivo de optimização 12 compreende um módulo 13 de escolha de estratégia, ligado ao módulo 18 de geração de código pelos meios 92 de recepção de núcleos identificados 20 ΕΡ 1 704 476/ΡΤ nos códigos fonte de origem. O módulo 13 de escolha de estratégia está, também, ligado aos meios 52 de recepção de sequências-padrão 1 e aos meios 58 de recepção de regras de optimização 9. O módulo 13 de escolha de estratégia gera na sua saída 67, para cada núcleo correspondente a uma sequência-padrão testada, um conjunto 15 de n versões em que cada uma é óptima para uma certa combinação de parâmetros.

Um módulo 14 de combinação e montagem de versões está ligado aos meios 59 de recepção de regras de optimização 9, aos meios 66 de recepção de informações, emitidas pelo módulo de escolha de estratégia 13 e aos meios 68 de recepção da pluralidade 15 de versões 1 a η. O módulo 14 entrega através dos meios de transferência 93 informações que compreendem as versões optimizadas correspondentes, a sua zona de utilização e, se for o caso, o teste a executar para determinar dinamicamente a versão mais adaptada. 0 módulo 18 de geração de código optimizado compreende um módulo 20 de detecção de ciclos que podem ser optimizados, o qual está ligado aos meios 71 de recepção de códigos fonte 17 de utilizadores. A saída 75 do módulo 20 está ligada a um módulo 22 de decomposição em núcleos em que a saída 77 está ela própria ligada a um módulo 23 de análise de caso, de montagem e de injecção de código, o qual está ligado, através dos meios de transferência 92, ao optimizador 12 para transmitir a identificação do núcleo detectado. O módulo 23 recebe por outro lado, pelos meios de transferência 93, as informações que descrevem o núcleo optimizado correspondente. O módulo 23 está também ligado aos meios 73 de fornecimento de códigos optimizados 19.

De acordo com uma variante de concretização vantajosa, o módulo 80 de optimização e de geração de código compreende uma base de núcleos optimizados 16. O módulo de combinação e de montagem 14 está ligado à base de núcleos optimizados 14 pelos meios de transferência 79, para armazenar, nesta base de núcleos optimizados, as informações que compreendem as versões optimizadas, a sua zona de utilização e, se for o caso, o teste a executar para determinar dinamicamente a versão mais adaptada. De acordo com esta variante, o módulo 23 de análise de caso, de montagem e de injecção de código 21

ΕΡ 1 704 476/PT está também ligado à base 16 de núcleos optimizados pelos meios de transferência 72 para receber as informações que descrevem um núcleo optimizado, sem invocar o optimizador 12, se o núcleo procurado já tiver sido gravado nesta base 16.

Como se pode ver na FIG. 3, o módulo 23 de análise de caso, de montagem e de injecção de código compreende também meios 74 para acrescentar às sequências-padrão 1 núcleos, os quais tenham sido colocados em evidência no módulo 23 sem ter a identificação correspondente na base 16 dos núcleos optimizados, nem nas sequências-padrão. A FIG. 4 mostra um exemplo particular de concretização, para o qual não foi representado o optimizador 12, o qual permanece idêntico à variante da FIG. 3, de acordo com a qual existe uma base 16 dos núcleos optimizados.

Neste exemplo de concretização, o módulo 18 de geração de código produz uma saída 73 do módulo 23 de análise de caso, de montagem e de injecção de código, um código fonte refeito 19, o qual é de seguida processado pelas ferramentas clássicas de preparação de programa 81, 82 para a obtenção de código binário 83 optimizado para a plataforma alvo 90. A FIG. 4 representa um exemplo de concretização, o qual pode ser realizado de forma muito fácil. O código fonte de utilizador de origem 17 foi refeito no módulo 80 de optimização e de geração de código já descrito acima, de tal forma que os ciclos que podem ser optimizados foram substituídos pelos das chamadas aos sub-programas, tendo sido o código correspondente a estes sub-programas injectado no código fonte refeito 19 a partir da base dos núcleos optimizados 16. O código fonte 19 assim refeito contém então tudo o necessário para gerar um código binário optimizado 83 adaptado à plataforma material 90, por uma passagem numa cadeia clássica que compreende um compilador 81 e um editor de ligações 82.

De acordo com uma variante possível, o código fonte dos núcleos optimizados da base dos núcleos optimizados 16 pode ser utilizado directamente na etapa de compilação na qualidade de biblioteca fonte complementar. Isto é 22 ΕΡ 1 704 476/ΡΤ simbolizado na FIG. 4 pela seta a ponteado 85, a qual liga a base dos núcleos optimizados 16 ao compilador 81. Esta variante permite deste modo evitar a injecção directa deste código fonte dos núcleos optimizados no código fonte refeito e simplifica a etapa de geração no módulo 18. A FIG. 5 representa uma outra variante de concretização do exemplo de concretização da FIG. 4. A variante da FIG. 5 explora a possibilidade que oferecem certos sistemas de exploração de instalar as bibliotecas com a forma de códigos binários executáveis e acessíveis pelos programas, para edição de ligações dinâmicas no momento da sua execução.

No caso da variante da FIG. 5, deixa de ser necessário injectar o código a partir da base dos núcleos optimizados 16 para o código fonte refeito 19. Pelo contrário, uma biblioteca dinâmica que contém o conjunto de funcionalidades dos núcleos optimizados deve ser instalada na plataforma alvo 90 por intermédio de um compilador 181 e de um módulo de instalação 182. Pode-se utilizar apenas um compilador comum para os compiladores 81 e 181 da FIG. 5. Nesta variante da FIG. 5, a operação de instalação é necessária apenas uma vez para cada plataforma alvo, de forma que esta variante é mais económica em termos de processamento global do processo de optimização. A realização de um sistema de geração de código optimizado de acordo com o invento aplica-se particularmente bem aos três domínios que são o cálculo científico, o processamento de sinal e o processamento gráfico.

Com efeito, os códigos utilizados nestes três domínios apresentam várias características CARI a CAR4, as quais são importantes para esta realização. o CAR 1: As estruturas de tipo ciclo (ou "ninhos de ciclo") constituem as porções de código mais consumidoras de tempos de execução 23 ΕΡ 1 704 476/ΡΤ ο CAR 2: As estruturas de dados utilizadas são na maior parte tipo tabela multidimensional e são acedidas de acordo com motivos muito regulares (linhas, colunas, blocos, etc.) o CAR 3: Os ciclos (ou ninhos de ciclos) são em geral constituídos de iterações independentes e que podem ser utilizadas em paralelo o CAR 4: O corpo do ciclo é, em geral, constituído de uma sequência de expressões aritméticas e corresponde a um cálculo uniforme (ou quase uniforme) num grande volume de dados.

Naturalmente, se estes três dominios do cálculo cientifico, do processamento de sinal e do processamento gráfico possuírem pontos comuns, apresentam, deste modo, certas diferenças fortes. Deste modo, no domínio do processamento de sinal, os dados de tipo complexo constituem um tipo de dados extremamente importante, o que requer optimizações específicas enquanto que a importância deste tipo de dados é marginal nos dois outros domínios. O processamento gráfico é fortemente marcado pela utilização de um tipo de dados particular, os pixéis, e de uma aritmética especial. Para além de gráfica, a estruturação dos dados e dos algoritmos em relação a um ecrã bidimensional é fundamental.

As quatro características acima (CARI a CAR4) têm consequências muito fortes para a optimização de código e permitem o desenvolvimento de técnicas completamente específicas: o CAR 1 => as optimizações vão de facto se concentrar nas estruturas de tipo "ciclo", as quais apresentam duas vantagens principais: repetitividade (e previsibilidade) e capacidade de representação. o CAR 2 => os acessos às tabelas, os quais representam uma parte importante (até mesmo principal devido à utilização crescente das memórias intermediárias) dos 24 ΕΡ 1 704 476/ΡΤ tempos de execução vão poder facilmente ser analisados devido à sua regularidade. o CAR 3 => a independência das iterações num ciclo e nos ninhos de ciclos, vai permitir a utilização (a optimização) de percursos do espaço de iteração em função dos acessos às tabelas e de acordo com as caracteristicas próprias da arquitectura alvo. Pode-se salientar que o acesso a N elementos dados de uma tabela pode ser realizado de N! maneiras (ordens) diferentes. o CAR 4 => a estrutura simples dos corpos de ciclos em termos de expressões aritméticas vai permitir-nos utilizar uma abordagem sistemática e hierárquica apoiada na representação sob a forma de árvores de uma expressão aritmética. A fase de análise permanece uma fase essencialmente experimental no fim da qual é necessário: • ter determinado os pontos fortes e os pontos fracos da arquitectura, • saber correlacionar desempenho e estrutura de código, • ter identificado as boas estratégias de optimização, as que podem ser função de diferentes parâmetros ligados ao código.

Como já foi indicado, o ponto de partida é um conjunto de códigos "de tipo fonte" simples mas genéricos denominados "sequências-padrão". Estes códigos têm uma estrutura de tipo ciclo, o termo "tipo fonte" que indica que as operações são especificas de alto nivel e não de nivel de código máquina.

Estes códigos estão organizados em niveis de forma hierárquica por ordem de complexidade crescente do código do corpo de ciclo da seguinte forma: 25 ΕΡ 1 704 476/ΡΤ • SEQUÊNCIA-PADRÃO NÍVEL 0: a este nível, apenas uma operação elementar é testada, isto significa que o corpo de ciclo compreende apenas uma operação: leitura de um elemento de tabela, escrita de um elemento de tabela, adição flutuante, etc. Estas operações correspondem aos corpos de ciclo constituídos por uma única expressão aritmética representada por uma árvore de altura 0. • SEQUÊNCIA-PADRÃO NÍVEL 1: a este nível, são consideradas e testadas combinações de duas operações de nivel 0: leitura e escrita de uma tabela, leitura de duas tabelas diferentes, leitura e adição numa tabela etc. Estas operações correspondem ao corpo de ciclos constituídos quer por uma única expressão aritmética representada por uma árvore de altura 1, quer por duas expressões aritméticas, sendo cada uma representada por uma árvore de altura 0. • SEQUÊNCIA-PADRÃO NÍVEL 2: a este nível, as combinações de duas operações de nivel 1 ou de três operações de nivel 0 são consideradas e testadas: leitura de três tabelas diferentes, leitura e adição de duas tabelas componente a componente e escrita do resultado numa terceira tabela, etc. • SEQUÊNCIA-PADRÃO NÍVEL K: o nível K pode ser facilmente definido por recorrência a partir dos níveis anteriores.

Todas as sequências-padrão de nível 0 correspondem aos códigos, os quais são "artificiais", isto é não traduzem os ciclos "reais".

Esta organização em níveis de complexidade crescente é também utilizada na fase de optimização. O conjunto de sequências-padrão assim definido é infinito. 26

ΕΡ 1 704 476/PT

Estas sequências-padrão utilizam duas classes de parâmetros diferentes: • Parâmetros estáticos: estes parâmetros são definidos de forma estática (isto é antes da execução e de forma independente da execução). Estes parâmetros estáticos são eles próprios subdivididos em duas grandes subclasses: parâmetros estáticos de alto nivel (número de iterações do ciclo, sem acesso às tabelas, tipo de operando,...) parâmetros estáticos de baixo nivel (utilização de instruções especificas, de ordenamento das instruções, etc.) • Parâmetros dinâmicos: estes parâmetros são definidos no momento da execução do ciclo. Os mesmos compreendem, por exemplo: a localização das tabelas de operandos na memória hierárquica, posição relativa dos endereços de partida das tabelas,...

Estas duas classes de parâmetros são exploradas de forma muito diferente: os parâmetros estáticos serão utilizados para gerar os diferentes códigos teste em combinação com as variantes/optimizações descritas acima, enquanto que os parâmetros dinâmicos são exclusivamente utilizados no momento da execução no banco de teste.

Os parâmetros estáticos de alto nível são relativamente limitados e correspondem, no essencial, aos parâmetros clássicos de um ciclo e de tabelas expressas numa linguagem de alto nivel (Fortran ou C, por exemplo) sem qualquer especificidade proveniente do processador alvo.

Os parâmetros estáticos de baixo nível vão permitir ter em conta todas as especificidades ligadas ao processador (arquitectura) e ao ordenamento das instruções (gerador de código objecto). Com efeito, as sequências-padrão são de facto abstracções de alto nível (definidas numa linguagem fonte, independentes da arquitectura do processador visado) e não integram qualquer optimização particular. Para testar os mesmos num dado processador, é necessário gerar e optimizar os códigos de montagem correspondentes. No momento desta geração, várias variantes (sequência de instruções 27

ΕΡ 1 704 476/PT integradas) vão ser geradas automaticamente. Todas as variantes associadas a uma mesma sequência-padrão são códigos semanticamente equivalentes à sequência-padrão de partida. São estas variantes, as quais vão ser executadas e medidas. Estas variantes correspondem de facto a diferentes técnicas de optimização de código (isto é, aos parâmetros estáticos de baixo nível). Estas optimizações podem ser definidas de forma abstracta sem referência à estrutura particular de uma sequência-padrão e constituem o essencial dos parâmetros estáticos de baixo nível.

Os parâmetros estáticos de baixo nível compreendem: • a utilização de instruções de montagem: uma mesma operação ao nível fonte pode ser realizada por diferentes sequências de instruções. Em particular, é necessário tratar aqui as diferentes estratégias possíveis para utilizar o pré-carregamento dos dados e das instruções. • a estrutura do corpo de ciclo: desenvolvimento (grau variável) do corpo de ciclo, • o ordenamento do corpo de ciclo: ordenamento das instruções do corpo de ciclo (distâncias de pré-carregamento, vectorização), reagrupamento de faltas de memória intermediária, processamento dos conflitos nas filas de espera), • o ordenamento das iterações: encadeamento lógico (profundidade variável)

No número de compiladores, os parâmetros estáticos de baixo nível, descritos acima, correspondem às opções de compilação, que permitem realizar de forma explícita a optimização visada. O papel do gerador de teste 3 é de gerar as diferentes variantes descritas acima, que correspondem, por um lado, aos parâmetros estáticos de alto nível (por exemplo, sem acesso 28

ΕΡ 1 704 476/PT às tabelas) e, por outro lado, aos parâmetros estáticos de baixo nível.

Deve ser salientado que, para as sequências-padrão de nível 1, o número total de variantes para gerar/analisar é extremamente elevado e cifra-se em vários milhões. Apesar disso, o processo de geração e de análise pode ser automatizado de forma muito simples.

Ao nível do dispositivo de exercícios 5 e do analisador 8, trata-se de testar os desempenhos das diferentes variantes e de seleccionar as melhores variantes/optimizações possíveis.

Esta fase implica a geração de um grande número de resultados armazenados na base de resultados 6. Os testes são efectuados de forma hierárquica e entrelaçados com as fases de análise: deste modo os primeiros testes são efectuados nas variantes das sequências-padrão de nível 0. No fim desta primeira campanha de testes, uma primeira triagem nas diferentes variantes pode ser efectuada em função dos resultados obtidos. Certas variantes podem assim ser imediatamente eliminadas e não serão consideradas para os níveis seguintes. isto permite limitar a explosão combinatória do número de testes a realizar. A fase de análise de resultados é à primeira vista suficientemente simples de efectuar, devido a ser utilizada apenas uma métrica (desempenho). De facto uma grande parte da complexidade do processo provém do facto de em geral, a escolha das melhores variantes depender muito fortemente dos parâmetros.

Uma primeira triagem pode ser realizada de forma muito simples ao calcular de acordo com as especificações da arquitectura, os desempenhos óptimos para cada uma das sequências-padrão. Pelo contrário, as dificuldades podem aparecer rapidamente, ligadas às iterações complexas entre arquitectura e códigos (aí contido para os códigos também tão simples como as sequências-padrão de nível 0 e 1) : isto traduz-se pelas figuras complicadas que descrevem as variações do desempenho em função dos parâmetros. Estes 29 ΕΡ 1 704 476/ΡΤ comportamentos complexos podem ser de início analisados com a utilização de algoritmos de processamento de imagem depois sintetizados ao qualificar uma dada variante para uma certa área de parâmetros. Deste modo, a fase de análise não gera simplesmente uma lista que indica para cada sequência-padrão a melhor (e única) variante/técnica de optimização: de facto para cada sequência-padrão, é determinada uma lista de áreas de parâmetros e, para cada uma destas áreas, é indicada a melhor variante/técnica de optimização: é uma informação deste tipo, a qual será denominada "regra de optimização". 0 conjunto das sequências-padrão testadas é um subconjunto muito restrito do conjunto das sequências-padrão. Este conjunto, o qual é utilizado de seguida pelas optimizações é denominado "conjunto das sequência-padrão de referência".

Na prática, é muito importante fixar um objectivo "razoável" de optimização: procurar deste modo a todo o custo o óptimo pode gerar um número muito elevado de variantes enquanto que aliviando a restrição do óptimo e aceitando desempenhos numa vizinhança de 5 a 10% do óptimo, uma variante apenas pode ser utilizada para uma grande área de parâmetros. Para tal procede-se a uma filtragem, por exemplo, num limiar de 90% do desempenho óptimo.

Na prática, é suficiente testar e analisar apenas os níveis 0, 1 e 2 das sequências-padrão para desbloquear e validar as principais técnicas de optimização. O conjunto de referência das sequências-padrão não conterá em geral sequências de nível superior a 3.

Com efeito, o volume de testes torna-se rapidamente muito elevado, em particular, acima do nível 2. O conjunto de testes presta-se de forma ideal à paralelização: os testes podem ser executados em paralelo em 100 ou 1000 máquinas. Esta propriedade de paralelização é extremamente útil e permite efectuar explorações sistemáticas e em tempos aceitáveis. 30

ΕΡ 1 704 476/PT

Esta fase é completamente automatizável e os procedimentos de verificação de qualidade e de coerência de resultados podem ser também automatizáveis. A intervenção humana apenas é necessária para recolher os erros/anomalias decorrentes da análise dos resultados produzidos automaticamente pelos procedimentos de verificação de qualidade e de coerência.

No fim da fase de análise, o objectivo é dispor de um grande número de códigos simples ditos "núcleos" optimizados especificamente para a arquitectura alvo, este processo de optimização baseia-se de forma essencial nas técnicas de optimização resultantes no fim da fase de análise.

De forma estrita, os "núcleos" são sequências de código fonte tipo ciclo e constituem um sub-conjunto do caso geral das sequências-padrão. Ao contrário destas últimas, os mesmos correspondem a fragmentos de código real e útil. Como as sequências-padrão, os mesmos são organizados em niveis por ordem de complexidade crescente. A geração/optimização destes núcleos desenrola-se de acordo com as quatro fases abaixo: o Correlação com uma ou várias sequências-padrão de referência: para os núcleos mais simples, existe uma correspondência directa entre núcleos e sequências-padrão, para os núcleos mais complexos, o núcleo será decomposto em várias sequências-padrão de referência. Esta correlação/decomposição é efectuada ao nivel fonte em função das caracteristicas do corpo de ciclo do núcleo: número de tabelas, sem acesso às tabelas, etc. o Geração de código/ordenamento de instruções/optimização de instruções: trata-se de utilizar as técnicas de optimização detectadas no momento da fase de análise (em função das sequências-padrão correspondentes) e de aplicar as mesmas directamente à geração/optimização de código para os núcleos. Para um mesmo núcleo, várias versões 31

ΕΡ 1 704 476/PT possíveis poderão ser geradas e em função dos parâmetros. o Alocações de registo: bom número de técnicas de optimização utilizadas aumentam de forma sensível a pressão nos registos disponíveis. Neste caso, é conveniente ajustar a alocação do conjunto de registos disponíveis. o Experimentação/Validação: o núcleo gerado e optimizado é testado com a utilização do banco de teste da fase de análise. No fim desta fase, é construído um modelo simples de desempenhos do núcleo.

Em relação às optimizações clássicas utilizadas num compilador, as optimizações utilizadas aqui são muito diferentes: em primeiro lugar as mesmas são obtidas directamente de um processo detalhado de avaliação de desempenhos (efectuado no momento da fase de análise) de seguida as mesmas são muito mais complexas e com melhor desempenho (em particular para a alocação de registos) devido às mesmas serem executadas fora de ligação sem "restrição" de tempos. A utilização das sequências-padrão de referência e das regras de geração permitem ter em conta por um lado todas as características finas da arquitectura (características operacionais medidas e não teóricas) e por outro lado as diferentes versões que devem ser seleccionadas em função dos parâmetros.

No fim desta fase, foi construída uma base de dados 16 de núcleos optimizados, que contém não apenas os códigos gerados mas também as informações relativas aos desempenhos e isto em função dos diferentes parâmetros. Cada um destes núcleos é de seguida testado de acordo com o procedimento utilizado para as sequências-padrão.

Na prática, a base 16 dos núcleos optimizados compreende de forma sistemática e exaustiva todos os núcleos de níveis 1, 2, 3, 4 e 5. O custo em termos de volume de cálculo da 32

ΕΡ 1 704 476/PT construção desta base de dados é importante mas como para a fase de análise de desempenhos, a mesma pode-se paralelizar de forma muito eficaz. A optimização do código utilizador desenrola-se em três fases: o Detecção dos núcleos que podem ser optimizados (módulo 20): trata-se de reconhecer no código fonte os ciclos que podem ser decomposto em núcleos. Esta fase utiliza técnicas muito próximas daquelas dos paralelizadores/vectorizadores automáticos. Se for necessário, o código fonte é reestruturado para fazer aparecer o ciclo sob a forma mais favorável à optimização. o Análise do ciclo que pode ser optimizado, decomposição em núcleos (módulo 22): com suporte nas técnicas de emparelhamento de configuração e de decomposição próximas das utilizadas para a optimização de núcleos, o ciclo é decomposto numa sequência de núcleos. o Reunião e injecção de código (módulo 23) : os diferentes núcleos utilizados para a decomposição são reunidos e injectados de novo no código fonte. O procedimento de decomposição é, em geral, parametrizado em função de características do ciclo fonte de origem.

As optimizações propostas podem ser integradas o seja por um pré-processador numa cadeia de compilação existente e isto de maneira transparente significa sem que seja necessário ter acesso ao código do compilador, o seja directamente num compilador, isto necessitando, certamente, de modificações no código do compilador. 33 ΕΡ 1 704 476/ΡΤ

Como já foi indicado acima com referência à FIG. 3, no fim desta fase de análise, está disponível um certo número de regras de optimização: estas regras são função da sequência-padrão e da área de parâmetro. Em vez de passar pela etapa intermédia dos núcleos, uma variante possível é correlacionar directamente o ciclo que pode ser optimizado com as sequências-padrão e aplicar directamente as regras de optimização ao ciclo que pode ser optimizado sem passar pelo armazenamento de núcleos numa base 16 dos núcleos optimizados.

Esta variante é mais simples que a passagem para os núcleos e a mesma permite uma utilização mais flexível das regras de optimização. Pelo contrário, pelo facto da mesma ser realizada essencialmente em linha, o número de variantes exploradas será necessariamente mais restrito e por isso os desempenhos obtidos serão à priori um pouco inferiores.

No fim da fase de optimização, o sistema gerou formas optimizadas para um certo número de ciclos "que podem ser optimizados", os quais à priori não estavam directamente disponíveis na base dos núcleos devido aos mesmos necessitarem de uma decomposição. Estas formas optimizadas podem ser armazenadas na base 16 dos núcleos optimizados e reutilizadas de seguida. Deste modo, a base de dados 16 dos núcleos é enriquecida automaticamente para esta forma de aprendizagem.

Lisboa, 2009-07-14

Claims (24)

1. ΕΡ 1 704 476/PT 1/7 REIVINDICAÇÕES 1 - Sistema de geração automática de códigos optimizados (19) operacionais numa plataforma material predefinida (90), que compreende, pelo menos, um processador (91), para um domínio de aplicação predeterminado a partir de códigos fonte (17) submetidos pelos utilizadores, caracterizado por compreender meios (51, 52) de recepção de sequências de códigos simbólicas ditas sequências-padrão (1), representativas do comportamento do dito processador (91) em termos de desempenhos, para o domínio de aplicação predeterminado; meios (53) de recepção de parâmetros estáticos (2) definidos a partir da plataforma material predefinida (90) do seu processador (91) e das sequências-padrão (1); meios (55) de recepção de parâmetros dinâmicos (7) igualmente definidos a partir da plataforma material predefinida (90) do seu processador (91) e das sequências-padrão (1); um dispositivo de análise (10) para estabelecer regras de optimização (9) a partir de testes e de medidas de desempenho estabelecidas a partir de sequências-padrão (1) dos parâmetros estáticos (2) e dos parâmetros dinâmicos (7); um dispositivo (80) de optimização e geração de código que recebe por um lado as sequências-padrão (1) e por outro lado as regras de optimização (9) para examinar os códigos fonte (17) dos utilizadores, detectar os ciclos optimizáveis, decompor em núcleos, montar e injectar códigos para fornecer os códigos optimizados (19); e meios (74) para voltar a injectar nas sequências-padrão (1) as informações emitidas do dispositivo (80) de geração e optimização de códigos e relativas aos núcleos.
2. 2 - Sistema de acordo com a reivindicação 1, caracterizado por o dispositivo de análise (10) compreender um gerador de testes (3), ligado, por um lado, aos meios (51) de recepção de sequências-padrão e, por outro lado, aos meios (53) de recepção de parâmetros estáticos para gerar automaticamente um número elevado de variantes de testes, os quais são transferidos pelos meios de transferência (61) para serem armazenados numa base de variantes (4); um dispositivo de exercícios (5), ligado, por um lado, aos meios de transferência (62) para receberem as variantes de testes, armazenadas na base das variantes (4), e, por outro lado, aos ΕΡ 1 704 476/PT 2/7 meios (55) de recepção de parâmetros dinâmicos para executarem as variantes de testes numa gama de variação dos parâmetros dinâmicos (7) e produzir resultados, os quais são transferidos pelos meios de transferência (63), para serem armazenados numa base de resultados (6); e um analisador (8), ligado aos meios de transferência (64) para receber os resultados armazenados na base de resultados (6), analisar os mesmos e deduzir as regras de optimização, as quais são transferidas pelos meios de transferência (57) numa base de regras de optimização (9).
3. 3 - Sistema de acordo com a reivindicação 2, caracterizado por o analisador (8) compreender meios de filtragem com um limite arbitrário do desempenho óptimo, de forma a considerar uma variante da base de resultados como óptima no espaço de parâmetros desde que a mesma satisfaça os critérios de filtragem.
4. 4 - Sistema de acordo com a reivindicação 2 ou com a reivindicação 3, caracterizado por o analisador (8) compreender também meios (54) de modificação dos parâmetros estáticos (2) e meios (56) de modificação dos parâmetros dinâmicos (7).
5. 5 - Sistema de acordo com qualquer uma das reivindicações 1 a 4, caracterizado por o dispositivo (80) de optimização e geração de código compreender um dispositivo (18) de geração de código optimizado e um optimizador (12), compreendendo este último um módulo de escolha de estratégia (13) ligado, por um lado, aos meios (92) de recepção de núcleos identificados nos códigos fonte de origem e, por outro lado, aos meios (52) de recepção de sequências-padrão (1) e, por outro lado, a meios (58) de recepção de regras de optimização (9) para gerar, para cada núcleo, correspondente a uma sequência-padrão testada, uma pluralidade de versões (15) em que cada uma é óptima para uma certa combinação de parâmetros, e um módulo de combinação e de montagem (14) ligado aos meios (59) de recepção de regras de optimização (9), a meios (66) de recepção de informações emitidas pelo módulo de escolha de estratégia (13) e a meios (68) de recepção da pluralidade de versões (15), para fornecer através de meios de transferência (93) informações que ΕΡ 1 704 476/ΡΤ 3/7 compreendem as versões optimizadas correspondentes à sua zona de utilização e se for o caso, ao teste a executar para determinar dinamicamente a versão mais adequada.
6. 6 - Sistema de acordo com a reivindicação 5, caracterizado por compreender uma base de núcleos optimizados (16) e por o módulo de combinação e de montagem (14) estar ligado à base de núcleos optimizados (16) pelos meios de transferência (79). para armazenar nesta base de núcleos optimizados as informações que compreendem as versões optimizadas, a sua zona de utilização e, se for o caso, o teste a executar para determinar dinamicamente a versão mais adequada.
7. 7 - Sistema de acordo com qualquer uma das reivindicações 1 a 6, caracterizado por o dispositivo (80) de optimização e geração de código compreender um optimizador (12) e um dispositivo (18) de geração de código optimizado, compreendendo este último um módulo (20) de detecção de ciclos optimizáveis, o qual está ligado aos meios (71) de recepção de códigos fonte (17) de utilizadores, um módulo (22) de decomposição em núcleos, um módulo (23) de análise de caso, de montagem e de injecção de código, o qual está ligado através de meios de transferência (92) ao optimizador (12) para transmitir a identificação do núcleo detectado e meios de transferência (93) para receber as informações que descrevem o núcleo optimizado correspondente, estando o módulo (23) de análise de caso, de montagem e de injecção de código também ligado aos meios (73) de fornecimento dos códigos optimizados.
8. 8 - Sistema de acordo com as reivindicações 6 e 7, caracterizado por o módulo (23) de análise de caso, de montagem e de injecção de código estar também ligado à base (16) dos núcleos optimizados para receber as informações que descrevem um núcleo optimizado sem invocar o optimizador (12) se o núcleo pesquisado já tiver sido armazenado.
9. 9 - Sistema de acordo com a reivindicação 8, caracterizado por o módulo (23) de análise de caso, de montagem e de injecção de código compreender também os meios (74) para acrescentar às sequências-padrão (1) os núcleos, os ΕΡ 1 704 476/PT 4/7 quais foram colocados em evidência neste módulo (23) de análise de caso, de montagem e de injecção de código sem ter a identificação correspondente na base (16) dos núcleos optimizados, nem nas sequências-padrão.
10. 10 - Sistema de acordo com qualquer uma das reivindicações 6, 8 e 9, caracterizado por o mesmo compreender um compilador (81) e um editor de ligações (82) para receber um código fonte refeito (19), emitido pelo dispositivo (80) de optimização e geração do código e produzir um código binário optimizado (83) adaptado à plataforma material (90).
11. 11 - Sistema de acordo com a reivindicação 10, caracterizado por compreender meios (85) para transferir o código fonte dos núcleos optimizados da base dos núcleos optimizados (16) para o compilador (81).
12. 12 - Sistema de acordo com a reivindicação 10, caracterizado por compreender um compilador (181) e um módulo de instalação (182) para instalar na plataforma material (90) uma biblioteca dinâmica, que contém o conjunto de funcionalidades dos núcleos optimizados.
13. 13 - Sistema de acordo com qualquer uma das reivindicações 1 a 12, caracterizado por o dominio da aplicação predeterminado ser o cálculo cientifico.
14. 14 - Sistema de acordo com qualquer uma das reivindicações 1 a 12, caracterizado por o dominio de aplicação predeterminado ser o processamento de sinal.
15. 15 - Sistema de acordo com qualquer uma das reivindicações 1 a 12, caracterizado por o dominio da aplicação predeterminado ser o processamento gráfico.
16. 16 - Sistema de acordo com qualquer uma das reivindicações 1 a 15, caracterizado por as sequências-padrão (1) compreenderem um conjunto de códigos tipo ciclo simples e genéricos específicos numa linguagem tipo fonte e organizados em niveis de forma hierárquica por ordem de complexidade crescente do código do corpo do ciclo. ΕΡ 1 704 476/PT 5/7
17. 17 - Sistema de acordo com a reivindicação 16, caracterizado por as sequências-padrão (1) compreenderem as sequências-padrão de nivel 0, nas quais apenas uma operação elementar é testada e corresponde a um corpo de ciclo constituído por uma única expressão aritmética, representada por uma árvore de altura 0.
18. 18 - Sistema de acordo com a reivindicação 17, caracterizado por as sequências-padrão compreenderem sequências-padrão de nivel 1, para as quais são consideradas e testadas as combinações de duas ou mais operações de nível 0, correspondendo as operações de sequências-padrão de nível 1 aos corpos de ciclos, constituídos quer por uma única expressão aritmética representada por uma árvore de altura 1, quer por duas expressões aritméticas, sendo cada uma representada por uma árvore de altura 0.
19. 19 - Sistema de acordo com a reivindicação 18, caracterizado por as sequências-padrão (1) compreenderem sequências-padrão de nivel 2, para as quais são consideradas e testadas as combinações de duas operações de nível 1 ou de três operações de nível 0. 0 - Sistema de acordo com qualquer uma das reivindicações 16 a 19, caracterizado por os parâmetros estáticos (2) compreenderem, em particular, o número de iterações do ciclo para cada sequência-padrão, o passo de acesso às tabelas e o tipo de operando, o tipo de instruções utilizadas, as estratégias de pré-carregamento, as estratégias de ordenamento das instruções e das iterações.
20. 21 - Sistema de acordo com qualquer uma das reivindicações 16 a 20, caracterizado por os parâmetros dinâmicos (7) compreenderem, em particular, a localização das tabelas de operandos nos diferentes níveis da memória hierárquica, a posição relativa dos endereços de partida das tabelas e o histórico dos saltos.
21. 22 - Sistema de acordo com qualquer uma das reivindicações 6, 8 e 9, caracterizado por a base dos núcleos optimizados (16) compreender as sequências de código fonte ΕΡ 1 704 476/PT 6/7 tipo ciclo que correspondem aos fragmentos de código real e útil e organizadas por ordem de complexidade crescente. de acordo com qualquer uma das a 12, caracterizado por a plataforma um
22. 23 - Sistema reivindicações 1 material predefinida (90) processador tipo Itanium. compreender, pelo menos, uma das plataforma menos, um
23. 24 - Sistema de acordo com qualquer reivindicações 1 a 12, caracterizado por a material predefinida (90) compreender, pelo processador tipo Power ou Power PC.
24. 25 - Sistema de acordo com qualquer uma das reivindicações 13 a 15 e de acordo com a reivindicação 23, caracterizado por as regras de optimização (9) compreenderem, pelo menos, algumas das seguintes regras: (a) minimizar o número de escritas no caso de mau desempenho das escritas em relação às leituras, (b) importância da utilização de pares de carregamento em virgula flutuante, (c) ajustar o grau de desenvolvimento em função da complexidade do corpo de ciclo, (d) utilizar as latências operacionais das operaçoes aritméticas, (e) aplicar técnicas de dissimulação para os vectores curtos, (f) utilizar sufixos de localização para os acessos à memória (Leitura, Escrita, Pré-carregamento), (g) definir as distâncias de pré-carregamento, (h) efectuar uma vectorização de grau 4 para evitar uma parte dos conflitos de bancos L2, ΕΡ 1 704 476/ΡΤ 7/7 (i) tomar em consideração as múltiplas variantes para evitar uma outra parte dos conflitos de bancos L2 e os conflitos na fila de espera de leituras/escritas, (j) tomar em consideração os ganhos de desempenho ligados às diferentes optimizações, (k) utilizar as cadeias de salto que minimizam as más previsões (vectores curtos), (1) fundir os acessos a memórias (reagrupamento de pixéis), (m) vectorizar os processamentos em pixéis. 26 - - Sistema de acordo com qualquer uma das reivindicações 13 a 15 e de acordo com a reivindicação 24, caracterizado por as regras de optimização (9) compreenderem, pelo menos, algumas das seguintes regras: (a) reordenar as leituras para reagrupar as faltas de memória intermediária, (b) utilizar o pré-carregamento apenas nas escritas, (c) ajustar o grau de desenvolvimento em função da complexidade do corpo de ciclo, (d) utilizar as latências operacionais das operações aritméticas, (e) utilizar sufixos de localização para os acessos à memória (Leitura, Escrita, Pré-carregamento), (f) definir as distâncias de pré-carregamento, (g) tomar em consideração as múltiplas variantes para evitar os conflitos nas filas de espera de leitura/escrita, (h) tomar em consideração os ganhos de desempenho ligados às diferentes optimizações. Lisboa, 2009-07-14