Avaliação de Desempenho da Execução de Programas C# em Ambientes.NET - SSCLI 2.0,.NET 2.0 e.net 3.0

Transcrição

1 Avaliação de Desempenho da Execução de Programas C# em Ambientes.NET - SSCLI 2.0,.NET 2.0 e.net 3.0 Guilherme Amaral Avelino Universidade Federal de Pernambuco(UFPE) gaa@cin.ufpe.br Resumo A Microsoft, visando a divulgação e o estudo do framework.net, disponibiliza uma versão de código aberto para esta plataforma. Implementando o padrão ECMA-334 e ECMA-335, respectivamente a descrição da linguagem C# e da CLI, o SSCLI (Shared Source Common Language Infrastructure) representa uma ferramenta em potencial para estudo acadêmico não só da plataforma.net, como também, das tecnologias nela empregadas. Embora o SSCLI seja uma representação fiel do padrão.net especificado pela ECMA, esta não é a versão comercial da Microsoft. Visando uma comparação do desempenho do SSCLI com as versões comerciais.net2.0 e.net3.0, neste artigo apresentamos uma análise da execução de arquivos escritos em C#, tendo em vista o uso de generics, delegates e tail-calls. 1. Introdução Tentando tornar a plataforma.net um padrão para desenvolvimento de aplicativos a Microsoft submeteu a European Computer Manufactures Association (ECMA) especificações da linguagem C# e da Common Language Infrastructure (CLI), baseadas no.net Framework. Em dezembro de 2001 estas especificações foram aprovadas, surgindo assim, os padrões ECMA-334 que especifica a linguagem C# e ECMA-335 para a CLI. Estes padrões descrevem as características mínimas necessárias para implementação do ambiente.net, o que permitiria a criação de aplicativos portáteis que poderiam ser executados em qualquer sistema operacional e hardware para o qual tenha sido desenvolvida uma plataforma que siga estes padrões. Seguindo estes padrões a Microsoft criou o SSCLI (Shared Source Commum Language Infrastructure), também conhecido como Rotor, que é uma versão de código aberto disponível para Windows XP e FreeBSD. O SSCLI possui, além das implementações da CLI e de um compilador C#, ferramentas, utilitários, classes adicionais e exemplos. O SSCLI, entretanto, é uma versão apenas para estudo. Para uso comercial a Microsoft disponibiliza o.net Framework, atualmente na versão 3.0. Umas das vantagens da plataforma.net é o fato de ela dar suporte a múltiplas linguagens, tais como C#, VB.NET, C++ e JScript. Este suporte pode ser melhor compreendido entendendo o processo de compilação deste ambiente que é dividido em duas etapas: 1. compilação do programa escrito em uma linguagem suportada para a Commum Intermediate Language (CIL), também conhecida como Microsoft Intermediate Language (MSIL); 2. compilação deste código intermediário sob demanda para a arquitetura alvo, através do compilador Just In Time (JIT). Desta forma a plataforma deixa o caminho aberto para que novas linguagens sejam incorporadas, através da criação de compiladores que gerem código CIL. Para que isto seja possível é necessário que 1

2 as características e particularidades das linguagens possam ser representadas na CIL. As formas como tais características são representadas bem como o ambiente implementa tais estruturas determinam o desempenho da linguagem. Os testes realizados foram feitos utilizandos três códigos diferentes, cada um contemplando uma característica importante da plataforma.net que é útil para uma implementação eficiente de linguagens funcionais. Esta metodologia foi adotado devido a utilização deste trabalho como base para melhorias na implementação do projeto Haskell.NET. Mais informações a respeito do projeto Haskell.NET pode ser visto em [1] e [3] Metodologia Os códigos utilizados nos testes foram colhidos na internet, representando porções específicas de benchmarcks mais completos ou simplesmente códigos que fazem uso intensivo das características aqui analisadas. Alguns códigos tiveram de ser alterados de modo a exibir o tempo gasto em suas execuções e a se adequarem as necessidades deste estudo. Mais detalhes serão fornecidos na apresentação dos códigos utilizados. Todos os testes foram executados em um computador com processador Pentium IV de 3.0 GHZ e 1MB de Cache, 512MB de memória RAM e HD de 80 GB. O sistema operacional utilizado foi o Windows XP Service Pack 2. Inicialmente coesistiram na mesma máquina as plataformas.net2.0 e o SSCLI2.0. Após os testes nestas duas foi feito o upgrade da plataforma.net2.0 para.net3.0 para a realização dos testes nesta ultima. Antes da execução dos testes foram retirados os processos que não fossem essenciais, bem como, o cabo de rede para evitar interferências externas. Cada exemplo foi executado 20 vezes em cada uma das implementações, de modo, a obter uma amostra significativa. Para automatizar a execução dos programas foram utilizados arquivos em lote do windows (.bat). A coleta dos dados ficou a cargo de scripts AWK[4], executados no ambiente cygwin, que varreram os arquivos gerados retirando apenas os dados relevantes. Para análise dos resultados foram utilizadas as ferramentas de análise de dados do Microsoft Excel. Sendo gerado os histogramas das amostras e as médias sem a influência dos outliers. A retirada dos outliers é uma atitude justificada devida a possíveis interferências de outros processos que estejam rodadando na máquina e a possíveis compilações em tempo de execução pelo compilador JIT. 2. Coleta e Análise dos Dados Segundo a metodologia descrita a realização da coleta e análise dos dados foi dividida em três partes: Generics, Delegates e Tail-Calls, correspondendo as características testadas neste artigo. Na apresentação dos resultados serão mostrados apenas as médias das 20 execuções, retirados possíveis outliers encontrados Generics Generics, também conhecida como polimofismo paramétrico é uma técnica bastante difundida nas linguagens funcionais, sendo posteriormente incorporada a linguagens imperativas (templates em C++) e orientadas a objetos utilizando supertipos comuns (Ex: Object em versões mais antigas de JAVA e da CLI). Vale ressaltar que neste artigo não será realizada a comparação de desempenho entre estas técnicas de representação de polimorfismo paramétrico, será avaliado apenas o desempenho de generics implementado nas plataformas aqui estudadas. Segundo [10], uma unidade genérica é uma unidade do programa que é parametrizada em relação a uma entidade da qual ela depende. A instanciação de uma unidade genérica gera uma unidade qualquer do programa, na qual cada um dos parâmetros formais genéricos são substituídos por um argumento. 2

3 Na prática com Generics podemos criar estruturas (classes, funções, etc) que podem trabalhar sobre diversos tipos de dados. O tipo de dado só será conhecido quando esta estrutura for instanciada e o tipo genérico for substituído pelo tipo desejado Código Utilizado Para o teste com Generics foi utilizado o SciGMark que está disponível para download nas linguagens C#, C++, Java e Aldor em http : // O SciGMark é uma variação, utilizando generics, do benchmark de aplicações científicas e numéricas SciMark[8]. Para uma comparação entre as implementações de generics em várias linguagens utilizando o SciGMark e deste com a versão sem generics, veja [5]. O benchmark SciGMark faz a medição da execução de vários kernels, pequena parte de um programa real geralmente a parte que faz uso computacional mais intenso, e gera uma média da pontuação obtida em MFlops (milhões de operações de ponto flutuante por segundos). Os kernels incluídos são Fast Fourier transform (FFT), Jacobi successive over-relaxation (SOR), Monte Carlo integration, Sparse matrix multiply e Dense LU matrix factorization. Detalhes a respeito destes algoritimos podem ser visto em [8] e [6] Resultados Os valores obtidos podem ser observados na Tabela 1. São apresentados os valores em MFlops obtidos para cada um dos testes e a médias deles nas três plataformas. FFT SOR Monte Carlo SPARCE LU Média.NET 2.0 6, , , , , ,0665.NET 3.0 6, , , , , ,0806 SSCLI 2.0 1,7442 4,5967 3,3829 5,3718 3,0340 3,6259 Tabela 1: Generics (Mflops) Na Tabela 2 é apresentada a relação entre os valores obtidos em cada uma das plataformas. É possível observar que a os valores obtidos nas plataformas.net2.0 e.net3.0 são praticamente os mesmos, apresentando uma variação mínima. Na comparação entre as plataformas.net2.0 e o SSCLI, entretanto, a variação dos resultados foi significativa chegando a valores 7,4503 vezes menor para o kernel Sparce e de 5,8099 na média dos testes. FFT SOR Monte Carlo SPARCE LU Média.NET2.0 x.net3.0 1,0000 0,9956 1,0000 1,0000 0,9999 0,9993.NET2.0 x SSCLI 3,5211 4,4442 5,9605 7,4503 6,1224 5,8099 Tabela 2: Generics (Relação entre os valores obtidos) 2.2. Delegates Delegates são estruturas de dados semelhantes a ponteiros só que, diferentemente destes, delegates são type-safe. Em C# delegates são classes capazes de encapsular referencias para métodos permitindo, desta forma, que métodos recebam como argumento referências para outro métodos. Outra vantagem de delegates em relação a ponteiros é que um delegate pode referenciar mais de um método. 3

4 Os métodos referenciados por um delegate são mantidos em uma lista interna e são chamados de uma só vez quando chamamos o método Invoke, sendo executados de acordo com a ordem de inserção no delegate Código Utilizado Para fazer o teste utilizando delegates foram feitas modificações no benchmark Invokebencharking[2]. Este programa oferece três formas diferentes de invocaçãos de uma função - chamada direta, delegates e via reflection. Utilizando delegates é criado um delegate para cada um dos quatros métodos descritos a seguir: StaticDelegateWithoutParams() método estático que não recebe parâmetros. StaticDelegateWithParams(int i, int j, int k) método estático com três parâmetros. DelegateWithoutParams() método não estático, sendo referenciado pelo delegate através da instância da classe a qual ele pertence. DelegateWithParams(int i, int j, int k) método não estático com três parâmetros. Todos os quatros métodos possuem o mesmo código (count++), que faz apenas o incremento do contador da quantidade de vezes que o método é executado. Nos nossos testes estabelecemos que cada um dos métodos seriam invocados vezes. Dentre as modificações realizadas no benchmark original a principal foi a retirada de todas as referências a classe System.Timers, pois com ela o programa não funcionava no SSCLI. Provávelmente, o SSCLI não possui a biblioteca que implementa esta classe. Com isto, tivemos de mudar a forma de avaliação feita pelo código que era dada em número de execuções em um determinado intervalo de tempo, controlado pela classe Timer. No modelo atual é passado ao programa o número de vezes que cada método deve ser invocado e como resultado temos o tempo gasto em milissegundos Resultados Os resultados obtidos neste teste podem ser visualizados na Tabela 3. A tabela mostra que, utilizando delegates, a invocação da instancia de métodos é em geral mais rápida do que a invocação de métodos estáticos. A exceção foi observada apenas na execução sem parâmetros no ambiente SSCLI, onde o tempo gasto pelo método instanciado foi levemente superior. Static.NET , , , ,8330.NET , , , ,2493 SSCLI , , , ,5781 Tabela 3: Invocação com delegates (Milissegundos) Mais uma vez, como podemos observar na Tabela 4, os valores dos testes nas plataformas.net2.0 e.net3.0 são equivalentes, apresentando variações pouco significantes. Já na comparação com o SSCLI os valores são muito superiores, chegando a gastar um tempo 216 vezes superior. 4

5 Static.NET2.0 x.net3.0 1,0132 1,0011 0,9823 1,0103.NET2.0 x SSCLI 149, , , ,6574 Tabela 4: Invocação com delegates (Relação entre os valores obtidos) Devido a elevada diferença apresentada nas comparações entre os resultados das plataformas.net2.0 e SSCLI foram feitos testes nos quais são efetuadas chamadas diretas aos métodos, para verificar se a implementação de delegates em SSCLI seria a responsável por tamanha diferença. Como mostra a Tabela 5 os valores para chamadas diretas são de duas a três vezes mais rápidas nos ambientes.net 2.0 e 3.0 e praticamente a mesma coisa no ambiente SSCLI. Static.NET , , , ,0833.NET , , , ,0833 SSCLI , , , ,6753 Tabela 5: Chamada direta a métodos (Milissegundos) A Tabela 6 mostra que a chamada direta nos ambientes.net 2.0 e 3.0 gastam o mesmo tempo e que no ambiente SSCLI o tempo gasto é 385 vezes maior em todos os casos quando comparado com.net2.0. Static.NET2.0 x.net3.0 1,0000 1,0000 1,0000 1,0000.NET2.0 x SSCLI Tabela 6: Chamada direta a métodos (Relação entre os valores obtidos) Estes resultados mostram que a chamada a métodos no ambiente SSCLI é extremamente mais lenta do que nos.net 2.0 e 3.0. Fica evidente também que esta discrepância não é devia a implementação de delegates, uma vez que, para chamadas direta aos métodos a diferença percentual é ainda maior Tail Calls Tail-Call é um mecanismo de chamada de função que visa eliminar o consumo de stack-frames da seguinte forma: sempre que uma chamada é executada ao final de uma determinada função, o frame atual é descartada, sendo imediatamente substituído pelo novo frame. Assim evita o crescimento exagerado da pilha. Este recurso é bastante útil em linguagens funcionais para evitar o estouro da pilha, uma vez que tais linguagens são essencialmente recursivas Código Utilizado O código utilizado neste teste pode ser encontrado em http : // Este código executa um número n de vezes a chamada a um método utilizando tail-call e sem utilizar 5

6 tail-call. O método realiza um cálculo simples vezes. Como C# não suporta tail-calls, embora a CLI suporte, o código contendo o método deve ser primeiramente compilado para MSIL para que seja inserido o prefixo.tail antes da chamada ao método de uma das execuções e posteriormente compilado para código executável utilizando o compilador Ilasm Resultados Os tempos gastos na execução com e sem tail-calls são apresentados na Tabela 7. O tempo gasto na execução com tail-calls, em comparação com a execução sem tail-calls, é um pouco maior que o dobro nos ambientes.net 2.0 e 3.0 e 40% maior para o SSCLI. Sem Tail-Call Com Tail-Call.NET 2.0 5, ,1929.NET 3.0 5, ,1984 SSCLI , ,1437 Tabela 7: Tail-Calls (Segundos) A Tabela 8 mostra que as plataformas.net 2.0 e 3.0 gastam tempo semelhantes com relação a chamadas com e sem tail-calls. Já na comparação com o SSCLI o tempo gasto é cinco vezes maior para as chamadas sem tail-calls e um pouco maior que três vezes para chamadas com tail-calls. Sem Tail-Call Com Tail-Call.NET2.0 x.net3.0 1,0001 1,0004.NET2.0 x SSCLI 5, Tabela 8: Tail-Calls (Porcentagem) 3 Conclusões e Trabalhos Futuros O plataforma Microsoft.NET 3.0 (antiga WinFX) representa o novo modelo de programação de código gerenciado para Windows. Ela combina o poder da plataforma.net 2.0 com quatro tecnologias novas: Windows Presentation Foundation (WPF), Windows Communication Foundation (WCF), Windows Workflow Foundation (WF)e Windows CardSpace (WCS, antigo InfoCard ). Nos testes aqui realizados foi demonstrado que quanto a uso de generics, delegates e tail-calls não foi feita nenhuma alteração que melhorasse a plataforma em relação a sua antecessora a.net2.0. Tais resultados nos levam a crer que a única diferença entre as plataformas.net2.0 e a 3.0 é o acréscimo das bibliotecas que provêm as quatros novas tecnologias descritas anteriormente, permanecendo a mesma CLR (Commum Language Runtime) sem nenhuma melhoria. Na avaliação do SSCLI 2.0 ficou evidenciado que o foco dado a esta plataforma não é o desempenho. Como o foco desta versão não é o uso comercial, e sim o estudo da plataforma, complexidades extras que poderiam melhorar o desempenho desta foram deixadas de lado para que se pudesse focalizar a legibilidade e entendimento da plataforma e das tecnologias nela empregada. No geral o desempenho no SSCLI foi de 3 a 6 vezes pior do que nas versões comerciais, o que é aceitável para uma versão não comercial cujo foco não é o desempenho. A exceção é a chamada a métodos, onde o desempenho foi de 100 a 300 vezes pior seja com o uso de delegates ou com chamadas direta. Outra característica que foi possível observar é a ausência, no SSCLI, de algumas bibliotecas que fazem parte das versões comerciais. 6

7 Entretanto, para uso no meio acadêmico a SSCLI é uma poderosa ferramenta, pois tem seu código aberto e liberado para estudo e possíveis alterações, desde que não utilizados para fins comerciais. A possibilidade de se poder alterar suas características pode justificar sua utilização ainda que em detrimento do desempenho. Desta forma como sugestão para trabalhos futuros destaca-se o estudo de técnicas de otimização que pudessem melhorar o desempenho do SSCLI, tendo em vista principalmente a chamada de métodos pois este demonstrou ser o principal gargalo no desempenho da plataforma. Outra sugestão é expandir os testes aqui realizados de forma a contemplar outras características destas plataformas tais como desempenho do coletor de lixo e do compilador Jitter. Referências [1] The haskell.net project. haskell/haskelldotnet/. [2] Marc Clifton. Benchmarking direct, delegate and reflection method invocations. [3] Monique Louise de Barros Monteiro. Integrando haskell à plataforma.net. Master s thesis, Universidade Federal de Pernambuco. Centro de Informática, Abril [4] Dale Dougherty and Arnold Robbins. sed & awk [5] Laurentiu Dragan and Stephen M. Watt. Performance analysis of generics in scientific computing. University of Western Ontario. Ontario Research Centre for Computer Algebra, [6] Laurentiu Dragan and Stephen M. Watt. On the performance of parametric polymorphism in maple. Technical report, University of Western Ontario. Ontario Research Centre for Computer Algebra, [7] Kevin John Gough. Compiling for the.net Commom Language Runtime (CLR). Prentice Hall PTR, [8] Roldan Pozo and Bruce Miller. Scimark 2.0 benchmark, [9] David Stutz, Ted Neward, and GeoffShilling. Shared Source CLI. O Reilly, [10] David Anthony Watt. Programming Language Design Concepts [11] Nick Wienholt. Maximizing.NET Performance