Algoritmo para carga dinâmica de tarefas em processadores heterogêneos

Transcrição

1 Algoritmo para carga dinâmica de tarefas em processadores heterogêneos Daniel Barcelos Emilena Specht Resumo Este artigo apresenta uma versão do algoritmo threshold accepting (TA) para escalonamento de tarefas em processadores heterogêneos. O TA foi implementado em software e hardware, e ambas versões foram comparadas em termos de área, potência, energia e desempenho. A fim de validar o funcionamento do TA, foi desenvolvido um software em Java que simula a alocação de tarefas, com custos de desempenho, energia ou potência previamente conhecidos, em dois processadores FemtoJava. Resultados mostram que a versão do TA em software é mais de 200 vezes mais dispendiosa do que o TA em hardware, tanto em termos de desempenho quanto em área e energia. Em sua funcionalidade, a execução com escalonamento por TA se aproxima da execução por escalonamento estático, com variações que não ultrapassam 4%. Introdução As limitações de consumo e área existentes nos sistemas embarcados tornam necessárias novas soluções nesse âmbito. Com o surgimento de circuitos e plataformas multi-processadas, novas abordagens foram criadas. Porém, quando se trata de processadores heterogêneos, ainda não existe uma solução definitiva para o problema de utilizar os processadores presentes da melhor maneira possível. Em sistemas SMP (Simetric Multi- Processing) a tarefa de escalonamento pode se dar pelos algoritmos convencionais, já que todos os processadores possuem o mesmo poder de processamento. Basicamente, assume-se que existe apenas um único processador com uma vazão de processamento multiplicada pelo número de núcleos existentes. Caso os processadores sejam heterogêneos, a análise se torna mais complicada. Cada processador pode realizar determinadas tarefas de maneira mais eficiente se comparado aos demais. Em compensação, podem existir tarefas que, se executadas em um processador não indicado, se tornem extremamente dispendiosas em termos de tempo e/ou energia. Esse artigo apresenta uma proposta de solução para o segundo caso exposto. Tal método é baseado em um algoritmo estocástico, o Accepting (TA). São apresentados resultados de simulações onde métricas de desempenho, energia e potência foram consideradas, em casos particulares. O cenário de simulação supõe dois processadores com o mesmo conjunto de instruções, porém organizações diferentes. Os processadores utilizados nas análises são do tipo FemtoJava [6]. Para a obtenção das métricas de custo das tarefas utilizadas como benchmarks foi utilizado o estimador de potência Caco-PS [7][9]. Accepting O algoritmo Accepting (TA) é uma variação do Simulated Annealing (SA) [][2] proposto por Dueck e Scheuer [3] em 990. Analogamente ao SA, o TA faz uso do conhecimento do comportamento das moléculas ao serem congeladas, mas faz uma simplificação no sentido de substituir a curva exponencial de aceitação por um threshold decrescente a uma razão constante. Uma versão estendida do TA foi proposta por Hu et al. e é denominada Old Bachelor Acceptance [4]. Figura Funcionamento do TA

2 O princípio de operação do TA é mostrado na Figura. A partir de uma solução inicial qualquer ele provoca pequenas perturbações em busca de melhores soluções. A cada iteração, o algoritmo escolhe de forma aleatória um processador para executar uma determinada tarefa. Em dois casos específicos a nova solução é aceita: caso ela seja melhor que a anterior e caso ela seja pior, mas esteja dentro do intervalo de aceitação, limitado superiormente pelo threshold. A próxima iteração assumirá um threshold menor e assim sucessivamente. Dessa maneira, soluções piores que as atuais são cada vez menos aceitas e, se a diminuição do threshold a cada iteração for infinitesimal, a solução ótima é encontrada, obviamente para isso seria necessário um tempo de computação infinito. Este trabalho não utiliza o TA a fim de encontrar uma solução ótima, mas aproveita o fato do TA provocar perturbações para obter uma solução aceitável. Isto porque, aplicando ao caso da alocação de tarefas, uma solução conhecida seria a solução ótima estática, o conjunto da melhor solução para cada tarefa individualmente, considerando uma determinada métrica. Mas esta solução não leva em consideração a ocupação dos processadores, por exemplo, que pode fazer com que a solução ótima estática não seja a melhor solução para uma execução em um dado instante de tempo. Uma desvantagem do TA é considerar apenas uma métrica para alocar as tarefas. Seria possível promover um estudo para determinar uma forma de contemplar mais de um dado simultaneamente (número limite de ciclos para executar um número x de tarefas, considerando ainda a eficiência energética, por exemplo), mas essa abordagem foge do escopo deste trabalho. TA em Hardware vs. TA em Software Independentemente do tipo de implementação, é importante que um escalonador de tarefas não consuma muitos recursos. Caso este seja realizado via software e o processador em que execute seja também utilizado para computar as demais tarefas, quanto menor for a fatia de processamento por ele consumida, melhor. Ainda rodando em software, mas em um processador dedicado, espera-se que ele consuma o menos possível de outros recursos como área, energia e potência. A decisão por realizar o escalonamento em hardware, apesar da maior complexidade do projeto e menor flexibilidade, provém de uma eventual grande vantagem na relação custobenefício que essa última solução leva em relação às anteriormente mencionadas. Os gráficos de desempenho, energia, potência e área das soluções implementadas são apresentados na Figura 2. A fins de comparação, no cálculo de desempenho e consumo de energia do algoritmo em hardware e software foi considerado o pior caso, em que o TA executa o número máximo de iterações (200). Figura 2 Comparação das soluções implementadas Como não há uma implementação do FemtoJava VLIW disponível em VDHL, a área ocupada pela solução VLIW não foi calculada, mas presume-se que ela seja ainda superior à solução utilizando o Pipeline. Para o cálculo da potência do algoritmo em hardware, a ferramenta Leonardo Spectrum[5] extraiu o esquemático dos arquivos VHDL do TA, e a partir dos esquemáticos foi estimado o número de chaveamentos, considerando que a taxa de chaveamentos é de 50%. As soluções em software assumem processadores dedicados exclusivamente ao escalonamento. Adotou-se essa estratégia devido ao fato do tempo de execução do TA no pior caso ser superior ao tempo de execução de qualquer uma das outras tarefas usadas como benchmarks, o que inviabiliza a execução do TA em um processador que não seja dedicado. Todas as implementações consideram que o escalonamento será realizado considerando apenas dois processadores heterogêneos e que até 255 tarefas poderão existir ao mesmo tempo.

3 Simulação do TA Para avaliar a utilidade do TA no escalonamento de tarefas, foi simulada uma rede com dois processadores FemtoJava e 5 tarefas independentes umas das outras que deveriam ser executadas. As tarefas são benchmarks de tamanhos variáveis e propósitos diferentes, que utilizam diferentes instruções. A granularidade do paralelismo é grossa, ou seja, as tarefas não são divididas, e para cada tarefa há um processo. Uma vez que o processo inicia sua execução em um processador, o mesmo não é interrompido até o fim da computação da tarefa. Dois estudos de caso foram desenvolvidos: o primeiro utiliza um processador FemtoJava pipeline e um FemtoJava multiciclo para compor a rede, enquanto o segundo estudo de caso contempla a execução das tarefas em um FemtoJava pipeline e um FemtoJava VLIW com 2 instruções por palavra. O TA escalona as tarefas com base em seu custo em ciclos, potência média dinâmica e energia dinâmica para cada versão do FemtoJava utilizada na rede. Tais dados, para 3 tarefas, foram obtidos previamente pelo grupo através da ferramenta CACO-PS [8]. As duas tarefas restantes, cujos custos também foram obtidos através do CACO-PS, são o próprio TA em software e o algoritmo pseudo-aleatório que é utilizado pelo TA. Os benchmarks e seus custos em ciclos para cada versão do FemtoJava são apresentados na Tabela. Tabela para executar cada tarefa Multiciclo Pipeline VLIW Sin - Cordic Sin - Table Sort - Bubble Sort - Select Sort - Insert Sort - Quick Search - Binary Seach - Sequencial IMDCT IMDCT u IMDCT u IMDCT u Floating Point Sums Random TA média O multiciclo é o processador que mais consome ciclos para executar cada uma das tarefas, já que executa apenas uma instrução por vez. O pipeline é mais eficiente que o multiciclo para todas as tarefas, e o VLIW, por sua vez, mais eficiente que o pipeline, já que é capaz de extrair paralelismo das tarefas em nível de instrução e executar em média mais de uma operação por ciclo. A Tabela 2 apresenta os benchmarks e seus respectivos consumo de energia (em chaveamentos) em cada processador FemtoJava. Tabela 2 - consumida por cada tarefa (CG) Multiciclo Pipeline VLIW Sin - Cordic Sin - Table Sort - Bubble Sort - Select Sort - Insert Sort - Quick Search - Binary Seach Seq IMDCT IMDCT u IMDCT u IMDCT u Float. P. Sums Random TA média O multiciclo é o processador com maior consumo de energia para todas tarefas. Isto é devido ao fato da pilha do multiciclo ser implementada na memória RAM, enquanto a pilha dos outros processadores é implementada em banco de registradores. Como em síntese o VLIW é uma composição de dois ou mais pipelines em um processador, era esperado que o consumo de energia do VLIW fosse maior do que o do pipeline. No entanto, a versão do VLIW utilizada aplica uma técnica de reutilização de acessos à memória [8], reduzindo a energia a ponto de, em algumas tarefas, ser inferior à energia consumida no pipeline. Tabela 3 - Potência consumida por cada tarefa Potência (CG/ciclo) Multiciclo Pipeline VLIW Sin - Cordic Sin - Table Sort - Bubble Sort - Select Sort - Insert Sort - Quick Search - Binary Seach - Sequencial IMDCT IMDCT u IMDCT u IMDCT u Floating Point Sums Random TA média

4 A Tabela 3 mostra as tarefas e seu consumos de potência média (em chaveamentos por ciclo) para cada processador. Para as tarefas em questão, o VLIW é o processador mais dispendioso em potência. A diferença de consumo entre o pipeline e o multiciclo em geral é baixa, também devido à desvantagem do multiciclo em relação à implementação da pilha. Para cada estudo de caso, a simulação foi feita em três etapas. A primeira considera que apenas o custo em ciclos de cada tarefa é conhecido a priori. Neste caso, o escalonamento estático consideraria o custo em ciclos como fator determinante para a alocação de uma tarefa para um processador, e a mesma métrica (ciclos) é adotada pelo TA. Para obter os resultados, o simulador usa os outros dados das tarefas (energia e potência) para comparar a execução das tarefas usando TA e sem usar TA. Analogamente, as etapas 2 e 3 consideram, respectivamente, energia e potência como dados conhecidos, e conseqüentemente, métricas que serão usadas pelo TA. Na simulação, é admitido um instante de tempo t, em que dois processadores estão desocupados, e há 5 tarefas que devem rodar nestes processadores, independentemente da ordem. O simulador não considera que as tarefas possam ter deadline ou ser dependentes umas das outras. Cada vez que um processador é desocupado, o TA é executado e aloca para aquele processador uma das 5 tarefas que ainda não tenha sido executada, desde que a solução desta tarefa corresponda ao processador desocupado (o que será conhecido após o teste do threshold). Caso não encontre uma solução imediatamente, o TA escolhe aleatoriamente outra tarefa, até a exaustão de possibilidades para aquele processador. A simulação termina quando todas as 5 tarefas foram executadas. Para facilitar a simulação, é considerado que ambos processadores rodam à mesma freqüência. Como o TA decide aleatoriamente a ordem de execução das tarefas, cada etapa é simulada 253 vezes, e a semente do algoritmo pseudoaleatório é modificada. Isto permite explorar mais possibilidades na ordem de execução das tarefas, e não tornar a simulação tendenciosa. Para os resultados, é considerado o valor médio das simulações. O custo do TA não foi considerado na simulação. Portanto, é necessário considerar que uma implementação do TA em hardware seria utilizada no ambiente simulado. Como a simulação não considera o custo do TA (seja em ciclos, potência ou energia), simular uma execução sem TA é o mesmo que simular uma execução com TA onde o threshold é igual a zero. Resultados A simulação obteve resultados na comparação entre a execução de um ambiente com escalonamento dinâmico (TA) e de um ambiente com escalonamento estático, que considera que as tarefas devem executar apenas no processador para o qual apresentam menor custo segundo a métrica em questão. A solução estática corresponde às seqüências em que o threshold é igual a zero. O threshold é calculado com base na tarefa de maior custo segundo a métrica préestabelecida. Por exemplo, quando o ambiente é composto por um pipeline e um multiciclo, e a métrica a ser analisada é número de ciclos, a tarefa TA é a que tem maior custo (74.00 ciclos no multiciclo). Um threshold igual a 5 representa 5% de 74.00, ou seja, ciclos. Este será o valor inicial usado pelo TA na determinação das soluções, para este caso. Um threshold igual a 0 representa 0% de ciclos, e assim respectivamente. No primeiro estudo de caso (em que foram utilizados um processador FemtoJava multiciclo e um FemtoJava pipeline), os resultados da Tabela 4 foram obtidos em uma execução que considera como métrica número de ciclos. Tabela 4 Resultado de uma execução multiciclo+pipeline que considera ciclos como métrica A solução em um escalonamento estático seria determinar que todas as 5 tarefas executassem no pipeline, como é possível verificar na Tabela. Tendo o multiciclo disponível, o TA usa o threshold para alocar ao multiciclo algumas tarefas que estariam esperando para executar no pipeline. Quanto maior o threshold, maior o número de tarefas para as quais o multiciclo também é considerado uma solução. Pelo aproveitamento do multiciclo, de forma geral o sistema ganha em desempenho. O ganho não é muito alto porque poucas tarefas conseguem efetivamente rodar no multiciclo, já que o pipeline é muito mais eficiente em tempo e consegue ficar logo desocupado. Há perda em energia, porque o consumo de energia aumenta quando as tarefas rodam no multiciclo. A Figura 3 mostra o gráfico correspondente à Tabela 4, com os valores normalizados para a solução estática.

5 ,02,05,0, , Figura 3 - Execução em um sistema multiciclo+pipeline que considera ciclos como métrica Em uma segunda etapa da simulação de um ambiente multiciclo + pipeline, foi considerado como métrica o consumo de energia. Neste caso, seguindo a Tabela 2, a solução estática novamente consideraria o pipeline para todas as tarefas. O resultado desta simulação encontra-se na Tabela 5. Tabela 5 - Resultado de uma execução multiciclo+pipeline que considera energia como métrica Mesmo dispondo do multiciclo, não é possível economizar em energia aproveitando a ociosidade de um processador que tem um consumo maior. Neste caso, a análise procura verificar se a perda em energia foi significativa, se comparada ao ganho em ciclos. A Figura 4 mostra o gráfico correspondente à Tabela 5, com os valores normalizados para a solução estática. Infelizmente, a perda em energia é considerável se comparada ao ganho em ciclos. Isso deve-se ao fato do multiciclo ser muito lento e consumir muito em relação ao pipeline. Se for desejável tomar a energia como métrica, mesmo sujeito a sofrer penalidades em ciclos, é porque o desempenho não representa tanto. Neste caso, é mais vantajoso utilizar escalonamento estático do que escalonamento com TA. A última etapa da simulação de um ambiente multiciclo + pipeline considera como métrica o consumo de potência. Neste caso, seguindo a Tabela 3, a solução estática consideraria a execução no pipeline para 8 tarefas, e a execução no multiciclo para as restantes. O resultado desta simulação encontrase na Tabela 6. Tabela 6 - Resultado de uma execução multiciclo+pipeline que considera potência como métrica Neste caso, o fato do multiciclo ser extremamente lento e consumir muita energia ao mesmo tempo auxiliou o TA a tomar uma decisão benéfica, tanto para ciclos quanto para energia. Isto porque um escalonamento estático não considera a disponibilidade dos processadores. Como o pipeline é mais ágil, o TA alocou mais tarefas para o pipeline, já que a diferença de potência entre o pipeline e o multiciclo é pequena para a maioria das tarefas. Assim sendo, foi possível ganhar tanto em energia (pipeline é mais econômico) quanto em ciclos. A Figura 5 mostra o gráfico correspondente à Tabela 6, com os valores normalizados para a solução estática.,02,05,0, ,975 0, Figura 4 - Execução em um sistema multiciclo+pipeline que considera energia como métrica,0 0,97 0,96 0, Figura 5 - Execução em um sistema multiciclo+pipeline que considera potência como métrica

6 Usar potência média como métrica pode não gerar boas soluções, principalmente em um ambiente onde dois processadores co-existam. A dissipação neste caso é estimada considerando que os dois processadores estarão executando ao mesmo tempo, e o sistema deve estar devidamente equipado para esta situação. O esforço para reduzir o consumo de energia passa a ser mais significativo do que o esforço para reduzir potência. A potência está diretamente relacionada à energia, mas baixa potência pode não significar baixo consumo em energia, e sim, maior tempo de execução. No entanto, há situações em que é melhor utilizar a potência média como métrica do que não utilizar métrica alguma, como em tarefas em que o tempo de execução não é conhecido (tarefas que interagem com usuários, por exemplo). A princípio imaginava-se que as organizações do FemtoJava multiciclo e pipeline fossem antagônicas: a primeira mais lenta, mas econônica em energia e potência; a segunda com maior desempenho, e por outro lado com alto consumo de energia e potência. Como esta comparação não pôde ser aplicada às versões utilizadas, foi feito um novo estudo de caso, considerando as versões FemtoJava VLIW e pipeline. Apesar do FemtoJava VLIW ser baseado em uma versão low-power do FemtoJava [8], a comparação é mais justa pois o VLIW sempre ganha em ciclos e sempre perde em potência. Começando pela primeira etapa da simulação, a Tabela 7 mostra os resultados da execução das 5 tarefas para um sistema composto por um processador FemtoJava pipeline e FemtoJava VLIW, considerando como métrica o número de ciclos. Tabela 7 - Resultado de uma execução VLIW+pipeline que considera ciclos como métrica Um escalonador estático colocaria todas as tarefas para rodar no VLIW neste caso, como é possível verificar na Tabela. Pelo mesmo motivo que no estudo de caso multiciclo + pipeline, o número total de ciclos para uma execução com TA diminuiu se comparado ao da solução estática, pelo simples aproveitamento do pipeline para algumas tarefas. O consumo em energia sofre um pequeno aumento para um threshold mais alto, pois o TA passa a alocar tarefas como IMDCTu, IMDCTu2 e IMDCTu3 ao pipeline, onde o consumo de energia é maior para estas tarefas. A Figura 6 mostra o gráfico correspondente à Tabela 7, com os valores normalizados para a solução estática.,0 0,97 0,96 0,95 0, Figura 6 - Execução em um sistema VLIW+pipeline que considera ciclos como métrica Na segunda etapa do estudo de caso pepeline + VLIW, foi considerado como métrica para o escalonamento das tarefas o consumo de energia. Com relação à energia, o consumo para algumas tarefas é menor no pipeline, enquanto poara outras é menor no VLIW. Os resultados da simulação para este caso são apresentados na Tabela 8. Tabela 8 - Resultado de uma execução VLIW+pipeline que considera energia como métrica Já era esperado que a solução do TA fosse pior em energia se comparada à solução estática, mas a surpresa foi obter piora também no desempenho. Vale lembrar que o número de ciclos é obtido pelo cálculo da média de ciclos gastos para executar as tarefas em todas as simulações. Em algumas simulações, a escolha de tarefas pelo TA foi mais vantajosa, a ponto de resultar em uma execução recorde de ciclos. Por outro lado, outras simulações foram prejudicadas pela ordem de escolha das tarefas para os processadores, o que provocou o aumento da média do número de ciclos por execução, fazendo com que esta superasse o número de ciclos em uma execução que usa escalonamento estático. Um exemplo disto é alocar as tarefas IMDCTu, IMDCTu2 e IMDCTu3 ao pipeline, onde tanto o consumo de energia quanto o número de ciclos para execução é maior para estas tarefas. A Figura 7 mostra o gráfico correspondente à Tabela 8, com os valores normalizados para a solução estática.

7 ,025,02,05,0, Figura 7 - Execução em um sistema VLIW+pipeline que considera energia como métrica Considerando a potência como métrica para escalonamento, o VLIW perde para o pipeline em todas as tarefas, como mostra a Tabela 3. Por isso, alocar tarefas também ao VLIW aumenta o desempenho e pode ainda reduzir o consumo de energia, já que algumas tarefas consomem menos no VLIW do que no pipeline. Os resultados da simulação para este caso são apresentados na Tabela 9. Tabela 9 - Resultado de uma execução VLIW+pipeline que considera potência como métrica A Figura 8 mostra o gráfico correspondente à Tabela 9, com os valores normalizados para a solução estática., ,975 0, Figura 8 - Execução em um sistema VLIW+pipeline que considera potência como métrica O custo do TA não foi considerado na simulação. Considerando que uma versão em hardware do TA fosse utilizada, a penalidade em ciclos considerando todas as 5 execuções do TA no contexto da simulação (uma execução para cada tarefa) seria: TA ciclos = (5*5)* 0,5 = 3 ciclos Onde 5 é o número de tarefas, 5 é o número médio de iterações em cada execução do TA (que representam o número de ciclos necessários para execução do TA em hardware) e 0,5 é a probabilidade do processador para o qual o TA escolheu uma tarefa ser o desocupado. Podese considerar esta probabilidade porque o TA pode executar ainda antes de um processador liberar. Pela comparação com o número total de ciclos de cada execução, que pelos logs do simulador teve valor mínimo de ciclos, optou-se por desprezar os ciclos consumidos pelo TA. O consumo do TA em energia é igual a: TA energia = 3* 3.40= CG Onde 3 é o número de ciclos e 3.40 é a potência do TA em hardware em CG/ciclo. Também foi optado por desprezar o consumo do TA em energia, uma vez que o número mínimo de CGs apresentado em uma execução foi de Conclusões e Trabalhos Futuros O TA é uma opção para o escalonamento de tarefas em redes com processadores heterogêneos, mas uma solução não muito indicada, principalmente se for para executar em software. Os melhores resultados (ganho em ciclos e energia) foram obtidos quando a métrica considerada é potência. Mesmo assim, para qualquer resultado, a utilização do TA não implica em uma diferença de mais de 4% se comparada à utilização de escalonamento estático. De uma forma geral, os resultados de uma execução que utiliza o TA são extremamente ligados à arquitetura e organização dos processadores que compõem a rede. É necessário ressaltar que a aplicação do TA para o problema de alocação de tarefas não foi adequada. Seria mais interessante fazer com que o TA efetivamente encontrasse uma solução ótima para um conjunto de tarefas, por exemplo, solução para execução total em um número mínimo de ciclos. De qualquer forma, o trabalho cumpriu a proposta inicial e apresentou resultados; uma nova abordagem para o TA no contexto de redes heterogêneas pode ser uma proposta de trabalhos futuros. Trabalhos futuros também incluem estender as implementações e o ambiente de simulação do TA para mais de dois processadores e considerar que instruções de uma mesma tarefa podem ser executadas em processadores diferentes. Entre as contribuições do trabalho estão o acréscimo de dois novos benchmarks para o FemtoJava (TA e Random) e a implementação de versões do TA em hardware e software, que podem vir a ser utilizadas em outros trabalhos.

8 Referências Bibliográficas [] V. Cerny, 985. Thermodynamical Approach to the Traveling Salesman Problem: an Efficient Simulation Algorithm. Journal of Optimization Theory and Applications 45(), 4-5. [2] S. Kirkpatrick, C. D. Gelatt, Jr. and M. Vecchi, 983. Optimization by Simulated Annealing. Science 220(4598), [3] G. Dueck and T. Scheuer, 990. Accepting: A General Purpose Optimization Algorithm Appearing Superior to Simulated Annealing. Journal of Computational Physics 90, [4] T. C. Hu, A. B. Khang and C. W. A. Tsao, 995. Old bachelor acceptance. A new class of non-monotone threshold accepting methods. ORSA Journal on Computing 7, 47. [5] Mentor Graphics. Leonardo Spectrum Level 3. versão 2005b.24. [6] S.A. Ito, L. Carro, R.P. Jacobi. Making Java work for microcontroller applications. Design & Test of Computers, IEEE Volume 8, Issue 5, Sept.-Oct. 200 Page(s): [7] A. C. S. Beck, et al. CACO-PS: a general purpose cycle-accurate configurable power simulator. Integrated Circuits and Systems Design, SBCCI Proceedings. 6th Symposium on 8- Sept Page(s): [8] A. C. S. Beck. Carro, L. Um processador Java VLIW com baixo consumo de potência para sistemas embarcados. Iberchip [9] A. C. S. Beck. Carro, L. Uso da Técnica VLIW para Aumento de Performance e Redução do Consumo de Potência em Sistemas Embarcados Baseados em Java. Dissertação apresentada como requisito parcial para a obtenção do grau de Mestre em Ciência da Computação. UFRGS, Porto Alegre, jul