Poems

A Nova Geração do YAP Prolog: Um ambiente experimental de compilação just-in-time baseada em traços de execução

Description
UNIVERSIDADE ESTADUAL DE MARINGÁ CENTRO DE TECNOLOGIA DEPARTAMENTO DE INFORMÁTICA PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO GEORGE SOUZA OLIVEIRA A Nova Geração do YAP Prolog: Um ambiente experimental
Categories
Published
of 140
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
UNIVERSIDADE ESTADUAL DE MARINGÁ CENTRO DE TECNOLOGIA DEPARTAMENTO DE INFORMÁTICA PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO GEORGE SOUZA OLIVEIRA A Nova Geração do YAP Prolog: Um ambiente experimental de compilação just-in-time baseada em traços de execução Maringá 2013 GEORGE SOUZA OLIVEIRA A Nova Geração do YAP Prolog: Um ambiente experimental de compilação just-in-time baseada em traços de execução Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação do Departamento de Informática, Centro de Tecnologia da Universidade Estadual de Maringá, como requisito parcial para obtenção do título de Mestre em Ciência da Computação. Orientador: Prof. Dr. Anderson Faustino da Silva Maringá 2013 Dados Internacionais de Catalogação na Publicação (CIP) (Biblioteca Central - UEM, Maringá, PR, Brasil) O48n Oliveira, George Souza A nova geração do YAP Prolog : um ambiente experimental de compilação just-in-time baseada em traços de execução / George Souza Oliveira. -- Maringá, f. : figs., tabs. Orientador: Prof. Dr. Anderson Faustino da Silva. Dissertação (mestrado) - Universidade Estadual de Maringá, Centro de Tecnologia, Departamento de Informática, Programa de Pós-Graduação em Ciência da Computação, YAP Prolog (Interpretador de linguagens lógicas). 2. Compilação just-in-time (Computação). 3. Compilação baseada em traços de execução (Computação). I. Silva, Anderson Faustino da, orient. II. Universidade Estadual de Maringá. Centro de Tecnologia. Departamento de Informática. Programa de Pós-Graduação em Ciência da Computação. III. Título. CDD 21.ed GVS Ao meu Deus, Jesus Cristo, Criador dos céus e da terra. AGRADECIMENTOS Primeiramente, gostaria de agradecer a todos da minha família, que apesar de terem sido privados da minha presença, me compreenderam, dedicaram carinho e atenção a todo o momento. Agradeço também ao meu orientador, Anderson Faustino da Silva, pela dedicação e exemplo prestados. Anderson, você é um brilhante orientador e amigo de verdade. Agradeço também, a todos os meus amigos, àqueles presentes pelos momentos de descontração e trocas de idéias, e àqueles distantes que sempre estiveram torcendo pelo meu sucesso. Dentre eles, agradeço especialmente ao Juliano, que por ser mais experimente, foi capaz de me dar idéias brilhantes para que eu pudesse utilizar no meu trabalho. Por fim, e não menos importante, agradeço à Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES) pelo apoio financeiro concedido a este trabalho. A Nova Geração do YAP Prolog: Um ambiente experimental de compilação just-in-time baseada em traços de execução RESUMO As pesquisas voltadas para a implementação eficiente da linguagem Java apostaram no uso de um sistema de compilação just-in-time para otimizar código em tempo de execução. Além disso, pesquisas mais recentes têm demonstrado que, ao invés de compilar unidades de código limitados a um único escopo, compilar os traços de execução mais frequentes acarreta um melhor ganho de desempenho. Baseado neste contexto, este trabalho descreve uma nova arquitetura para o sistema YAP Prolog, que é capaz de construir traços de execução e então, gerar código nativo para eles. Os resultados obtidos indicaram que a compilação just-in-time baseada nessa estratégia alcança um ganho de desempenho de 25,2%, variando entre 1,006% e 134,4%. Palavras-chave: YAP Prolog. Compilação just-in-time. Compilação baseada em traços de execução. New Generation of YAP Prolog: An experimental environment of trace-based just-in-time compilation ABSTRACT Researches directed to efficient implementation of Java relied on a just-in-time (JIT) system to optimize code at runtime. Furthermore, recent researches has shown that compiling common execution traces, instead of code units limited to a single scope, leads to a better performance gain. Based on this context, this work introduces a new architecture for the YAP Prolog, which is able to build traces and then generate native code from them. The results indicated trace-based JIT compilation reaches 25.2% of performance gain, ranging from 1.006% to 134.4%. Keywords: YAP Prolog. Just-in-time compilation. Trace-based compilation. LISTA DE FIGURAS Figura Arquitetura genérica de um sistema JIT Figura Organização da Memória na WAM Figura Estrutura interna da versão atual do sistema YAP (adaptado de Costa et al. (2012)) Figura Estrutura interna do sistema proposto Figura Fases do Compilador JIT Figura Exemplo de um traço gerado para uma cláusula com 3 instruções. 89 Figura Trecho de um traço com característica linear em (b) que representa o fluxo de execução (marcado em vermelho) em (a) Figura Trecho do traço representado na Figura - 4.5, após o fluxo de execução (marcado em vermelho) mudar após o teste condicional. 91 Figura Trecho de um traço em uma instrução YAAM que causa uma exceção para coleta de lixo. Isso implica que, em código nativo, as condições para esse tipo de exceção são as mesmas para código interpretado. O efeito é que, mesmo executando código nativo, a coleta de lixo sempre ocorre em código interpretado Figura Trecho do traço representado na Figura - 4.6, mas usando um bloco elementar para suportar instruções condicionais onde um dos blocos de destino causam backtrack Figura Exemplo de traço que contém uma instrução de indexação Figura Traço da Figura (b) após ser reconstruído e recompilado Figura Organização do sistema com suporte aos novos predicados Figura Impacto do Interpretador Instrumentado no ambiente de execução. Quanto menor a barra, maior a desaceleração Figura Aceleração/desaceleração dos programas teste no modo smart JIT(com e sem recompilação) sobre o modo somente interpretar. Valores menores que 1 indicam desaceleração Figura Percentuais do fluxo de execução nos componentes ativos no modo smart JIT Figura Aceleração/desaceleração dos programas teste no modo compilaç~ao contínua(com e sem recompilação) sobre o modo somente interpretar. Valores menores que 1 indicam desaceleração Figura Percentuais do fluxo de execução nos componentes ativos no modo compilaç~ao contínua Figura Aceleração/desaceleração dos programas teste no modo somente compilar sobre o modo somente interpretar. Valores menores que 1 indicam desaceleração Figura Percentuais do fluxo de execução nos componentes ativos no modo somente compilar. O gráfico está representado em escala logaritmica para destacar os tempos do Compilador JIT Figura Tempos de construção, compilação e execução dos traços na configuração smart JIT sem recompilação. T i representa o traço de número i. Valores em vermelho indicam traços não úteis Figura Tempos de construção, compilação e execução dos traços na configuração smart JIT com recompilação. T i representa o traço de número i. Valores em vermelho indicam traços não úteis Figura Taxas do fluxo de execução na manutenção das áreas de memória do sistema sobre o tempo total de execução de cada programa avaliado. Os valores são praticamente os mesmos em todos os modos de execução Figura Arquitetura proposta para trabalhos futuros LISTA DE TABELAS Tabela Comparação entre os sistemas JIT Tabela Programas-teste habitualmente utilizados pela comunidade científica de Prolog Tabela Programas-teste do benchmark shootout SUMÁRIO 1 Introdução 12 2 Compilação JIT Histórico Arquitetura de Sistemas com Compilação JIT Compilador Base e Compilador Otimizador Offline Profiler Online Profiler Monitor Gerente de Código Gerente de Compilação Repositório de Código Motor de Execução Princípios de Compilação JIT Manutenção dos Sistemas de Compilação e Execução Acionamento do Sistema de Compilação Seleção de Unidades de Compilação Geração de Versões Especializadas Implementação e Desempenho Sistemas Considerações Finais Prolog Controle da Linguagem Máquina Abstrata de Warren O Estado Interno da WAM e a Organização da Memória Conjunto de Instruções Melhorando o Desempenho da WAM Especializar a Unificação Otimizar Seleção de Cláusulas Gerar Código Nativo Utilizar Análise Global Utilizar Memoização Implementações Prolog Considerações Finais 4 O Ambiente Experimental de Compilação Just-in-Time Baseada em Traços de Execução Yet Another Prolog Estruturas de Dados e Organização da Memória Principais Diferenças com a WAM Estrutura das Cláusulas Organização do Sistema A Nova Geração do YAP Os Módulos da Nova Geração do YAP Motor de Execução Compilador JIT Gerente de Código Construtor de Traços Módulo de Recompilação Os Predicados Suportados na Nova Geração do YAP Predicados para Análises de Código Predicados para Transformações de Código Predicados para Geração de Código Predicados para Configuração Geral Predicados para Depuração Predicados para Coleta de Perfil de Execução Considerações Finais Avaliação Experimental Metodologia Impacto do Interpretador Instrumentado Desempenho dos Diferentes Modos de Execução O Desempenho de Smart JIT O Desempenho de Compilação Contínua O Desempenho de Somente Compilar Desempenho na Construção dos Traços Considerações Finais Conclusões e Trabalhos Futuros Motivações A Nova Geração do YAP 6.3 Resultados Alcançados Trabalhos Futuros Gerente de Código Compilador JIT Motor de Execução Offline Profiler Online Profiler Cache Considerações Finais REFERÊNCIAS 144 12 1 Introdução Linguagens que implementam programação lógica (Colmerauer, 1990; Henderson e Somogyi, 2002) possuem uma clara correspondência à lógica matemática e expressam a computação sem descrever o seu fluxo de controle. Em outras palavras, a descrição do programa é baseada em o que realizar, em vez de como realizar, ao contrário do que ocorre na programação imperativa (Sebesta, 2009). Isso é baseado na premissa de que qualquer algoritmo consiste de uma especificação lógica (a descrição das propriedades do resultado esperado) e um controle (a forma de executar esta especificação). De posse da especificação lógica, o próprio sistema é encarregado de prover o controle e encontrar a solução do problema (caso esta exista). Esse estilo de programação torna as linguagens lógicas tanto mais fáceis quanto mais difíceis se comparadas a outras estratégias de programação. Fácil porque a forma de encontrar a solução fica a cargo do ambiente de execução da própria linguagem e difícil porque esquemas de programação mais comuns não são suportados. A primeira linguagem de programação lógica surgiu no início dos anos 70 (Kowalski, 1988) como um provador de teoremas especializado, que eventualmente evoluiu para uma linguagem mais poderosa chamada Prolog (Colmerauer, 1990; Sterling e Shapiro, 1994). Esta última descreve a programação como um subconjunto de lógica de primeira ordem, as cláusulas de Horn (Horn, 1951), sendo portanto, uma linguagem declarativa (Lloyd, 1994). Essa característica torna Prolog uma linguagem de programação simples e eficiente na implementação dos conceitos de unificação e busca. A implementação de linguagens declarativas, de Prolog em particular, é uma tarefa difícil, visto que as máquinas tradicionais são sequenciais, uma característica não existente neste tipo de linguagem (pelo menos não de forma explícita). Além disso, como o 13 controle de execução fica a cargo da própria linguagem, o desenvolvedor se vê obrigado a considerá-lo e projetá-lo. Isso significa que as estratégias empregadas para criação de compiladores ou interpretadores para linguagens imperativas não são suficientes para a criação de compiladores ou interpretadores para linguagens declarativas, e portanto, lógicas. Uma alternativa para implementação de Prolog surgiu com a Máquina Abstrata de Warren (WAM) (Aït-Kaci, 1991; Warren, 1983), um modelo que permite compilar código Prolog para uma representação intermediária sequencial. Com esse modelo, um ambiente Prolog pode ser implementado tanto por hardware (Van Roy e Despain, 1992) quanto por software (Carlsson e Mildner, 2012; Costa et al., 2012; Diaz et al., 2012; Hermenegildo et al., 2012; Swift e Warren, 2012; Taylor, 1996; Van Roy, 1990; Wielemaker et al., 2012). Na verdade, a implementação por hardware consiste apenas de um conceito teórico, visto que é uma implementação difícil devido à alta granularidade das instruções WAM. Além disso, o desenvolvimento do hardware ao longo dos anos e o aumento do número de instruções com baixa granularidade para as arquiteturas atuais mostrou que o uso desse tipo de abordagem é inviável. Mesmo que um hardware especializado fosse criado, seria difícil, mesmo para os mais adeptos, adquirir uma máquina que só executasse Prolog. Por fim, a dificuldade em obter bom desempenho em hardware tradicional somado ao custo de implementação de hardware exclusivo justificam que ambientes Prolog tenham sido essencialmente projetados por software. Por outro lado, a implementação por software acarreta um alto overhead proveniente da interpretação de código WAM para código de máquina equivalente. Além disso, a alta granularidade das instruções WAM impedem a aplicação de diversas otimizações de código(muchnick, 1997). Uma alternativa é implementar Prolog para a geração de código nativo. Os primeiros sistemas a utilizarem essa alternativa foram Aquarius (Van Roy, 1990) e Parma (Taylor, 1996), que utilizavam análise global (Warren et al., 1988) para especializar a unificação e otimizar a seleção de cláusulas. Embora essas implementações tenham demonstrado que a execução de Prolog é comparável à das linguagens imperativas em alguns casos, as mesmas foram abandonadas por serem muito difíceis de manter. Dessa forma, os sistemas Prolog mais comuns são atualmente implementados como interpretadores (Carlsson e Mildner, 2012; Costa et al., 2012; Diaz et al., 2012; Hermenegildo et al., 2012; Swift e Warren, 2012; Tarau, 1991; Wielemaker et al., 2012). Como alternativa, alguns deles também oferecem execução de código nativo, como GNU-Prolog (Diaz et al., 2012), SICStus Prolog (Carlsson e Mildner, 2012), CIAO (Hermenegildo et al., 2012) BinProlog (Tarau, 1991) e XSB Prolog (Swift e Warren, 2012). Dentre as implementações existentes, YAPc (Silva e Costa, 2007) se destaca por 14 empregar uma abordagem diferente, que consiste em gerar código em tempo de execução para as regiões executadas com mais frequência. YAPc foi projetado para ser utilizado com o interpretador YAP (Costa et al., 2012), a fim de torná-lo um ambiente de modo misto de execução. Um sistema deste porte possui a vantagem de utilizar informações coletadas em tempo de execução para especializar o código nativo a ser gerado, sem a necessidade de implementar um analisador global (Warren et al., 1988). Em síntese, o princípio básico de YAPc é o mesmo dos compiladores just-in-time (JIT) desenvolvidos para sistemas Java, como Jikes (Arnold et al., 2000; Burke et al., 1999), JUDO(Cierniak et al., 2000) e Sun Hotspot(Kotzmann et al., 2008; Paleczny et al., 2001): em primeiro lugar, cada unidade de código (que no contexto de YAPc, se trata de uma cláusula) é instrumentada com contadores e então interpretada. Cada contador é incrementado na medida em que as unidades associadas são invocadas. Durante este processo, um profiler coleta informações sobre o programa em execução e, ao atingir um certo limite de invocação, a unidade é selecionada para compilação. Por fim, o compilador JIT é acionado a fim de gerar código especializado baseado nas informações anteriormente coletadas. Silva e Costa(2007) mostraram que YAP obtém ganho de desempenho na execução de programas com longas entradas quando o YAPc é acionado. Apesar de suas vantagens, YAPc possui algumas restrições de implementação que o impede de gerar resultados melhores, principalmente para programas com pouco tempo de execução (Silva, 2006), que são: 1. Uma quantidade limitada de otimizações (transformações) de código. Geralmente, a escolha das otimizações para determinadas unidades de código influenciam o desempenho geral do sistema e o número reduzido delas limita a variedade de escolhas. 2. Um alocador de registradores baseado em um algoritmo de coloração de grafo (Muchnick, 1997), que é capaz de gerar bons resultados, mas que possui um custo que não compensa ser aplicado em ambientes de compilação JIT. O fato é que compiladores JIT compilam código em tempo de execução e, por esta razão, devem ser leves e eficientes de tal modo que gerem código aceitável no menor tempo possível. 3. O compilador mostrou ser apenas uma prova de conceito. Embora o trabalho com o YAPc tenha demonstrado ser uma boa alternativa de implementação de Prolog, este não se tornou uma implementação disponibilizada nas versões do YAP. 15 Em vista disso, o principal objetivo deste trabalho é projetar e implementar uma nova arquitetura de compilação JIT para o YAP, mais precisamente, um módulo de compilação JIT baseada em traços de execução. O esquema de compilação baseada em traços de execução difere da estratégia adotada em YAPc, bem como da maioria dos sistemas JIT atuais, por não se limitar ao escopo de uma unidade de código tradicional, como um método, função ou cláusula. Um objetivo secundário deste trabalho é fornecer ao YAP a capacidade de ser um ambiente experimental de compilação JIT para Prolog. Esta última proposta pode ser concretizada pelo desenvolvimento de predicados nativos, que auxiliam na configuração do sistema quanto a forma que o mesmo executa, compila e gerencia o código. Em específico, tais predicados podem: (1) modificar os modos de execução de código, (2) aplicar transformações de código na variedade e ordem que o usuário desejar, (3) habilitar análises de código, tais como o tempo gasto para compilar e executar código nativo e (4) realizar tarefas de depuração quando determinada condição for satisfeita. Este trabalho pretende conciliar os objetivos estabelecidos com o padrão de funcionamento que tem sido considerado desde a implementação do YAPc, que consiste em preservar a ilusão de que o sistema executa diretamente o programa na forma que o programador escreveu, invocando o ambiente de compilação e otimizando código de forma transparente. Esse padrão traz alguns pontos a serem considerados (Silva, 2006): 1. O programador deve ser livre para editar qualquer cláusula do sistema; 2. O programador deve ser capaz de entender a execução do programa e qualquer erro que ocorra no programa em termos do código fonte e construções da linguagem; e 3. O programador deve se isolar do fato dos programas serem compilados. Portanto, a proposta deste trabalho busca alcançar dois resultados finais: 1. Tornar Prolog mais próximo das linguagens tradicionais, como C e Java, ou que, no mínimo, a arquitetura proposta seja capaz de executar código mais rapidamente que a versão atual do sistema. 2. Flexibilidade dos parâmetros e novos modos de execução, para que o usuário realize diversos experimentos; Os resultados obtidos na avaliação deste trabalho mostraram ganho de desempenho para a maioria dos programas, que variou de 1,006% a 134,4%, com uma média de 25,2% sobre a versão atual do sistema. Esses valores foram obtidos a partir da execução 16 do sistema em diversas configurações diferentes, com o uso de predicados que modificam os parâmetros e modos de execução. Isso mostra, portanto, que os resultados buscados neste trabalho foram alcançados. Além disso, os resultados obtidos apontaram diversos trabalhos futuros, com o objetivo de diminuir custos e aperfeiçoar os traços construídos para cada programa. A fim de apresentar os conceitos iniciais, a nova arquitetura, resultados e trabalhos futuros, esta dissertação está organizada da seguinte forma: O Capítulo 2 contém a teoria relacionada à compilação just-in-time, seus conceitos, histórico e princípios, além de exemplos de alguns sistemas. O Capítulo 3 contém os fundamentos de Prolog, com o foco na WAM e suas formas de implementação. O Capítulo 4 apresenta a arquitetura do novo sistema como uma extensão da arquitetura atual, apresentada por Costa et al. (2012). O Capítulo 5 apresenta os resultados obtidos e, por fim, o Capítulo 6 apresenta as conclusões e trabalhos futuros. 17 2 Compilação J
Search
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks