Estudo do impacto de consumo de potência e desempenho na inserção de um Array Reconfigurável na arquitetura Femtojava Multiciclo

Transcrição

1 Estudo do impacto de consumo de potência e desempenho na inserção de um Array Reconfigurável na arquitetura Femtojava Mateus Beck Rutzig Universidade Federal do Rio Grande do Sul Instituto de Informática - Av. Bento Gonçalves, 95 Campus do Vale - Porto Alegre, Brasil mbrutzig@inf.ufrgs.br RESUMO O mercado de sistemas embarcados está em constante crescimento. O aumento da complexidade do software embarcado está demandando processadores mais poderosos. Uma maneira de aumentar o desempenho dos sistemas é trocar lógica seqüencial por lógica combinacional. Neste trabalho é explorado o espaço de projeto da inserção de um Array Reconfigurável em um simples microprocessador, tornando a plataforma praticamente Dataflow. 1. INTRODUCÃO Atualmente, o crescimento da produção de eletroeletrônicos faz com que a tecnologia se encontre cada vez mais presente em nosso cotidiano, facilitando as tarefas do dia-a-dia. Exemplos destes são celulares, PDA, tocadores de mp3, sistemas de alarmes e mecanismos de injeção eletrônica de combustíveis [1]. Estes dispositivos são denominados de sistemas embarcados, que cada vez mais disponibilizam serviços mais sofisticados como: acesso à Internet; tela colorida com gráficos animados; rádio; televisão; jogos, entre outros. Conseqüentemente, estas características fazem com que estes dispositivos necessitem de uma capacidade computacional ainda maior. Alguns problemas são encontrados quando este assunto é tratado em sistemas embarcados. Existem duas particularidades nestes dispositivos que necessitam de uma atenção especial: os sistemas embarcados, na sua grande maioria, são produzidos com o objetivo de diminuir de tamanho; e também, em sistemas embarcados portáteis, por estes serem geralmente dependentes de uma bateria, existe a necessidade dos mesmos permanecerem ligados o máximo de tempo possível sem necessitar de recarga. Assim, há a preocupação adicional pelo consumo de energia. Entretanto, quando a capacidade computacional do sistema aumenta a tendência é que ocorra também um crescimento da área do dispositivo e ao mesmo tempo um consumo maior de energia. Conclui-se então que o objetivo, em sistemas embarcados, não é focado somente em obter a máxima capacidade computacional, e sim obter o desempenho suficiente para atender aos requisitos da aplicação, economizando-se em potência. Com o crescimento da quantidade e a diversidade de dispositivos embarcados no mercado, a Sun Microsystems implementou uma tecnologia que portasse Java para sistemas embarcados. Assim Java tornou-se bastante atrativa para ser usada nestes sistemas, por obter características que facilitam a implementação de aplicativos para os mesmos. Dentre estas características está a sua portabilidade, assim, os sistemas implementados em Java podem ser simulados e testados em quaisquer plataformas para após ser implantado na arquitetura final. Outras características de Java são a robustez, segurança e a orientação a objetos. Por esta última característica, a modelagem e programação destes sistemas são facilitadas, visto que estes podem ser projetados em um nível mais alto de abstração, diminuindo o tempo de projeto. Por todas estas facilidades, Java está cada vez mais sendo utilizada em sistemas embarcados. É previsto que no mínimo 8% dos telefones celulares em 27 irão suportar Java [2]. Diversas técnicas de extração de paralelismo em nível de instrução (ILP) são encontradas na literatura, estas trazem um grande aumento de desempenho e diminuição de consumo de energia. No entanto, estas técnicas não são válidas para aplicações que não fornecem a extração de um desejável grau de paralelismo, devido a características da própria aplicação. Outra forma potencial de conseguir um aumento de desempenho e diminuição de consumo de energia é utilizar um array reconfigurável que faz a execução de um fluxo de instruções em um circuito totalmente combinacional.

2 Unindo a idéia de execução de fluxo de instruções em um Array Reconfigurável com tradução binária para detectar on-the-fly seqüência de instruções que podem ser executadas no array, se alcança ao mesmo tempo um aumento de desempenho mantendo compatibilidade de software. Neste trabalho, o processador FemtoJava é utilizado para ser alvo de exploração de espaço de projeto na inserção de um Array Reconfigurável em um simples microcontrolador. Assim tornando a arquitetura praticamente Dataflow. Na Seção 2, são demonstrados alguns trabalhos relacionados e exemplos de algumas arquiteturas reconfiguráveis. Uma breve descrição do processador Femtojava é demonstrada na Seção 3. O Array Reconfigurável e o Dynamic Instruction Merging são apresentados na Seção 4. Na Seção 5 são demonstrados os resultados de desempenho, energia, potência e área obtidos no trabalho proposto. Finalmente, na Seção 6 são feitas conclusões e citados alguns trabalhos futuros. 2. TRABALHOS RELACIONADOS Muitos trabalhos que utilizam um array reconfigurável para alcançar um melhor desempenho e diminuição de enrgia são encontrados na literatura. Processadores como Chiamera [3] e ConCISe [4] possuem um array reconfigurável firmemente acoplado ao core do processador. Nestes, o array nada mais é que uma unidade funcional adicional no pipeline do processador, compartilhando os meus recursos com as outras unidades. Por este motivo a lógica de controle se torna muito simples, diminuindo o overhead de comunicação entre o array e o resto do sistema. O processador Femtojava [5] possui um Array Reconfigurável de granularidade grossa, o mesmo utiliza um abordagem chamada Dynamic Instruction Merging para detectar on-the-fly os basic blocks que serão executados no array. Neste trabalho foi proposto a inserção de um array reconfigurável idêntico ao que é formalizado para o Femtojava em uma processador muito mais simples, que fornece a mesma arquitetura que o anterior, mas a sua organização é muito menos complexa. A família Femtojava é um exemplo de arquiteturas que foram criadas especificamente para sistemas embarcados, visando restrições de área e potência. A organização de memória é baseada na alocação de quadros (frames) como manda a especificação da linguagem Java. Além do mais, o Femtojava implementa o sistema de E/S mapeado em memória. Outras características do Femtojava são o conjunto reduzido de instruções, arquitetura Harvard, pequeno tamanho e facilidade de inserção e remoção de instruções. Assim, a proposta do trabalho é acoplar um processador simples, que praticamente só irá executar instruções de controle, em um array reconfigurável, tornando a arquitetura praticamente Dataflow. Diferentemente das propostas anteriores que acoplam um array em processadores mais complexos. 4. ARRAY RECONFIGURÁVEL E DIM A organização do Array reconfigurável proposta por [7] é ilustrada na Figura 1. A mesma é composta por células, cada célula contém unidades lógicas e aritméticas, load/store, deslocadores e um multiplicador. Nesta abordagem existe um mecanismo de detecção de basic blocks que serão executados no array on-the-fly, este é denominado Dynamic Instruction Merging[8] (DIM). 3. PROCESSADOR FEMTOJAVA O processador utilizado na abordagem foi o Femtojava [6]. Este é um processador que executa nativamente bytecodes Java, desta forma é um processador de pilha, já que a máquina virtual Java possui esta característica. Esta versão, diferentemente da versão, não possui nenhum abordagem que extraia paralelismo em nível de instruções. Figura 1- Array Reconfigurável [8]

3 O funcionamento da técnica ocorre da seguinte forma: enquanto o primeiro fluxo de instruções esta sendo executado no processador o DIM está detectando os basic blocks para futura execução no array. Quando houver a ocorrência de um basic block, este não será executado no processador e sim em um mecanismo mais eficiente, o Array Reconfigurável. A configuração dos basic blocks são armazenados em uma cache de reconfigurações. E o número de células podem ser variados de acordo com os requisitos e restrições do sistema. 5. RESULTADOS Para avaliar os resultados obtidos foi realizada uma comparação entre a arquitetura proposta e a arquitetura Femtojava dotada do mesmo array reconfigurável. Todos resultados foram validados através de simulação utilizando os seguintes benchmarks: compress, check, jess, raytrace, db, javac, mpegaudio, mtrt, jack, todos estes do pacote SPECjvm98; além de binary search, float sums, imdct, mp3, sequence search, bubble1, quick1 e select1. É importante ressaltar que os algoritmos propostos possuem características tanto control flow como data flow, fazendo com que se possa melhor explorar o espaço de projeto. Para todos os benchmarks apresentados anteriormente foram realizados experimentos com 1, 2, 3, 4 e 5 células no Array Reconfigurável, tanto para o Femtojava quanto para o Femtojava. Outra questão a ser observada é a penalidade por branches condicionais que é imposta ao Femtojava, então para realizar uma comparação imparcial foi utilizada uma penalidade de 5% para todos os resultados demonstrados nas próximas sub-seções. 5.1 Desempenho Primeiramente, na Tabela 1 pode ser observado todos os resultados obtidos nos benchmarks anteriormente citados em todos os experimentos executados para ambos processadores. A Figura 2 mostra o número de ciclos gastos com o Array Reconfigurável dotado de 3 células. Pode-se observar que em alguns benchmarks o Femtojava obtém um melhor desempenho comparado ao, este fenômeno é explicado pela diferença nas características das aplicações. Jess, db e Javac possuem uma porcentagem maior de instruções de controle e chamada de método, em relação ao total de instruções executadas, que o mp3. Aplicação como Jess favorecem o processador, pois instruções de controle e chamadas de métodos executam em um mesmo número de ciclos que no processador. Ou seja, quanto mais control flow for a aplicação menor será o ganho de ciclos do processador em relação ao. # ciclos jess db javac mp3 Figura 2- Número de ciclos com 3 células no Array A média de ciclos calculada para todos os benchmarks avaliados é demonstrada na figura 3, no eixo horizontal é variado o número de células do Array Reconfigurável. Pode-se observar nesta figura que o crescimento do número de células do Array faz com que ocorra uma maior diminuição do número de ciclos do processador em relação ao. Quando existe somente uma célula o número de instruções executadas no Array é menor do que cinco células, assim várias instruções que poderiam ser executadas no Array acabam sendo executadas no processador por falta de células. Este nicho de instruções (soma, deslocamentos, negações) é executado mais rapidamente no processador do que o. Entretanto, quando mais células são acrescidas ao sistema, a tendência é que a diferença de ciclos diminua entre os processadores pelo fato destas instruções passarem a ser executadas no Array Reconfigurável e apenas instruções de desvios e chamadas de métodos continuam sendo executadas no processador, sendo que nestas instruções ambos possuem o mesmo desempenho. # ciclos células Figura 3 Média de número de ciclos variando-se o número de células do Array Reconfigurável

4 Tabela 1 Desempenho, em número de ciclos, variando-se o número de células Uma célula Duas células Três células Quatro células Cinco células check compress jess raytrace db javac mpegaudio mtrt jack binary_search float_sum imdct mp seq_search bubble quick select Energia Na tabela 2 estão demonstrados o consumo de energia de todos os algoritmos propostos em todas as opções de quantidades de células no Array Reconfigurável executadas para ambos processadores. A figura 4 mostra a energia consumida para quatro benchmarks utilizando três células no array. Podese observar que, semelhante com o desempenho, alguns algoritmos possuem maior diferença de energia consumida no do que no. A razão é a mesma demonstrada anteriormente, a porcentagem de instruções de controle e de chamadas de métodos em alguns algoritmos é maior que em outros, favorecendo assim a sua execução no processador. Também pode-se notar na figura 4 e na tabela 2 que o processador consome, em todos os benchmarks, menos energia que o pipeline. Em benchmarks como jack o, com o mesmo número de células, consome 14% a mais de energia que o. Energia javac mpegaudio mtrt jack Figura 4 Energia consumida com o Array dotado de 3 células Na figura 5 é mostrado a média de consumo de energia de todos os benchmarks propostos, variando o número de células do Array Reconfigurável. Diferentemente da figura 3 de média de desempenho, a figura 5 ilustra que no aumento do número de células não ocorre uma elevação do consumo de energia do processador. Isto é explicado pelo fato de as instruções executadas no dotado do Array com cinco células acabam sendo, na sua maioria, instruções de desvios e chamadas de métodos, sendo que na execução destas o consome menos energia que o. Portanto, comparando as duas figuras discutidas anteriormente, o aumento no número de células provoca, no, um aumento de desempenho proporcionalmente maior que no e o consumo de energia diminui com uma grandeza similar em ambos. Energia 2,5E+13 2E+13 1,5E+13 1E+13 5E+12 células Figura 5 Média de energia consumida variandose o número de células do Array Reconfigurável

5 Tabela 2 Energia (x1 3 ) consumida pelos benchmarks variando-se o número de células Uma célula Duas células Três células Quatro células Cinco células check compress jess raytrace db javac mpegaudio mtrt jack binary_search float_sum imdct mp seq_search bubble quick select Como citado anteriormente, em todos os resultado mostrados são computados 5% de penalidade de desvios condicionais no. Isto deve-se ao fato da organização do possuir no seu estágio de busca de instruções na memória um buffer de 9 bytes. Este buffer é gerenciado de modo que se houver a possibilidade de inserir uma palavra de 4 bytes neste, esta é buscada da memória e alocada no buffer. Entretanto, quando um desvio ou uma chamada/retorno de método ocorre no processador, este buffer tem de ser esvaziado e acessos anteriores à memória de instruções são perdidos. Como a priori, os dados de entrada não são conhecidos pelo processador, quando um desvio condicional for executado pode ocorrer do mesmo ser ou não tomado. Entretanto, a porcentagem de desvios tomados variam dentre as aplicações, então para tornar a comparação imparcial, foi calculado três porcentagens diferentes de penalidades por desvios condicionais: 1,5 e zero. A figura 6 mostra a energia consumida com penalidade de esvaziamento do buffer com as penalidades calculadas. Ou seja, com penalidade 1% toma-se por principio que todos os desvios condicionais foram tomados e o buffer foi esvaziado. Com 5% tem-se que somente a metade dos desvios foram tomados e por fim %, nenhum desvio foi tomado, conseqüentemente nenhum acesso a memória de instruções foi desnecessário. Nota-se, nesta figura, que mesmo com % de penalidade o processador, em todas as configurações de células no Array, permanece com um ganho alto de consumo de energia comparado ao. Energia células Penalidade 1% Penalidade 5% Penalidade % Figura 6 Média de energia consumida com diferentes penalidades no em todas as configurações do Array 5.3 Potência A figura 7 mostra média de potência consumida pelos benchmarks em todas as configurações de células executadas. Nesta figura mostra-se que a potência consumida pelo é muito menor em todas as configurações do Array. Fato que se comprova pelos mesmos motivos citados anteriormente.

6 Na figura 8 e 9 são mostrados dados de energia e desempenho dos mesmos algoritmos executados no dotado do Array reconfigurável com 5 células e no dotado do mesmo com 1 célula. Nota-se que o desempenho, em ciclos, dos algoritmos é similar, até mesmo em alguns casos o executa em menos ciclos que o. Entretanto, a energia consumida pelo é maior em todos os casos, no benchmark seq_search esta diferença chega a 19.5 vezes mais que consumido no Potência Energia / Ciclos Ciclos 5 células Ciclos 1 célula Energia 5 células Energia 1 célula Energia / Ciclos raytrace mpegaudio mtrt jack Ciclos 5 células Ciclos 1 célula Energia 5 células Energia 1 célula Média Potência Média Potência células Figura 7 Média de potência consumida em todas as configurações do Array Figura 8 Energia e ciclos comparados entre os dois processadores 5.4 Área O simples acoplamento do array no processador causa um enorme aumento da área da plataforma. Como pode ser observada na figura 1, a retirada do e a inserção do processador traz uma diminuição de área proporcional a uma célula no Array Reconfigurável. Portanto, para o experimento anterior onde comparou-se o processador dotado de 5 células com o com um Array Reconfigurável de 1 célula o overhead de área do multiciclo não é de quatro células e sim de três pelo motivo explicitado anteriomente. VLIW 2 6. CONCLUSÕES E TRABALHOS FUTUROS Neste trabalho foi inserido um Array Reconfigurável em um simples microprocessador, tornando a arquitetura praticamente DataFlow. Foi observado que esta abordagem proposta traz benefícios energéticos comparados a abordagens anteriores. Além disso, desconsiderando compromissos com área, pode-se alcançar o mesmo desempenho de um processador mais complexo com um consumo menor de energia. Seguindo a mesma abordagem, é desejável obter estes mesmos resultados variando o tamanho e a política de substituição da cache de reconfigurações para observar qual o impacto que estas variações trazem para o desempenho, energia, potência e área do sistema. 7. REFERÊNCIAS CACHE RECONFIGURAÇÕES D.I.M. CACHE DADOS REDUÇÃO DE ÁREA!!! Figura 1 Blocos ilustrando a diferença proporcional de área dos diferentes componentes do Array Reconfigurável binary_search seq_search bubble1 quick1 select1 [1] Schlett, M. Trends in Embedded-Microprocessor Design. In Computer, vol. 31, n. 8, 1998, [2] G. Lawton, Moving Java into Mobile Phones, Computer, vol. 35, n. 6, 22, pp [3] Hauck, S., Fry, T., Hosler, M., Kao, J., The Chimaera reconfigurable functional unit. In Proc. IEEE Figura 9 Energia e ciclos comparados entre os dois processadores

7 Symp. FPGAs for Custom Computing Machines, Napa Valley, CA, 1997, [4] Kastrup, B., Bink, A., Hoogerbrugge, J., ConCISe: a compiler-driven CPLD-based instruction set accelerator. In Proc. 7th Annu. IEEE Symp Field-Programmable Custom Computing Machines, Napa Valley, CA, 1999, [5] Beck, A.C.S., Carro, L A VLIW Low Power Java Processor for Embedded Applications. December (23) [6] S. Ito, L. Carro, R. Jacobi, Making Java Work for Microcontroller Applications. IEEE Design & Test, vol. 18, no. 5, Set-Oct. 21, pp [7] Beck, A. C. S.., Carro, L. Dynamic Reconfiguration with Binary Translation: Breaking the ILP Barrier with Software Compatibility. In Design Automation Conference (DAC), 25 [8] Gomes, V.F., Beck, A.C.S., Carro, L. Trading Time and Space on Low Power Embedded Architectures with Dynamic Instruction Merging, In Journal of Low Power Eletronics, Vol. 1, 1-1, 25.