Este documento resume os resultados experimentais de análises e otimizações no LLVM. Foram avaliados os padrões O1, O2 e O3 do LLVM em aplicações do SPEC CPU2006, além de diferentes alias analyses e otimizações individuais. A metodologia empregada mediu o tempo de compilação, tamanho de código e desempenho, buscando identificar a melhor configuração de análises e otimizações para cada tipo de aplicação.

1. 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 LLVM
1
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 sosticação. Embora possam ser
obtidas melhorias signicativas em muitos programas, o potencial de degradação de desempenho nos padrões
de determinado programa é conhecido por desenvolvedores de compiladores e muitos usuários. Aplicar as
otimizações do compilador a um determinado programa pode ter um impacto signicativo sobre o desem-
penho do mesmo. Devido à interação não-linear de otimizações do compilador, no entanto, determinar a
melhor conguração não é trivial. Diversas técnicas que buscam o espaço de opções do compilador para
encontrar 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 do
compilador reete 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 insuciente da arquitetura
alvo pode limitar severamente a precisão de desempenho. Assim, a determinação da melhor combinação de
aná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 de
opções. Por exemplo, o LLVM inclui mais de 100 opções de otimização, além de agrupar um subconjunto
delas e oferecer em três níveis de otimização, O1, O2 e O3. Isto criou a necessidade de se desenvolver
uma metodologia que possa identicar e apresentar de maneira sistemática o comportamento de programas
submetidos 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 de
código do compilador LLVM em um conjunto de aplicações do SPEC CPU2006. A metodologia empregada
pode ser vista como um passo inicial na busca de uma sistematização para se determinar o subconjunto de
aná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ítico
e trechos de código que são menos críticos. Fazer com que as partes críticas possam executar o mais rápido
possível envolve não somente a escolha de um subconjunto de análises e otimizações bem como determinar
a 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ções
em tempo de compilação, ligação e execução de programas escritos em uma variedade de linguagens.
1

2. desempenho do programa. Os esforços de otimização podem modicar ou eliminar códigos fora do caminho
crí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 menos
eciente do que quando se adota simplesmente as otimizações padrões O1, O2 ou O3 disponibilizados pelo
LLVM.
2 Metodologia
O LLVM possui diversos tipos de otimizações que podem ser aplicados ao código, incluindo os grupos de
otimizações padrões O1, O2 e O3. Neste experimento, primeiro avaliamos os 3 grupos padrões de compilação
e 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érie
de modicações para avaliar primeiro, o impacto das diversas alias analysis descritas em 2.2 e, por m, a
contribuiçã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 cada
aplicação foi utilizada. A partir desta amostra estimou-se os parametros µ (média) e σ (variança):
¯X =
1
n
n
i=1
Xi, S2
=
n
i=1 (Xi − ¯X)
2
n − 1
que produziram para a amostra selecionada as estimativas pontuais. Uma maneira de expressar a
precisão da estimação é estabelecer limites que com certa probabilidade incluem o verdadeiro valor do
parâmetro. Em nossos experimentos, construímos então um intervalo de conança de 95%, i.e., um
intervalo no qual estamos 95% conantes da cobertura do verdadeiro valor do parâmetro. O intervalo
de conanç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ósito
geral. 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). Em
relação ao padrão O1, O2 e O3 apresentam os seguintes passos de otimização: loop-unroll (desenrolar
de laços), gvn (numeração de valores globais) seguido de memdep (análise de dependência de memória)
2

3. 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 o
padrã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 experimento
avaliamos 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 consultas
de 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ão
alias.
-globalsmodref-aa 3 (Simple mod/ref analysis for globals). Esta análise fornece informação para
valores globais que não têm seu endereço tomado, e mantém o controle se funções de leitura ou
gravaçã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 de
dependências são dentro de uma única iteração de um laço, ao invés de dependências entre as
diferentes 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 de
suas 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 Elimination
exclui argumentos mortos de funções internas. Este passo remove tanto os argumentos que estão
mortos, bem como os argumentos passados apenas em chamadas de função como argumentos
mortos de outras funções. Esta otimização é freqüentemente útil como limpeza após otimizações
interprocedurais agressivas, que adicionam argumentos possivelmente mortos. O passo Aggressive
Dead Code Elimination tenta eliminar código, semelhante ao Dead Code Elimination, mas, de
forma 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 de
valores. 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 para
eliminar 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 basic
3Idem para globalsmodref-aa, referido como global
3

4. são necessários, exclui o que sobra. Isso permite também excluir trechos do programa que são
inacessí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ásicos
estão mortos e elimina-os, a menos que se prove o contrário e, transforma desvios condicionais em
incondicionais quando factível.
simpl Simplify the CFG. Este passo executa eliminação de código morto e fusão de blocos básicos.
Especicamente, remove blocos básicos, sem predecessores; mescla um bloco básico com o seu
predecessor 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 bloco
bá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 Projeto
LLVM [1] é uma coleção de tecnologias de compilação modular e reutilizável. LLVM começou como um
projeto de pesquisa da Universidade de Illinois, com o objetivo de oferecer uma estratégia de compilação
moderna, baseado em SSA, capaz de suportar tanto a compilação estática e dinâmica de um número
arbitrá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 na
produção de uma ampla variedade de projetos de código aberto e comerciais, além de ser amplamente
utilizado em pesquisas acadêmicas. O principal sub-projeto do LLVM são as bibliotecas núcleo do
LLVM que fornecem uma otimizador moderno e independente da plataforma alvo, juntamente com
o suporte de geração de código para as CPUs mais populares. Essas bibliotecas são construídas em
torno de uma representação de código bem especicada conhecida como a representação intermediária
LLVM (LLVM IR). As bibliotecas núcleo do LLVM estão bem documentados, e é particularmente
fá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 nosso
experimento, divididos em aplicações que usam instruções inteiras e de ponto utuante, sua categoria
e a linguagem de programação utilizada. Maiores detalhes sobre a descrição das aplicações o leitor
encontra em [3].
Máquina alvo. Foi utilizado como máquina alvo um notebook Dell Vostro 1440 com processador Intel Core
2 Duo T7250 @ 2GHz e 2 GB de memória. O sistema operacional na máquina alvo utilizada foi o
Kubuntu 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 usados
nas análises fornecem também o intervalo de conança. Quando dois intervalos se sobrepõe, consideramos
para efeito de análise que os resultados são iguais.
4

5. Benchmark Aplicação Linguagem Categoria
Integer
perlbench ANSI C Linguagem de programação. Interpretador Perl
bzip2 ANSI C Compressão/Descompressão de código
gcc C Compilador e Otimizador para a Linguagem C
mcf ANSI C Otimização Combinatorial
gobmk C Inteligência Articial, Jogo Go
hmmer C Modelo estatistico para busca de padrões em sequencias de DNA
sjeng C Inteligência Articial. Reconhecimento de Padrões e busca em árvore
libquantum C99 Simulador de um computador quântico
h264ref C Compressão de Vídeo
omnetpp C++ Simulação de Eventos Discretos
astar C++ Inteligência Artical. Algoritmos de busca de caminhos em mapas
xalancbmk C++ Processador XLST. Transforma Documentos XML em HTML
Floating Point
milc C Simulações em Física Quântica
namd C++ Simulaçoes em Dinâmica Molecular Clássica
dealII C++ Soluções de Equações Diferenciais Parciais
soplex ANSI C++ Solução Programação Linear pelo método Simplex
lbm 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 estas
apresentarem tempos de execução iguais. São elas, gcc, gobmk, omnetpp, sjeng e xalancbmk. A massa de
dados de entrada utilizadas para estas aplicações são massas de testes e, ao que tudo indica, não estressaram
adequadamente a aplicação. Em função do tempo exíguo proposto para este trabalho, não pudemos repetir
tais 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ítico
no processo de desenvolvimento de uma aplicação, nota-se na comparação dos dois gracos mostrados na
gura 1 que o número de bytes otimizados por segundo decresse 25% quando se utiliza o padrão O3 (mais
agressivo) 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

6. 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ções
realizadas. Observamos que a maioria dos experimentos produziram uma redução no tamanho do código
otimizado comparado com o código sem otimizações, produzido pelo compilador. Os gracos na gura 3
mostram 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 como
pode ser observado na aplicação omnetpp, mostrado
na gura 2. Existe um conjunto de otimizações que
podem ser responsáveis por este aumento como, por
exemplo, loop unrolling
4 Este comportamento tam-
bém foi observado nas aplicações gcc e milc mostradas
na gura 4. Uma análise das aplicações poderia
mostrar 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 ou
quais otimizações foram responsáveis por este comportamento. Esta metodologia foi aplicada em parte na
nossa 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 reete diretamente no tempo de execução. Uma análise dos
dados 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 renada se de fato loop-unroll é o
responsável e também identicar a inuência do passo argpromotion nos passos seguintes.
6

7. (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 seja
um 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 simplicações realizadas esconderam oportunidades de otimização
dos 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ção
de 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ção
que seja killer. Percebeu-se também que nem sempre as otimizações consideradas mais agressivas, como é o
caso do padrão O3, resultaram em um melhor desempenho. Por exemplo, o padrão O2 apresentou melhor
desempenho em relação ao padrão O3 nas aplicações (a)-Astar e (c)-gcc (gura 6). Observou-se também que
as alias analysis, em particular, globalsmodref-aa e scev-aa apresentaram uma melhora perceptiva somente
na aplicação (b)-bzip2 (ver gura 6). A conclusão que se pode chegar é que a escolha de se aplicar ou não
um passo de otimização é sensível ao tipo de aplicação.
7

8. (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'04
Mini Workshop on Compiler Research Infrastructures, West Lafayette, Indiana, USA, Sep/2004
[2] Reid Spencer and Gordon Henriksen. LLVM Analysis and transform Passes, Documentation for the
LLVM System at http://www.llvm.org/docs/Passes.html
[3] SPEC CPU2006 Benchmark Descriptions. Descriptions written by the SPEC CPU Subcommittee and
by 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. Contact
john.henning@acm.org
8

9. Applications Optmizations No opt O1 O2 O3 no-aa basic global scev dead gvn sccp simpl
Astar
Opt time - 0.272 0.316 0.320 0.320 0.328 0.276 0.316 0.296 0.276 0.336 0.292
Text size 55755 43703 43311 44667 43815 43743 43815 43815 43935 44183 43743 43991
Exec 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
bzip2
Opt time - 0.792 1.0241 0.8961 0.796 1.0801 0.76 0.776 1.0161 0.7841 1.0401 1.0081
Text size 84273 68172 72172 72684 69004 72332 69004 69004 72492 69420 72332 72364
Exec 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
dealII
Opt time - 21.8094 23.6615 24.7136 23.5815 23.9895 23.3255 24.1735 23.9935 22.9054 23.5215 23.8135
Text size 5122907 3187951 3234331 3300159 3244691 3238659 3244691 3244691 3269351 3238643 3239823 3227707
Exec 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
gcc
Opt time - 34.2181 43.8507 54.0034 39.3145 44.5108 39.6625 39.9625 43.9467 35.3182 43.9148 41.9146
Text size 4108585 3933768 3905000 4264568 3943000 3919960 3943000 3943000 3935288 3946568 3925512 3926296
Exec 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
gobmk
Opt time - 5.8724 7.0964 7.7885 6.5964 7.1724 6.5884 6.7604 7.0204 6.2164 6.8884 7.0164
Text size 1707803 1578466 1581844 1668420 1587412 1586436 1587412 1587412 1586836 1588980 1586916 1590292
Exec 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
h264ref
Opt time - 4.2643 5.4763 5.8804 5.2923 5.8644 5.1923 5.1603 5.6724 5.0363 5.6284 5.5603
Text size 666963 577691 597593 610681 607065 599993 607065 607065 601353 605161 598777 611913
Exec 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
hmmer
Opt time - 2.4122 2.6802 2.9202 2.5162 2.7202 2.4682 2.5082 2.7322 2.4922 2.6762 2.7442
Text size 371566 336997 333405 346493 336381 332957 336381 336381 333117 337917 333005 339933
Exec 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
lbm
Opt time - 0.1 0.104 0.128 0.128 0.14 0.128 0.128 0.112 0.128 0.124 0.136
Text size 16682 15524 15268 15620 15620 15476 15620 15620 15508 15892 15476 15636
Exec 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
libquantum
Opt time - 0.232 0.248 0.272 0.252 0.268 0.228 0.252 0.24 0.224 0.244 0.248
Text size 49827 37413 40789 44885 41365 41541 41365 41365 41621 38117 41541 42117
Exec 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
mcf
Opt time - 0.084 0.08 0.1 0.096 0.088 0.088 0.084 0.076 0.076 0.088 0.084
Text size 15709 12861 12813 13197 12861 12813 12861 12861 12813 12861 12813 12909
Exec 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
milc
Opt time - 0.836 0.981 1.2281 0.8841 1.0401 0.8961 0.8801 1.0041 0.9241 1.0121 1.0361
Text size 146235 122492 135372 147020 134572 135564 134572 134572 135772 135756 135756 138972
Exec 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
namd
Opt time - 2.3642 2.8962 2.9402 2.5882 2.9722 2.5962 2.5882 2.8722 2.4282 2.8682 2.9242
Text size 500043 341826 341378 342116 340122 341018 340122 340122 342066 342426 341018 341658
Exec 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
omnetpp
Opt time - 5.1323 5.8124 8.5765 5.5804 5.7844 5.5083 5.6244 5.7684 5.3083 5.7364 6.2964
Text size 1033828 991073 994609 1133469 994981 994245 994981 994981 995293 993785 994185 1000889
Exec 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
perlbench
Opt time - 10.6247 12.4048 14.2049 12.5648 13.3328 12.4768 12.6088 13.1808 11.5767 13.1888 13.5769
Text size 1349805 1268671 1271931 1349099 1286587 1278507 1286587 1286587 1284955 1275547 1279529 1284651
Exec 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
sjeng
Opt time - 0.748 0.8801 0.9361 0.76 0.8561 0.764 0.772 0.8841 0.756 0.8641 0.8881
Text size 154401 140461 140829 143709 141917 141469 141917 141917 141901 142237 141469 142605
Exec 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
sjeng
Olooppt time - 2.7282 2.9682 3.2362 2.8882 3.1562 2.9602 3.0322 3.1122 2.7762 2.9482 3.3162
Text size 536448 394169 389321 403293 395041 390537 395041 395041 393277 395481 390809 395925
Exec 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
xalancbmk
Opt time - 30.7219 34.6422 37.3063 33.0221 35.0742 33.4181 34.2102 34.0941 31.642 34.1901 34.1101
Text size 6814992 4725744 4761688 5006264 4740980 4765032 4740980 4740980 4781968 4734940 4758880 4769036
Exec 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