Análises e Otimizações no LLVM

Resultados Experimentais

Marcio Machado Pereira - RA 780681

21 de dezembro de 2011

Resumo

O objetivo deste relatório foi o de fornecer uma visão geral das análises e otimizações que o LLVM1

oferece para a melhoria do desempenho das aplicações. Além disso, a metodologia aqui empregada pode

ser vista como um passo inicial para uma sistematização na seleção das diversas análises e otimizações

oferecidas pelo LLVM, bem como determinar a sequencia adequada para melhorar o desempenho de um

determinado tipo de aplicação.

1 Introdução

As otimizações em compiladores modernos alcançaram um alto nível de so�sticação. Embora possam serobtidas melhorias signi�cativas em muitos programas, o potencial de degradação de desempenho nos padrõesde determinado programa é conhecido por desenvolvedores de compiladores e muitos usuários. Aplicar asotimizações do compilador a um determinado programa pode ter um impacto signi�cativo sobre o desem-penho do mesmo. Devido à interação não-linear de otimizações do compilador, no entanto, determinar amelhor con�guração não é trivial. Diversas técnicas que buscam o espaço de opções do compilador paraencontrar boas soluções tem sido propostas, mas tais abordagens costumam ser caras. O estado da arte édeixar os usuários lidarem com este problema através de opções do compilador. A presença de opções docompilador re�ete a incapacidade dos otimizadores de hoje em fazer as melhores escolhas em tempo de com-pilação. A indisponibilidade de dados do programa de entrada e o conhecimento insu�ciente da arquiteturaalvo pode limitar severamente a precisão de desempenho. Assim, a determinação da melhor combinação deanálises e otimizações do compilador para um determinado programa continua a ser uma meta não trivial.

Compiladores de hoje têm evoluído ao ponto em que eles apresentam para o usuário um grande número deopções. Por exemplo, o LLVM inclui mais de 100 opções de otimização, além de agrupar um subconjuntodelas e oferecer em três níveis de otimização, O1, O2 e O3. Isto criou a necessidade de se desenvolveruma metodologia que possa identi�car e apresentar de maneira sistemática o comportamento de programassubmetidos a um determinado conjunto de otimizações.

Este relatório cientí�co avaliou o impacto de um conjunto pré-estabelecido de análises e otimizações decódigo do compilador LLVM em um conjunto de aplicações do SPEC CPU2006. A metodologia empregadapode ser vista como um passo inicial na busca de uma sistematização para se determinar o subconjunto deanálises e otimizações mais adequado para cada tipo de aplicação. Note que a escolha deste subconjunto nãoé tarefa simples. Em um determinado programa, geralmente há trechos de código cujo desempenho é críticoe trechos de código que são menos críticos. Fazer com que as partes críticas possam executar o mais rápidopossível envolve não somente a escolha de um subconjunto de análises e otimizações bem como determinara sequencia ideal em que as mesmas devam ser aplicadas para que este processo resulte em melhorias no

1O LLVM - Low Level Virtual Machine - é uma infraestrutura de compilação escrita em C++ projetada para otimizaçõesem tempo de compilação, ligação e execução de programas escritos em uma variedade de linguagens.

1

desempenho do programa. Os esforços de otimização podem modi�car ou eliminar códigos fora do caminhocrítico e portanto, não alcançar o resultado desejado. Veremos que a falta de uma metodologia adequada,além de time consuming, pode frustar nossas expectativas, resultando em uma versão de programa menose�ciente do que quando se adota simplesmente as otimizações padrões O1, O2 ou O3 disponibilizados peloLLVM.

2 Metodologia

O LLVM possui diversos tipos de otimizações que podem ser aplicados ao código, incluindo os grupos deotimizações padrões O1, O2 e O3. Neste experimento, primeiro avaliamos os 3 grupos padrões de compilaçãoe os comparamos, com base nas métricas citadas em 2.1, com o código sem otimizações produzido pelo LLVM.Em seguida, tomando como base o grupo de otimizações que compõem o padrão O3, aplicamos uma sériede modi�cações para avaliar primeiro, o impacto das diversas alias analysis descritas em 2.2 e, por �m, acontribuição que algumas otimizações especí�cas, descritas em 2.2, exercem dentro do grupo O3.

2.1 Métricas

Três métricas foram utilizadas para se realizar as avaliações:

• tempo gasto pelos passos de otimização durante o processo de compilação

• tamanho do código gerado (text size)

• desempenho do código gerado. Para tanto, uma amostra de dez ( n = 10 ) execuções para cadaaplicação foi utilizada. A partir desta amostra estimou-se os parametros µ (média) e σ (variança):

X̄ =1

n

n∑i=1

Xi, S2 =

∑ni=1 (Xi − X̄)

2

n− 1

que produziram para a amostra selecionada as estimativas pontuais. Uma maneira de expressar aprecisão da estimação é estabelecer limites que com certa probabilidade incluem o verdadeiro valor doparâmetro. Em nossos experimentos, construímos então um intervalo de con�ança de 95%, i.e., umintervalo no qual estamos 95% con�antes da cobertura do verdadeiro valor do parâmetro. O intervalode con�ança para a média é dado por:

ICµ,95% = [X̄ ± t S√n

]

onde o valor de t é obtido recorrendo-se a uma tabela da distribuição normal.

2.2 Otimizações & Análises

Padrões O1, O2 e O3 : Os padrões O1, O2 e O3 são composttos por uma série de passos de otimização,inclusive com repetições, com o objetivo de alcançar o melhor desempenho em aplicações de propósitogeral. O grupo O3 apresenta duas otimizações a mais em relação ao grupo O2. São elas, argpromotion(promove 'por referência' argumentos para escalar) e globaldce (eliminação global de código morto). Emrelação ao padrão O1, O2 e O3 apresentam os seguintes passos de otimização: loop-unroll (desenrolarde laços), gvn (numeração de valores globais) seguido de memdep (análise de dependência de memória)

2

e constmerge (fusão de constantes globais duplicadas). As otimizações do O3 são apresentadas abaixo,ressaltando em amarelo as diferenças para o padrão O2 e em azul as diferenças de O3 e O2 para opadrão O1. Detalhes sobre cada otimização dos padrões citados podem ser encontradas em [2].

Pass Arguments: -no-aa -tbaa -basicaa -simplifycfg -domtree -scalarrepl -early-cse -targetlibinfo -no-aa-tbaa -basicaa -globalopt -ipsccp -deadargelim -instcombine -simplifycfg -basiccg -prune-eh -inline -functionattrs -argpromotion -scalarrepl-ssa -domtree -early-cse -simplify-libcalls -lazy-value-info-jump-threading -correlated-propagation -simplifycfg -instcombine -tailcallelim -simplifycfg -reassociate-domtree -loops -loop-simplify -lcssa -loop-rotate -licm -lcssa -loop-unswitch -instcombine -scalar-evolution-loop-simplify -lcssa -iv-users -indvars -loop-idiom -loop-deletion -loop-unroll -instcombine -memdep

-gvn -memdep -memcpyopt -sccp -instcombine -lazy-value-info -jump-threading -correlated-propagation-domtree -memdep -dse -adce -simplifycfg -strip-dead-prototypes -print-used-types-deadtypeelim -globaldce -constmerge -preverify -domtree -verify

Alias Analysis O LLVM possui diversos métodos de alias analysis implementados. Neste experimentoavaliamos os métodos descritos a seguir, incluindo o �-no-aa" (No Alias Analysis). Esta é a imple-mentação padrão da interface Alias analysis. Ela sempre retorna �I don't know� para as consultasde alias. Todos os métodos foram avaliados em conjunto com os passos de otimização utilizados em�-O3� substituindo os passos de alias presente no padrão pelo alias analysis desejado:

-basicaa 2 Basic Alias Analysis implementa identidades, i.e., duas variáveis globais diferentes sãoalias.

-globalsmodref-aa 3 (Simple mod/ref analysis for globals). Esta análise fornece informação paravalores globais que não têm seu endereço tomado, e mantém o controle se funções de leitura ougravação em memória são �puros�.

-scev-aa (ScalarEvolution-based Alias Analysis). Análise simples implementada em termos de con-sultas ScalarEvolution. Difere da análise tradicional de dependência de laço onde os testes dedependências são dentro de uma única iteração de um laço, ao invés de dependências entre asdiferentes iterações. ScalarEvolution tem uma compreensão mais completa da aritmética de pon-teiros que a Basic Alias Analysis.

Otimizações individuais As seguintes otimizações foram avaliadas com o objetivo de medir o impacto desuas contribuições quando desligadas (removidas) do grupo padrão O3:

dead Compõem o grupo, as otimizações Dead Argument Elimination, Aggressive Dead Code Elimi-nation, Dead Store Elimination e Dead Global Elimination. O passo Dead Argument Eliminationexclui argumentos mortos de funções internas. Este passo remove tanto os argumentos que estãomortos, bem como os argumentos passados apenas em chamadas de função como argumentosmortos de outras funções. Esta otimização é freqüentemente útil como limpeza após otimizaçõesinterprocedurais agressivas, que adicionam argumentos possivelmente mortos. O passo AggressiveDead Code Elimination tenta eliminar código, semelhante ao Dead Code Elimination, mas, deforma agressiva, assume que os valores estão mortos até que se prove o contrário. Esta otimizaçãoé semelhante ao Sparse Conditional Constant Propagation, exceto que é aplicada ao liveness devalores. O passo Dead Store Elimination é uma otimização trivial que elimina somente stores re-dundantes em blocos básicos. Por �m, a transformação Dead Global Elimination é projetada paraeliminar dados globais que não são alcançáveis no programa. Este usa um algoritmo agressivo,procurando dados globais que estão vivos. Depois que ele encontra todos os dados globais que

2Nas tabelas de resultados, basicaa é referenciado simplesmente por basic3Idem para globalsmodref-aa, referido como global

3

são necessários, exclui o que sobra. Isso permite também excluir trechos do programa que sãoinacessíveis.

gvn Global Value Numbering Este passo elimina instruções totalmente e parcialmente redundantes.Ele também realiza eliminação de carga redundantes.

sccp Sparse Conditional Constant Propagation. Este passo de otimização assume que valores são con-stantes e substitui-os pelas mesmas, a menos que se prove o contrário; assume que blocos básicosestão mortos e elimina-os, a menos que se prove o contrário e, transforma desvios condicionais emincondicionais quando factível.

simpl Simplify the CFG. Este passo executa eliminação de código morto e fusão de blocos básicos.Especi�camente, remove blocos básicos, sem predecessores; mescla um bloco básico com o seupredecessor se houver apenas um e o predecessor só tem ele como sucessor; elimina nós PHI(contendo φ-functions) para os blocos básicos com um único predecessor e elimina um blocobásico que contém apenas um ramo incondicional.

3 Infraestrutura

A seguinte infraestrutura foi utilizada em nossas experimentações:

Geração de Código otimizado. Para a geração de código otimizado utilizou-se o LLVM 2.9. O ProjetoLLVM [1] é uma coleção de tecnologias de compilação modular e reutilizável. LLVM começou como umprojeto de pesquisa da Universidade de Illinois, com o objetivo de oferecer uma estratégia de compilaçãomoderna, baseado em SSA, capaz de suportar tanto a compilação estática e dinâmica de um númeroarbitrário de linguagens de programação. Desde então, o LLVM cresceu para ser um projeto guarda-chuva que consiste em um número de diferentes subprojetos, muitas das quais estão sendo utilizados naprodução de uma ampla variedade de projetos de código aberto e comerciais, além de ser amplamenteutilizado em pesquisas acadêmicas. O principal sub-projeto do LLVM são as bibliotecas núcleo doLLVM que fornecem uma otimizador moderno e independente da plataforma alvo, juntamente como suporte de geração de código para as CPUs mais populares. Essas bibliotecas são construídas emtorno de uma representação de código bem especi�cada conhecida como a representação intermediáriaLLVM ("LLVM IR"). As bibliotecas núcleo do LLVM estão bem documentados, e é particularmentefácil portar para um compilador existente para usar o LLVM como um otimizador e gerador de código.Maiores informações, o leitor pode encontrar em http://www.llvm.org.

Aplicações. A tabela 1 descreve o subconjunto das aplicações do SPEC CPU2006 utilizadas no nossoexperimento, divididos em aplicações que usam instruções inteiras e de ponto �utuante, sua categoriae a linguagem de programação utilizada. Maiores detalhes sobre a descrição das aplicações o leitorencontra em [3].

Máquina alvo. Foi utilizado como máquina alvo um notebook Dell Vostro 1440 com processador Intel Core2 Duo T7250 @ 2GHz e 2 GB de memória. O sistema operacional na máquina alvo utilizada foi oKubuntu 11.10 com kernel Linux versão 3.0.0-13 e interface grá�ca KDE 4.7.2.

4 Resultados Experimentais

A tabela 2 na página 9 apresenta os resultados brutos de todas as simulações executadas neste experimento.Nesta tabela o tempo de execução (exec time) mostrado corresponde ao tempo médio. Os grá�cos usadosnas análises fornecem também o intervalo de con�ança. Quando dois intervalos se sobrepõe, consideramospara efeito de análise que os resultados são iguais.

4

Benchmark Aplicação Linguagem Categoria

Integer

perlbench ANSI C Linguagem de programação. Interpretador Perlbzip2 ANSI C Compressão/Descompressão de códigogcc C Compilador e Otimizador para a Linguagem Cmcf ANSI C Otimização Combinatorialgobmk C Inteligência Arti�cial, Jogo Gohmmer C Modelo estatistico para busca de padrões em sequencias de DNAsjeng C Inteligência Arti�cial. Reconhecimento de Padrões e busca em árvorelibquantum C99 Simulador de um computador quânticoh264ref C Compressão de Vídeoomnetpp C++ Simulação de Eventos Discretosastar C++ Inteligência Arti�cal. Algoritmos de busca de caminhos em mapasxalancbmk C++ Processador XLST. Transforma Documentos XML em HTML

Floating Point

milc C Simulações em Física Quânticanamd C++ Simulaçoes em Dinâmica Molecular ClássicadealII C++ Soluções de Equações Diferenciais Parciaissoplex ANSI C++ Solução Programação Linear pelo método Simplexlbm ANSI C Simulação. Dinâmica de �uídos

Tabela 1: Aplicações SPEC CPU2006

Isto posto, notamos que algumas análises �caram prejudicadas em um conjunto de aplicações, por estasapresentarem tempos de execução iguais. São elas, gcc, gobmk, omnetpp, sjeng e xalancbmk. A massa dedados de entrada utilizadas para estas aplicações são massas de testes e, ao que tudo indica, não estressaramadequadamente a aplicação. Em função do tempo exíguo proposto para este trabalho, não pudemos repetirtais experimentos com massa de dados mais adequadas. No entanto, como o volume de aplicações é razoável,estas não prejudicaram nosso objetivo principal.

4.1 Tempo de Otimização

Nossa primeira análise é sobre o tempo dispendido durante a otimização. Apesar de não ser um tempo críticono processo de desenvolvimento de uma aplicação, nota-se na comparação dos dois gra�cos mostrados na�gura 1 que o número de bytes otimizados por segundo decresse 25% quando se utiliza o padrão O3 (maisagressivo) em relação ao padrão O1.

(a) padrão O1 (b) padrão O3

Figura 1: Bytes otimizados por segundo nos padrões O1 e O3

5

4.2 Impacto no código

Nossa segunda análise examina o impacto no código, em termos de tamanho, em função das otimizaçõesrealizadas. Observamos que a maioria dos experimentos produziram uma redução no tamanho do códigootimizado comparado com o código sem otimizações, produzido pelo compilador. Os gra�cos na �gura 3mostram que este comportamento é o mais esperado.

Figura 2: Efeito no O3

Observou-se, no entanto, que o conjunto de otimiza-ções do padrão O3 quando aplicado a alguns progra-mas produz um aumento no tamanho do código comopode ser observado na aplicação omnetpp, mostradona �gura 2. Existe um conjunto de otimizações quepodem ser responsáveis por este aumento como, porexemplo, loop unrolling4 Este comportamento tam-bém foi observado nas aplicações gcc emilc mostradasna �gura 4. Uma análise das aplicações poderiamostrar se as mesmas guardam alguma relação como,por exemplo, um número grande de laços, o que pode-ria explicar este comportamento.

(a) Astar (b) bzip2 (c) dealII

(d) mcf (e) h264ref (f) libquantum

Figura 3: tamanho do código em relação ao código sem otimização

Por outro lado, desligando e religando as otimizações do padrão O3, poderia determinar exatamente qual ouquais otimizações foram responsáveis por este comportamento. Esta metodologia foi aplicada em parte nanossa próxima análise.

4.3 Tempo de Execução

Esta é sem dúvida a análise mais importante porque estamos geralmente interessados na melhoria de desem-penho de nossas aplicações e isto normalmente re�ete diretamente no tempo de execução. Uma análise dosdados coletados nos mostra que obtivemos uma melhora de 29% (mcf ) à 70% (delaII ) no tempo de execução

4Como este passo esta presente também no padrão O2, cabe aqui uma análise mais re�nada se de fato loop-unroll é oresponsável e também identi�car a in�uência do passo argpromotion nos passos seguintes.

6

(a) gcc (b) milc

Figura 4: Exemplos de aumento do código para o padrão O3

quando comparado com o código sem otimização. Isto nos mostra quanto o processo de otimização é impor-tante e faz com que uma busca pela melhor combinação de ana¨ise e otimizações para nossas aplicações sejaum objetivo a ser perseguido.

(a) mcf (b) milc

Figura 5: tempo de execução para as diversas otimizações

Note na �gura 5 que para a aplicação mcf o passo de otimização simplify the CFG tem uma contribuição neg-ativa no padrão O3. Provavelmente as simpli�cações realizadas �esconderam� oportunidades de otimizaçãodos passos seguintes. O comportamento �normal� esperado é mostrado na aplicação milc. Nesta aplicação,a remoção de qualquer um dos grupos de otimizações individuais aqui analisados revela uma contribuiçãode mais de 6% dentro do grupo O3.

5 Conclusões

O que se pode observar nas analises realizadas é que, em primeiro lugar, não se detectou uma otimizaçãoque seja killer. Percebeu-se também que nem sempre as otimizações consideradas mais agressivas, como é ocaso do padrão O3, resultaram em um melhor desempenho. Por exemplo, o padrão O2 apresentou melhordesempenho em relação ao padrão O3 nas aplicações (a)-Astar e (c)-gcc (�gura 6). Observou-se também queas alias analysis, em particular, globalsmodref-aa e scev-aa apresentaram uma melhora perceptiva somentena aplicação (b)-bzip2 (ver �gura 6). A conclusão que se pode chegar é que a escolha de se aplicar ou nãoum passo de otimização é sensível ao tipo de aplicação.

7

(a) Astar (b) bzip2 (c) dealII

(d) gcc (e) h264ref (f) libquantum

Figura 6: comparação do tempo de execução em diversas otimizações

Referências

[1] Chris Lattner and Vikram Adve. The LLVM Compiler Framework and Infrastructure Tutorial, LCPC'04Mini Workshop on Compiler Research Infrastructures, West Lafayette, Indiana, USA, Sep/2004

[2] Reid Spencer and Gordon Henriksen. LLVM Analysis and transform Passes, Documentation for theLLVM System at http://www.llvm.org/docs/Passes.html

[3] SPEC CPU2006 Benchmark Descriptions. Descriptions written by the SPEC CPU Subcommittee andby the original program authors posted at www.spec.org/cpu2006/Docs/. Edited by John L. Hen-ning, Secretary, SPEC CPU Subcommittee, and Performance Engineer, Sun Microsystems. Contactjohn.henning@acm.org

8

Applications Optmizations No opt O1 O2 O3 no-aa basic global scev dead gvn sccp simpl

AstarOpt time - 0.272 0.316 0.320 0.320 0.328 0.276 0.316 0.296 0.276 0.336 0.292Text size 55755 43703 43311 44667 43815 43743 43815 43815 43935 44183 43743 43991Exec time 26.00 14.01 13.87 13.97 14.11 14.02 14.13 14.14 13.97 14.04 14.00 13.93

bzip2Opt time - 0.792 1.0241 0.8961 0.796 1.0801 0.76 0.776 1.0161 0.7841 1.0401 1.0081Text size 84273 68172 72172 72684 69004 72332 69004 69004 72492 69420 72332 72364Exec time 1:31.81 54.36 54.46 54.56 54.56 54.95 53.77 53.71 54.33 54.75 55.15 54.09

dealIIOpt time - 21.8094 23.6615 24.7136 23.5815 23.9895 23.3255 24.1735 23.9935 22.9054 23.5215 23.8135Text size 5122907 3187951 3234331 3300159 3244691 3238659 3244691 3244691 3269351 3238643 3239823 3227707Exec time 4:00.01 1:11.52 1:11.06 1:11.06 1:11.36 1:11.06 1:11.33 1:11.26 1:11.20 1:11.34 1:11.07 1:11.14

gccOpt time - 34.2181 43.8507 54.0034 39.3145 44.5108 39.6625 39.9625 43.9467 35.3182 43.9148 41.9146Text size 4108585 3933768 3905000 4264568 3943000 3919960 3943000 3943000 3935288 3946568 3925512 3926296Exec time 0:03.06 0:01.95 0:01.94 0:01.96 0:01.94 0:01.94 0:01.95 0:01.94 0:01.94 0:01.96 0:01.95 0:01.95

gobmkOpt time - 5.8724 7.0964 7.7885 6.5964 7.1724 6.5884 6.7604 7.0204 6.2164 6.8884 7.0164Text size 1707803 1578466 1581844 1668420 1587412 1586436 1587412 1587412 1586836 1588980 1586916 1590292Exec time 0:00.33 0:00.26 0:00.26 0:00.26 0:00.26 0:00.26 0:00.26 0:00.26 0:00.26 0:00.26 0:00.26 0:00.26

h264refOpt time - 4.2643 5.4763 5.8804 5.2923 5.8644 5.1923 5.1603 5.6724 5.0363 5.6284 5.5603Text size 666963 577691 597593 610681 607065 599993 607065 607065 601353 605161 598777 611913Exec time 0:59.24 0:31.38 0:30.94 0:30.88 0:31.02 0:30.87 0:31.04 0:31.05 0:31.24 0:30.99 0:30.89 0:30.96

hmmerOpt time - 2.4122 2.6802 2.9202 2.5162 2.7202 2.4682 2.5082 2.7322 2.4922 2.6762 2.7442Text size 371566 336997 333405 346493 336381 332957 336381 336381 333117 337917 333005 339933Exec time 0:13.84 0:07.15 0:06.68 0:06.78 0:06.82 0:06.69 0:06.81 0:06.82 0:06.70 0:07.17 0:06.69 0:07.60

lbmOpt time - 0.1 0.104 0.128 0.128 0.14 0.128 0.128 0.112 0.128 0.124 0.136Text size 16682 15524 15268 15620 15620 15476 15620 15620 15508 15892 15476 15636Exec time 0:09.01 0:08.98 0:08.98 0:08.98 0:08.97 0:08.98 0:08.97 0:08.98 0:08.97 0:08.97 0:08.98 0:08.81

libquantumOpt time - 0.232 0.248 0.272 0.252 0.268 0.228 0.252 0.24 0.224 0.244 0.248Text size 49827 37413 40789 44885 41365 41541 41365 41365 41621 38117 41541 42117Exec time 0:08.54 0:05.45 0:05.28 0:05.24 0:05.46 0:05.31 0:05.47 0:05.47 0:05.30 0:05.43 0:05.28 0:05.23

mcfOpt time - 0.084 0.08 0.1 0.096 0.088 0.088 0.084 0.076 0.076 0.088 0.084Text size 15709 12861 12813 13197 12861 12813 12861 12861 12813 12861 12813 12909Exec time 0:05.09 0:03.57 0:03.57 0:03.58 0:03.61 0:03.57 0:03.58 0:03.57 0:03.57 0:03.56 0:03.57 0:03.53

milcOpt time - 0.836 0.981 1.2281 0.8841 1.0401 0.8961 0.8801 1.0041 0.9241 1.0121 1.0361Text size 146235 122492 135372 147020 134572 135564 134572 134572 135772 135756 135756 138972Exec time 0:41.65 0:22.18 0:21.74 0:21.72 0:21.82 0:21.80 0:21.85 0:21.76 0:23.03 0:22.90 0:22.99 0:23.06

namdOpt time - 2.3642 2.8962 2.9402 2.5882 2.9722 2.5962 2.5882 2.8722 2.4282 2.8682 2.9242Text size 500043 341826 341378 342116 340122 341018 340122 340122 342066 342426 341018 341658Exec time 0:42.42 0:21.32 0:21.29 0:21.28 0:21.31 0:21.30 0:21.29 0:21.31 0:21.29 0:21.26 0:21.28 0:21.27

omnetppOpt time - 5.1323 5.8124 8.5765 5.5804 5.7844 5.5083 5.6244 5.7684 5.3083 5.7364 6.2964Text size 1033828 991073 994609 1133469 994981 994245 994981 994981 995293 993785 994185 1000889Exec time 0:01.80 0:00.68 0:00.67 0:00.65 0:00.66 0:00.67 0:00.66 0:00.66 0:00.64 0:00.66 0:00.67 0:00.64

perlbenchOpt time - 10.6247 12.4048 14.2049 12.5648 13.3328 12.4768 12.6088 13.1808 11.5767 13.1888 13.5769Text size 1349805 1268671 1271931 1349099 1286587 1278507 1286587 1286587 1284955 1275547 1279529 1284651Exec time 0:10.83 0:07.11 0:06.62 0:06.77 0:06.76 0:06.59 0:06.74 0:06.84 0:06.49 0:06.63 0:06.66 0:06.60

sjengOpt time - 0.748 0.8801 0.9361 0.76 0.8561 0.764 0.772 0.8841 0.756 0.8641 0.8881Text size 154401 140461 140829 143709 141917 141469 141917 141917 141901 142237 141469 142605Exec time 0:10.84 0:06.63 0:06.60 0:06.50 0:06.50 0:06.51 0:06.51 0:06.46 0:06.58 0:06.61 0:06.50 0:06.82

sjengOlooppt time - 2.7282 2.9682 3.2362 2.8882 3.1562 2.9602 3.0322 3.1122 2.7762 2.9482 3.3162Text size 536448 394169 389321 403293 395041 390537 395041 395041 393277 395481 390809 395925Exec time 0:00.05 0:00.02 0:00.02 0:00.02 0:00.02 0:00.02 0:00.02 0:00.02 0:00.02 0:00.02 0:00.02 0:00.02

xalancbmkOpt time - 30.7219 34.6422 37.3063 33.0221 35.0742 33.4181 34.2102 34.0941 31.642 34.1901 34.1101Text size 6814992 4725744 4761688 5006264 4740980 4765032 4740980 4740980 4781968 4734940 4758880 4769036Exec time 0:00.81 0:00.13 0:00.13 0:00.13 0:00.14 0:00.13 0:00.14 0:00.14 0:00.13 0:00.13 0:00.13 0:00.13

Tabela 2: Resultados Experimentais

9