An alise Comparativa do C odigo Gerado por Compiladores Java e C++

Valente Ricardo Terra, Jussara Almeida, Roberto S. Bigonha, Marco Tulio o Departamento de Ci encia da Computac a Universidade Federal de Minas Gerais (UFMG) 31.270-010 Belo Horizonte MG
{terra,jussara,bigonha,mtov}@dcc.ufmg.br

Abstract. Platform independence provided by interpreters is usually achieved at the expense of efciency. Although such inefciency can be tackled by several optimization techniques, the efciency of interpreted languages such as Java is still questioned nowadays. This article initially describes what types of operations are relatively slow in Java and presents a comparative analysis of several classes of algorithms implemented both in Java and C/C++. It also compares the performance gains that have been achieved by versions of the GNU GCC and JDK compilers delivered in the last ve years. Resumo. Independ encia de plataforma normalmente e obtida a ` s custas da eci encia de execuc a ao interpretados a par o de sistemas, que nesses casos s tir de c odigos intermedi arios. Embora esses tipos de ineci encia t em sido resolvidos via novas t ecnicas de compilac a encia da linguagem Java e o, a eci ainda muito questionada nos dias de hoje. Diante disso, este artigo procura inicialmente enumerar quais tipos de operac o ao relativamente len es ainda s tas em Java e apresenta uma an alise comparativa entre implementac o es Java e C/C++ de diversas classes de algoritmos. Compara-se tamb em o impacto das melhorias dos compiladores GNU GCC e JDK no tempo de execuc a odigo o do c gerado nesses u ltimos cinco anos.

o 1. Introduc a
A linguagem Java vem obtendo destaque no desenvolvimento de sistemas. Contudo, sua muito discutida nos dias de hoje, sendo usualmente considerada lenta e com eci encia e amplamente adotada no desenvolvimento alta demanda de mem oria [8]. Mesmo assim, e o; de sistemas, devido a diversos fatores como: (i) facilidade de aprendizagem e utilizac a (ii) diversos arcabouc os e bibliotecas p ublicas dispon veis; (iii) ampla gama de f oruns, grupos de discuss ao devido ao grande n umero de comunidades de desenvolvedores; (iv) considerado fundamental pela quantidade de diferentes portabilidade, o que atualmente e o ou utilizac o; entre outros [2]. plataformas; (v) sem custo de aquisic a a o, e de se esperar que sistemas deAnalisando unicamente o tempo de execuc a senvolvidos em C/C++ tenham melhor desempenho do que sistemas desenvolvidos em Java [8, 9, 5, 4, 1]. Claramente, esse racioc nio se deve ao fato de se conhecer o processo o dessas linguagens. Enquanto uma compilac o C/C++ gera diretamente de compilac a a o Java gera um c c odigo de m aquina, uma compilac a odigo intermedi ario (bytecode) que interpretado pela M posteriormente e aquina Virtual Java (Java Virtual Machine ou JVM).

Por outro lado, compiladores est ao em constante aprimoramento, incorporando novas o. Apenas para citar um exemplo, a JVM incorpora um t ecnicas e recursos de otimizac a o do byterecurso conhecido como compilador JIT (Just-In-Time) que consiste na traduc a o [7]. code para c odigo de m aquina nativo em tempo de execuc a Diante disto, este artigo tem o intuito de avaliar o desempenho da linguagem Java o a ` linguagem C/C++ em duas esferas. Primeiramente, v em comparac a arios algoritmos foram implementados e executados tanto em Java quanto em C/C++, com o objetivo de es s mostrar se realmente Java sempre tem pior desempenho e quais tipos de operac o ao realizada uma an notoriamente mais lentas. Por outro lado, e alise dos compiladores de Java e C/C++ de cinco anos atr as e os de atualmente a m de avaliar o impacto das o do c melhorias dos compiladores no tempo de execuc a odigo gerado. o 2 desO restante deste artigo est a organizado conforme descrito a seguir. A Sec a o completa do ambiente experimental creve a metodologia aplicada, incluindo a descric a o 3 descreve um comparativo entre as e da carga de trabalho utilizada. Em seguida, a Sec a es pareadas de diversos algoritmos, e a Sec o 4 analisa linguagens por meio de observac o a o do quantitativamente o impacto das melhorias dos compiladores no tempo de execuc a ltimos cinco anos. Por m, a Sec o 5 descreve trabalhos relacioc odigo gerado nesses u a o 6 conclui. nados e a Sec a

2. Metodologia
Para atingir os objetivos propostos neste artigo, as seguintes atividades foram executadas: 1. O experimento foi todo realizado em uma m aquina dedicada do Laborat orio de o congurada exclusivamente para o desenvolvimento Linguagem de Programac a dos experimentos. Isso foi realizado a m de prover um ambiente com validade descrito em detalhes na Subsec o 2.1. experimental. O ambiente e a 2. Realizou-se uma an alise comparativa entre Java e C/C++. (a) Desenvolveu-se um benchmark chamado TerraBM que cont em uma s erie de algoritmos implementados em C/C++ e em Java. Como crit erio de o, foram selecionados algoritmos de alta complexidade assint selec a otica, 2 preferencialmente O(n ). Al em disso, tais algoritmos foram agrupados ` pilha de em classes espec cas, tais como algoritmos de estresse a o, a ` mem ` Unidade L execuc a oria prim aria, a ogica e Aritm etica (ULA) etc. descrita em detalhes na Subsec o 2.2. A carga de trabalho e a (b) Em seguida, foi realizado um processo experimental com validade estat stica visando avaliar o desempenho de cada um desses algoritmos e es s inferir quais tipos de operac o ao notoriamente mais lentas. descrita em detalhes na Subsec o 3. Essa atividade e a 3. Realizou-se uma an alise do impacto das melhorias dos compiladores C/C++ e o do c Java no tempo de execuc a odigo gerado.

(a) Desenvolveu-se um sistema Java chamado Simula que envolve pelo o 3. menos um algoritmo de cada classe denida na Sec a (b) Em seguida, foi realizado um Projeto Fatorial 2k r visando avaliar a o da compilac o e a vers inu encia dos par ametros de customizac a a ao do o de sistemas nessas duas linguagens. compilador no tempo de execuc a descrita em detalhes na Sec o 4. Essa atividade e a 2.1. Ambiente Todos os tempos neste artigo foram medidos em uma m aquina AMD Sempron 2.8GHz importante com 1GB de RAM, sob sistema operacional Linux Debian 5.04 Basic Shell. E mencionar que somente os servic os indispens aveis ao experimento estavam ativados e somente os aplicativos estritamente necess arios foram instalados1 . Para o experimento comparativo das linguagens foram utilizadas a JDK vers ao `s u ltimas vers oes dos compiladores. 1.6.0 20 e GNU GCC 4.5.0 que correspondem a E, para a an alise do impacto das melhorias dos compiladores C/C++ e Java no tempo de o do c execuc a odigo gerado foram tamb em utilizadas a JDK vers ao 1.5.0 222 e GNU GCC 4.0.43 . Al em disso, para que sistemas C/C++ e Java obtenham acesso equivalente aos re o justa, foram estipuladas as seguintes cursos e, consequentemente, haja uma comparac a es: (i) o espac o (stack) e do espac o din congurac o o da pilha de execuc a o de alocac a amica (heap) foram xados em 32MB; (ii) os compiladores foram congurados para otimizar o es de depurac o em tempo de execuc o foc odigo o m aximo poss vel; (iii) as informac o a a o em background na JVM. Caso ativa, essa ram desativadas; (iv) desativou-se a compilac a o permitiria que o c o congurac a odigo fosse inicialmente interpretado at e que a compilac a estivesse completa, o que invalidaria os resultados. o (i), no quesito espac Portanto, em termos t ecnicos, para atender a congurac a o o, foi inserido o par da pilha de execuc a ametro stack para C/C++ e Xss para Java. J a no quesito espac o da heap, foi inserido o par ametro heap para C/C++ e os par ametros Xms ` mem e Xmx para Java que, respectivamente, correspondem a oria inicial e m axima. Para o (ii), foi inserido o par atender a congurac a ametro O3 para C/C++ e server para Java. o (iii), foi inserido o par Para atender a congurac a ametro g0 para C/C++ e os par ametros o (iv), foi g:none, Xlint:none e dsa para Java. Por m, para atender a congurac a passado o par ametro Xbatch para a JVM. 2.2. Carga de Trabalho N ao foram utilizados benchmarks existentes, simplesmente porque n ao foi encontrado um es de algoritmos tanto em C/C++ quanto em Java. benchmark que contenha implementac o Os benchmarks encontrados ou apresentam uma gama de algoritmos em C/C++ ou ent ao
Na p agina http://www.dcc.ufmg.br/terra/sblp2010 encontra-se publicamente dis o do ambiente e detalhamento das linhas de compilac o e execuc o. pon vel o roteiro de congurac a a a 2 A JDK 1.5 foi lanc ada em setembro de 2004. 3 O GNU GCC 4.0 foi lanc ado em abril de 2005.
1

 es nas duas uma gama de algoritmos em Java, entretanto nenhum continha implementac o linguagens. o pareada, a qual requer Diante disso, com o intuito de possibilitar uma observac a o dos experimenuma carga de trabalho equivalente para as duas linguagens na execuc a tos, desenvolveu-se um benchmark de algoritmos chamado TerraBM4 que consiste na o tanto em C/C++ quanto em Java de uma s implementac a erie de algoritmos, con es estressadas nos forme descritos na Tabela 1. Esse benchmark contemplou as operac o o pareada, designa-se um tipo de observac o em benchmarks existentes. Por observac a a que s ao conduzidos n experimentos em cada um dos sistemas de tal forma que exista uma correspond encia um-para-um entre o i- esimo teste do sistema A e o i- esimo teste do sistema B [3]. Para ns de esclarecimento, neste artigo, os sistemas s ao as linguagens o e os testes s de programac a ao os algoritmos. Conv em mencionar que esses algoritmos , fez-se a foram implementados da melhor forma poss vel que a linguagem permite, isto e o preferencial de recursos que possibilitem uma maior eci utilizac a encia. Por exemplo, a o de um arranjo na linguagem C/C++, o qual pode ser feito com indexac o cl iterac a a assica, sabidamente mais eciente. optou-se por aritm etica de ponteiros que e
Tabela 1. Algoritmos do TerraBM

Objetivo ` pilha de execuc o Estresse a a ` mem Estresse a oria prim aria - Busca de valores - Troca de valores

Algoritmo Fibonacci Busca Sequencial Ordenac a o Bolha Ordenac a a o Selec o Ordenac a a o Inserc o C opia de Arquivo Mult. de Matrizes Inteiras e Decimais Simula

Complexidade O(n ) O(n) O(n2 ) O(n2 ) O(n2 ) O(n) O(n3 ) O(n3 )

` mem Estresse a oria secund aria ` ULA Estresse a o de um sistema Simulac a

Esclarecendo: =
1+ 5 2

1, 61803...

Como pode ser observado na Tabela 1, optou-se por algoritmos de alta comple o. A l xidade assint otica que estressam certa regi ao de execuc a ogica por tr as de cada fazer o uso repetitivo de determinados tipos de operac o. algoritmo e a analisar o comportamento de sisteO objetivo do algoritmo recursivo Fibonacci e o ao estresse da pilha de execuc o. Em relac o ao estresse a ` mas C/C++ e Java em relac a a a analisar o comportamento de sistemas em relac o a ` leitura mem oria prim aria, o objetivo e a e escrita de valores em mem oria prim aria. O algoritmo Busca Sequencial visa analisar o de valores sequenciais em mem o comportamento de sistemas na recuperac a oria. Em o, foram selecionados tr virtude do diferente comportamento adotado para a ordenac a es algoritmos para troca de valores. Por exemplo, o Bolha tende a realizar mais trocas que o Selec a a oximas. o, e o Inserc o tende a realizar trocas mais pr
Na p agina http://www.dcc.ufmg.br/terra/sblp2010 encontra-se publicamente dispon vel o benchmark desenvolvido.
4

O algoritmo C opia de Arquivo consiste basicamente na leitura de um arquivo o em um outro arquivo. Logo, esse algoritmo estressa a bin ario e posterior gravac a es de entrada e mem oria secund aria disco r gido, no caso por meio de diversas operac o sa da (E/S). E, o algoritmo Multiplicac a o de Matrizes que possui a maior complexidade o a execuc o repetitiva tem o intuito de analisar o comportamento de sistemas em relac a a es matem de operac o aticas inteiras e decimais (ponto utuante). Por m, foi idealizado e desenvolvido um aplicativo completo chamado Simula que tem o intuito de realizar atividades fundamentais realizadas em aplicativos, tais como ` disco, ordenac es, operac es matem recurs oes, acesso a o o aticas etc. Sua funcionalidade consiste em, inicialmente, declarar e inicializar matrizes inteiras quadradas de 200 linhas o uniforme. Em seguida, o valor de cada e colunas (A e B) seguindo uma distribuic a o da matriz A e substitu o da posic a do pelo fatorial de seu valor e o valor de cada posic a substitu matriz B e do pelo seu valor na s erie de bonacci. Em seguida, as matrizes s ao convertida para um arranjo unidimensional que e multiplicadas e a matriz resultante e o e ent realizada uma busca sequencial procurando ordenado pelo algoritmo de selec a ao e encontrar um determinado valor. De forma sint etica, o Simula tem seu pseudo-c odigo descrito na Listagem 1.
1 2 3 4 5 6 7

x : = { 1 , 2 , 3 , . . . } / I n c r e m e n t a quando u t i l i z a d o / p a r a t o d o e l e m e n t o em vA [ 2 0 0 ] [ 2 0 0 ] f a c a f a t ( x mod 3 0 ) p a r a t o d o e l e m e n t o em vB [ 2 0 0 ] [ 2 0 0 ] f a c a f i b ( x mod 3 0 ) vAB : = mult ( vA , vB ) v [ 4 0 0 0 0 ] : = l i n e a r ( vAB ) selecao (v) s e q u e n c i a l ( v , x mod 3 0 )

Listagem 1. Pseudo -codigo do Aplicativo Simula

3. Comparativo das Linguagens

o, descreve-se uma an Nesta sec a alise comparativa da eci encia das linguagens. O ambi o da compilac o etc ente do experimento m aquina, vers oes, par ametros de customizac a a o 2.1, e a carga de trabalho j j a foram identicados e descritos na Subsec a a foi apresen tada na Subsec ao 2.2. A an alise comparativa consiste na avaliac ao do desempenho dos o do taalgoritmos do TerraBM, exceto o Simula que foi implementado para a denic a o do impacto das melhorias dos compiladores C/C++ manho da amostra e para a avaliac a importante men o do c o 4). E e Java no tempo de execuc a odigo gerado (realizada na Sec a o e o tempo de CPU5 utilizado por cionar que a m etrica utilizada para a experimentac a cada algoritmo, em contrapartida a diversos artigos que consideraram o tempo decorrido, o que pode levar a conclus oes incorretas [1]. 3.1. Determinando o Tamanho da Amostra o de observac es pareadas, o primeiro passo e determinar o tamanho da Para a realizac a o amostra para que os resultados possuam validade estat stica. A f ormula estat stica que
Na linguagem C, utilizou a estrutura rusage da biblioteca sys/resource.h e, na linguagem Java, utilizou-se a classe java.lang.management.ThreadMXBean. O c odigo completo para se medir o o pode ser observado nos arquivos fontes publicamente dispon tempo de execuc a veis.
5

 es permite determinar o tamanho da amostra considerando a quantidade de observac o preliminares (n), a m edia aritm etica (x), o desvio padr ao (s) dos resultados, a conanc a o student-t referente desejada (p), a taxa de erro considerada (r) e o valor da distribuic a inferior a 30) e transcrita a seguir [3]: (pois a amostra preliminar e tamanho da amostra = 100.t[p; n1] .s r.x (1)

o, foi denida uma conanc Inicialmente, para essa determinac a a de 99,9% e taxa 6 de erro de 0,05% . Desse modo, as vers oes do aplicativo Simula para C/C++ e para Java foram executadas 10 vezes. Em seguida, determinou-se o tamanho da amostra por meio o da f da resoluc a ormula supracitada cujos valores e resultados obtidos s ao apresentados na Tabela 2.
do Numero Tabela 2. Denic ao de Amostras

o Preliminares (n) Observac a es (x) M edia Aritm etica das Observac o Desvio Padr ao (s) t[p;r] = t[0,9995;9] Taxa de Erro (r) Tamanho da Amostra

C/C++ 10 29,4674 0,0021 4.781 0,05 1

Java 10 31,9720 0,0162 4.781 0,05 24

es de Como pode ser observado na Tabela 2, o desvio padr ao (s) das observac o nica execuc o em C/C++ garantiria C/C++ foi muito baixo, indicando que apenas um u a o. validade estat stica, o que retrata a estabilidade da linguagem e do ambiente de execuc a superior ao de C/C++, o n Por outro lado, como o desvio padr ao de Java e umero de amostras para validade estat stica para sistemas Java e de 24 observac oes. Logo, seguindo es como o tamanho da uma abordagem estat stica conservadora, adotou-se 24 observac o o pareada. amostra para a observac a es Pareadas 3.2. Observac o Calculado o tamanho da amostra, os seguintes algoritmos do TerraBM foram executados com seus devidos par ametros: Fibonacci: foi avaliado o desempenho para f ib(40) e f ib(45); Busca Sequencial: foi avaliado o desempenho para uma busca de um n umero es. O fato do tamanho do arranjo ser inexistente em um arranjo de 10E 6 posic o consideravelmente maior quando comparado com os outros experimentos se deve ao fato da complexidade desse algoritmo ser O(n); o de um Bolha, Selec a a a o e Inserc o: foi avaliado o desempenho para ordenac es sem repetic o de arranjo em ordem descendente de 30.000 e de 100.000 posic o a valores;
6

o de algoritmos [1, 3]. E uma conanc a altamente adequada em comparac a

 C opia de Arquivo (CP): foi avaliado o desempenho para c opia de um arquivo de 100MB. Para avaliar a melhoria proporcionada pela nova biblioteca de Java para o de streams, comparou-se o desempenho do algoritmo C/C++ com o manipulac a de Java utilizando java.io (IO) e utilizando java.nio (NIO); Multiplicac a o de Matrizes Inteiras (MMI) e Decimais (MMD): foi avaliado o o de uma matriz quadrada de tamanho 800 com uma desempenho da multiplicac a outra matriz de mesmo tamanho. A Figura 1 apresenta a m edia aritm etica (x) com o intervalo de conanc a (IC) o. Todos os algoritmos tiveram o mesmo ambiente de execuc o e do tempo de execuc a a foram executados 24 vezes. Diante disso, os resultados apresentados s ao estatisticamente v alidos com uma conanc a de 99,9% e com um taxa de erro de 0,1%.
Mdia Aritmtica do Tempo com IC (em segundos)
26.900

30
21.280

C Java

25 20 15 10

16.905

15.709

19.200

19.285

12.321 13.300

7.240 9.060 1.222 2.160 1.444 2.000 1.275 1.700 0.652 1.120 0.332 0.220

Seleo 100k

Seleo 30k

Sequencial 10g

Bolha 100k

Insero 100k

Bolha 30k

Insero 30k

Fibonacci 40

Fibonacci 45

CP 100m (NIO)

CP 100m (IO)

dos Algoritmos em C/C++ e Java do TerraBM Figura 1. Tempo de Execuc ao

3.3. An alise dos Resultados de se esperar que todos os algoritmos implementados em C/C++ sejam mais ecientes E o. Entretanto, o que seu correspondente em Java, justamente pelo processo de compilac a justicado por algoritmo Busca Sequencial apresentou melhor eci encia em Java. Isso e pelo menos duas raz oes: (i) a partir do Java 5, a JVM possui um recurso chamado compi o, em tempo de execuc o, do bytecode para lador Just In Time (JIT) que consiste na traduc a a c odigo de m aquina nativo de trechos de c odigo com grande custo de processamento [7]; (ii) Somente o compilador JIT n ao explicaria o desempenho ser melhor que C. Por isso, o din o) deu ao compilador mais suspeita-se que a compilac a amica (em tempo de execuc a o [9]. oportunidades para otimizac a

MMD 0.8k

MMI 0.8k

0.652 0.900

0.695 0.780

7.828

14.700

 es pareadas, foi aplicada sobre Com o intuito de validar os resultados das observac o a diferenc a das m edias aritm eticas um teste chamado t-test, com o objetivo de comprovar que os desempenhos dos algoritmos das duas linguagens s ao estatisticamente diferentes. o desse teste para cada par de observac es, foi poss Assim, ap os a conduc a o vel garantir que todos os algoritmos em C/C++ possuem desempenho signicativamente diferente do seu correspondente em Java.
Fibonacci 40 Fibonacci 45 Sequencial 10g Seleo 30k Seleo 100k Bolha 30k Bolha 100k Insero 30k Insero 100k CP 100m (IO) CP 100m (NIO) MMI 0.8k MMD 0.8k 34.01% 25.08% 87.79% 11.37% 8.75% 81.62% 39.79% -34.3% 33.39% 23.5% 64.89% 41.04% 30.33%

Relao C/C++ e Java

Figura 2. Percentual da Melhoria dos Algoritmos em C/C++ e Java

Ainda, para facilitar o racioc nio sobre os resultados e apontar o quanto melhor o do seu correspondente em Java, foram sumarizados os resultados aplicativo em C/C++ e sob a raz ao das m edias aritm eticas para cada algoritmo, conforme ilustrado na Figura 2. Conv em mencionar que a diferenc a tamb em foi calculada com base em uma conanc a de 99,9%. Assim, com base nos resultados apresentados nas Figuras 1 e 2, foram realizadas an alises por classe de algoritmo: ` pilha de execuc o: Mesmo Java possuindo uma arquitetura de pilha, o algoEstresse a a ritmo recursivo Fibonacci em Java possui desempenho aproximadamente um terc o pior que em C/C++. Contudo, a diferenc a caiu de 41,04% com n = 40 para 30,33% com n = 45. Experimentalmente, observa-se que a diferenc a cai com o aumento de n. ` mem o ao algoritmo Busca SeEstresse a oria prim aria - Busca de Valores: Em relac a quencial, Java teve desempenho quase 35% melhor que em C/C++. Pode-se dizer que o resultado foi um tanto quanto inesperado principalmente pela linguagem Java n ao possuir , o uso de indexac o em arranjos e inevit ponteiros para tipos primitivos, isto e a avel, o que o em C/C++, por meio de ponteiros. foi facilmente evitado, na implementac a Por outro lado, o resultado possibilitou as seguintes infer encias: (i) armar que mais lento que em C devido a n iterar um arranjo em Java e ao existir aritm etica de pontei observ correto. E o internamente; ros n ao e avel que o compilador de Java otimiza a iterac a

(ii) o compilador JIT foi utilizado na convers ao do lac o de procura. Arma-se isso devido o com arranjos pequenos, o desempenho de C/C++ foi superior ao ao fato que na execuc a utilizado somente quando o trecho de c de alto de Java, pois o compilador JIT e odigo e es em tempo de execuc o procusto de processamento [7]; (iii) suspeita-se que informac o a o din porcionadas pela compilac a amica de Java foram utilizadas, pois os outros recursos somente garantiriam um desempenho equipar avel, mas n ao melhor. ` mem Estresse a oria prim aria - Troca de Valores: As diferenc as entre os algoritmos o variaram de 8,75% at de ordenac a e 64,89%. A menor diferenc a ocorreu no algoritmo Inserc a a a entre as linguagens car mais o seguido do Selec o e Bolha. O fato de a diferenc evidente nos algoritmos Selec a umero de trocas de o e Bolha algoritmos com maior n o de valores indica que existe um gargalo signicativo em Java no quesito de alterac a valores em mem oria prim aria. ` n Al em disso, n ao se pode atribuir gargalo a ao exist encia de ponteiros, uma vez o que o algoritmo Busca Sequencial demonstrou que internamente Java otimiza a iterac a de arranjos. ` mem Estresse a oria secund aria: H a pouco tempo atr as, a API java.io foi muito criticada devido a seu desempenho ser bem inferior ao desempenho de outras linguagens [5, 6]. Por exemplo, no algoritmo C opia de Arquivo utilizando java.io, o desempenho de Java foi mais de 80% pior que o correspondente em C/C++. Contudo, ao ` s cr se utilizar a API java.nio biblioteca desenvolvida pela Sun em respostas a ticas de desempenho de java.io essa diferenc a caiu substancialmente, sendo agora pouco mais de 30%. diretamente inuenConv em mencionar que o desempenho de c opia de arquivos e ciado pelo tamanho do buffer utilizado. Assim, deniu-se o tamanho do buffer em 32KB tanto para os algoritmos em C/C++ quanto para os de Java. ` ULA: Em relac o aos algoritmos de estresse a ` ULA, o desempenho de Java Estresse a a bem inferior ao de C/C++. Por exemplo, no algoritmo Multiplicac e a o de Matrizes com valores inteiros, o desempenho de Java foi mais de 25% pior que o desempenho em C. No entanto, essa diferenc a vai para mais de 85% quando utiliza-se valores decimais. Assim, lenta em operac es aritm conclui-se que Java ainda e o eticas, principalmente quando os operandos s ao pontos utuantes. ` Validade do Estudo 3.4. Riscos a o de desempenho entre Java e C++ apresentada nesta sec o foi baseada em A comparac a a es que fazem parte do benchmark TerraBM. Procurou-se com um conjunto de aplicac o es importantes nas duas linguagens, incluindo esses programas exercitar diversas operac o ` mem ` mem es aritm acesso a oria principal, acesso a oria secund aria, operac o eticas etc. No es principais utilizaentanto, n ao se pode argumentar que esses aplicativos e as operac o o dos mesmos s das na implementac a ao representativos de qualquer programa que possa ser implementado em Java ou C++. Particularmente, em sua atual vers ao, o benchmark es para gerenciaTerraBM n ao inclui programas que fazem uso intensivo de operac o o, remoc o via coletor de lixo etc). mento de objetos (criac a a o de cada programa e, com base Adicionalmente, mediu-se os tempos de execuc a

nos resultados obtidos, foram formuladas hip oteses para explicar as diferenc as de desem es e explicac es denitivas penho observadas entre Java e C++. No entanto, comprovac o o para as diferenc as medidas nos experimentos devem demandar uma an alise detalhada dos es realizadas pelos compiladores. c odigos gerados e das poss veis otimizac o

o do Impacto das Melhorias dos Compiladores 4. Avaliac a

o, realiza-se uma an Nesta sec a alise do impacto das melhorias dos compiladores no o do c o a dois principais fatores: par tempo de execuc a odigo gerado em relac a ametros o da compilac o e vers de customizac a a oes do compilador. Em outras palavras, deseja-se o da compilac o e a vers avaliar o quanto os par ametros de customizac a a ao do compila o de sistemas. Para isso, foi realizado um projeto dor inuenciam no tempo de execuc a classicar a imestat stico conhecido como Projeto Fatorial 2k r cujo principal objetivo e o de sistemas. port ancia desses fatores no tempo de execuc a 4.1. Projeto Fatorial 2k r um tipo especial de projeto experimental estat Um Projeto Fatorial e stico que determina os efeitos de k fatores, cada qual com dois n veis [3]. Esse tipo de projeto merece uma discuss ao especial, pois seus resultados s ao de f acil an alise e ajudam consideravelmente o dos fatores pelo seu impacto na resposta. O Projeto Fatorial 2k r consiste na classicac a es, replicar todas as observac es r em, al em de observar todas as poss veis combinac o o k , tem-se 2 r observac es. Isso permite estipular intervalo de conanc vezes, isto e o a para es entre eles e ainda obter o impacto relativo ao erro os efeitos de cada fator, das interac o experimental. utilizado para determinar o efeito de k faSumarizando, o Projeto Fatorial 2k r e tores em que cada fator possui dois n veis em um experimento com uma conanc a p es. Um exemplo cl o do e com r replicac o assico desse tipo de projeto consiste na avaliac a impacto da mem oria e do processador no desempenho de um sistema. Os fatores seriam o um projeto fatorial 2k r, cada tamanho da mem oria e a velocidade do processador. Como e fator possui dois n veis, por exemplo, 1GB e 4GB para mem oria e 1GHz e 2GHz para o o desse projeto permite avaliar qual o impacto da mem processador. A soluc a oria e do processador no desempenho do sistema. Logo, permitindo denir qual investimento seria mais apropriado para otimizar o desempenho do sistema: mem oria e/ou processador [3]. o da Neste estudo, os fatores considerados s ao os par ametros de customizac a o (A) e vers compilac a oes do compilador (B), pois se deseja obter o impacto desses fato o de sistemas em cada linguagem. Similarmente ao processo res no tempo de execuc a experimental anterior, adotou-se a conanc a de 99,9% e, ainda seguindo uma abordagem es para ambas as linguagens. estat stica conservadora, adotou-se 24 replicac o o da compilac o, os n Para os par ametros de customizac a a veis se baseiam na o dos par exist encia (+1), mais especicamente na utilizac a ametros identicados e descritos o 2.1, e na n o padr na Subsec a ao exist encia (-1) que consiste no uso da compilac a ao da lin o de par o guagem. Isso permite que se avalie o quanto a utilizac a ametros de customizac a o impactam no tempo de execuc o de sistemas. Para as vers da compilac a a oes dos compilador, foram selecionadas as vers oes de cinco anos atr as (-1) e as vers oes mais recentes (+1). Mais especicamente, foram selecionadas as JDKs 1.5.0 22 e 1.6.0 20 para o modelo de regress ao de Java e os compiladores GNU GCC 4.0.4 e 4.5.0 para o modelo de regress ao

de C/C++. Isso permite que se avalie o quanto cinco anos de desenvolvimento de com o de sistemas. Com a denic o do problema, piladores impactam no tempo de execuc a a utilizou-se o seguinte modelo de regress ao n ao linear [3]: y = q0 + qA xA + qB xB + qAB xA xB + e (2)

o, qA indica Nesse modelo, q0 indica a m edia aritm etica do tempo de execuc a o do compilador, qB indica o efeito da vers o efeito dos par ametros de customizac a ao o entre os par o do compilador, qAB indica o efeito da interac a ametros de customizac a e a vers ao do compilador e, por m, e indica o efeito relativo aos erros experimentais. o n o ou n Ainda, xA e vel do fator A que pode ser +1 ou -1 dependendo da utilizac a ao de o da compilac o, xB e o n par ametros de customizac a a vel do fator B que pode ser +1 ou a vari -1 dependendo da vers ao do compilador utilizada. Por m, y e avel resposta. Para um melhor entendimento dos experimentos, a Tabela 3 apresenta as m edias o de cada uma das combinac es descritas anteriormente aritm eticas do tempo de execuc a o para C/C++ e Java.
do Projeto Fatorial 2k r Tabela 3. Medias aritmeticas dos tempos de execuc ao para C/C++ e Java
A A

GCC
(-1) (+1) (-1)

JDK
(+1)

(-1) B (+1)

o Sem otimizac a

4.0.4 61,388

4.5.0 59,088 29,467

1.5.0 22 43,408 37,388

1.6.0 20 34,354 31,975

o 27,636 Com otimizac a

A partir dos resultados, determinou-se o seguinte modelo de regress ao para a linguagem C/C++: yC/C ++ = 44, 395 15, 844xA 0, 117xB + 1, 033xA xB + e (3) o do modelo de regress de 44,395s; o Segue-se a interpretac a ao: o tempo m edio e o do compilador e de -15,844s; o efeito da vers efeito dos par ametros de otimizac a ao do de -0,117s; e o efeito da interac o entre os par o e a compilador e a ametros de customizac a de 1,033s. vers ao do compilador e o da variac o A partir do modelo de regress ao, pode-se calcular e entender a frac a a o explicada pelos par o da total causada por cada efeito. A frac a ametros de customizac a o foi de 99,57% e pela vers o explicada compilac a ao do compilador foi de 0,01%. A frac a o entre os fatores foi de apenas 0,42% e praticamente nada foi atribu pela interac a do importante mencionar que a frac o explicada pelos erros como erro experimental. E a praticamente nula devido ao desvio padr experimentais e ao dos algoritmos C/C++ serem muito baixos. A partir dos resultados, determinou-se o seguinte modelo de regress ao para a linguagem Java: yJAV A = 36, 781 2, 1xA 3, 617xB + 0, 91xA xB + e (4)

 o do modelo de regress de 36,781s; Segue-se a interpretac a ao: o tempo m edio e o do compilador e de -2,1s; o efeito da vers o efeito dos par ametros de otimizac a ao do de -3,617s; e o efeito da interac o entre os par o e a compilador e a ametros de customizac a de 0,910s. vers ao do compilador e o da variac o A partir do modelo de regress ao, pode-se calcular e entender a frac a a o explicada pelos par o da total causada por cada efeito. A frac a ametros de customizac a o foi de 24,06% e pela vers o explicada compilac a ao do compilador foi de 71,41%. A frac a o entre os fatores foi de 4,52% e praticamente nada foi atribu pela interac a do como erro experimental. 4.2. An alise dos Resultados A partir dos resultados obtidos para a linguagem C/C++, suspeita-se da estabilidade dos compiladores C/C++, uma vez que n ao vem apresentando grande melhoria de uma vers ao para outra. Isso se justica pelo fato dos compiladores GNU GCC j a terem 23 anos de desenvolvimento. Diante disso, conclui-se que, em busca de um melhor desempenho em o da compilac o, os C, mais esforc os devem ser dados aos par ametros de customizac a a quais representaram o efeito dominante. Em contrapartida, a partir dos resultados obtidos para a linguagem Java, foi cons o, uma vez que representatatado que os compiladores ainda est ao em constante evoluc a o. Isso era esperado j ram mais de 70% da melhoria do tempo de execuc a a que a linguagem relativamente nova. Java e o da compilac o Al em disso, pode-se perceber que os par ametros de customizac a a o. Contamb em s ao importantes, representando cerca de um quarto do tempo de execuc a o e bem inferior a ` quela resultante no modelo da linguagem C. Isto e , tudo, essa frac a ltima vers o foi o dobro do tempo na u ao do compilador C/C++, o tempo sem otimizac a o, uma diferenc com otimizac a a de quase 30s. Por outro lado, na linguagem Java, essa diferenc a foi de menos de 8%, uma diferenc a de menos de 3s. Isso leva a conclus ao o em sua de que os compiladores Java j a agregam diversos par ametros de customizac a o padr ` m o. compilac a ao, deixando-a bem pr oxima a axima otimizac a ltima vers Conv em mencionar que o desempenho otimizado da u ao do compilador de C/C++ foi inferior ao desempenho otimizado da vers ao do compilador de cinco anos ltima atr as. O motivo disso podem ser v arios, contudo dois podem ser mencionados: (i) a u o 0 vers ao do compilador C/C++ foi lanc ada h a pouco tempo e ainda est a na liberac a o 4 (4.0.4); (ii) nos 4.5.0 enquanto que a vers ao de cinco anos atr as parou na liberac a ltimos cinco anos, v es foram realizadas no intuito de sistemas serem otiu arias modicac o mizados para m aquinas 64 bits e multi-n ucleos, o que pode ter impactado o desempenho em m aquinas 32 bits de apenas um n ucleo, a qual caracteriza a m aquina utilizada pelo experimento. ` Validade do Estudo 4.3. Riscos a No estudo descrito, considerou-se apenas duas vers oes de compiladores C++ e duas vers oes de compiladores Java, com uma diferenc a de cinco anos entre cada um deles. Evidentemente, esse estudo poderia ser ampliado, considerando um n umero maior de vers oes de compiladores.

5. Trabalhos Relacionados
um assunto de grande interesse a ` academia. Logo, v Desempenho de linguagens e arios trabalhos cada qual com seu enfoque foram propostos. Inicialmente, Georges et al. o de desempenho podem estar se armam que as metodologias dominantes de avaliac a enganando e que diversos artigos podem estar apresentando conclus oes incorretas. Logo, o estaticamente rigorosa do desempenho da linguagem Java para realizam uma avaliac a diversos benchmarks validando seus resultados [1]. No entanto, n ao comparou o desempenho com outras linguagens. o a pesquisas comparativas, Martins e Botelho estudaram a evoluc o do Em relac a a desempenho da linguagem Java entre as suas vers oes e compararam o desempenho de o ao tempo de processamento e ao tempo de leitura sequencial Java com C++ em relac a o ao tempo de processamento n mais em disco concluindo que a diferenc a em relac a ao e t ao signicativa [5]. Contudo, nenhuma t ecnica estat stica foi utilizada e o espectro de es e relativamente pequeno. aplicac o o a otimizac o da linguagem Java, Reinholtz analisou a compilac o Em relac a a a poss din amica de Java e concluiu que e vel que Java tenha um desempenho melhor do o din es que C++, pois a compilac a amica fornece ao compilador Java acesso a informac o o que n em tempo de execuc a ao est ao dispon veis a um compilador C++ [9]. Em uma outra linha, Prechelt compara o desempenho de 40 diferentes es de um mesmo problema escritas por 38 diferentes desenvolvedores [8]. implementac o Diferenciando-se da an alise realizada pela maioria dos benchmarks, que comparam uma nica implementac o de um problema em C/C++ com uma u nica implementac o em Java. u a a o que ocorre entre as implementac es Com esse estudo, Prechelt concluiu que a variac a o de cada desenvolvedor supera a diferenc a de desempenho da linguagem em si.

es Finais 6. Considerac o
uma das suas maiores vantagens e, tamb A portabilidade da linguagem Java e em, o fator causador de uma de suas maiores cr ticas: desempenho. Desenvolvedores normalmente optam pela linguagem Java visando distribuir seus aplicativos para v arios sistemas ope de se esperar, querem a portabilidade sem abrir m racionais. Contudo, como e ao da eci encia de uma linguagem compilada como C/C++. Para avaliar o desempenho da linguagem Java, inicialmente, elaborou-se uma an alise comparativa entre as linguagens C/C++ e Java. Essa an alise utilizou toda o estat o dos experimentos e consistiu basicamente em fundamentac a stica para a validac a es pareadas de diversas classes de algoritmos que visam estressar certa regi observac o ao o, por exemplo, mem de execuc a oria prim aria, ULA, pilha etc. Em um segundo momento, foi elaborada uma an alise do impacto das melhorias o do c ltimos dos compiladores C/C++ e Java no tempo de execuc a odigo gerado nesses u k o a cinco anos. Essa an alise foi realizada por meio de um Projeto Fatorial 2 r em relac a o da compilac o. dois fatores: vers ao do compilador e par ametros de customizac a a ` s perguntas A partir desses estudos, formou-se argumentos para se responder a enunciadas no in cio deste estudo. A linguagem Java n ao tem sempre pior desempenho es em que o compilador JIT e utilizado e informac es que a linguagem C. Em situac o o o din o do c obtidas pela compilac a amica permitem a otimizac a odigo, o desempenho de

Java pode ser superior. Isso foi constatado pelo algoritmo Sequencial que obteve um de es de troca de valores sempenho quase 35% melhor. Al em disso, observou-se que operac o es aritm em mem oria prim aria e operac o eticas com pontos utuantes tem um desempenho pouco satisfat orio em Java. Logo, mais pesquisas devem ser conduzidas no intuito de es. melhorar o compilador Java para essas operac o o ao impacto das melhorias dos compiladores no tempo de execuc o Em relac a a do c odigo gerado, foi constatado que os compiladores Java est ao em constante aperfeic oamento, sendo sua nova vers ao respons avel por 70% da melhoria de desempenho. Isso contrasta com o resultado do compilador C, em que praticamente toda a o da compilac o. Isso indica melhoria foi proporcionada pelos par ametros de customizac a a o para uma nova vers que, em busca de um melhor desempenho em Java, a atualizac a ao uma boa opc o, enquanto que em C, mais esforc do compilador e a os devem ser dados aos o da compilac o. par ametros de otimizac a a Poss veis linhas de trabalho futuro incluem: (i) realizar uma an alise comparativa ltimos cinco anos, a m de obter um estudo entre todas as vers oes dos compiladores dos u o entre as vers da evoluc a oes; (ii) realizar uma an alise do comportamento dos compiladores em processadores 64 bits; (iii) realizar uma an alise do comportamento dos compiladores em m aquinas multi-n ucleos. Agradecimentos: Este trabalho foi apoiado pela FAPEMIG e CNPq.

Refer encias
[1] A. Georges, D. Buytaert, and L. Eeckhout. Statistically rigorous Java performance evaluation. SIGPLAN Not., 42(10):5776, 2007. [2] C. S. Horstmann and G. Cornell. Core Java, Volume I Fundamentals. Prentice Hall, 8 edition, 2007. [3] R. Jain. The art of computer system performance analysis: techniques for experimental design, measurement, simulation, and modeling. John Wiley & Sons, 1991. [4] J. P. Lewis and U. Neumann. Performance of Java versus C++, 2004. Dispon vel em: http://www.idiom.com/ zilla/Computer/javaCbenchmark.html. mais t [5] H. B. Martins and F. C. Botelho. Java n ao e ao lento. Revista Eletr onica de Iniciac a o Cient ca, 2008. [6] S. Microsystems. JSR 51: New I/O APIs for the Java platform, 2010. Dispon vel em: http://www.jcp.org/en/jsr/detail?id=51. [7] S. Microsystems. Performance features and tools, 2010. Dispon vel em: http://java.sun.com/developer/onlineTraining/Programming/JDCBook/perf2.html. [8] L. Prechelt. Technical opinion: comparing Java vs. C/C++ efciency differences to interpersonal differences. Commun. ACM, 42(10):109112, 1999. [9] K. Reinholtz. Java will be faster than C++. SIGPLAN Not., 35(2):2528, 2000.