Para veriĄcar o tempo médio de tomada de decisão, todos os algoritmos (incluindo suas versões) foram executados 6 vezes. Em cada execução foi adotado um determinado número de processadores escravos conforme apresentado na Tabela 8. Assim, a primeira execução foi conduzida com um processador mestre e apenas um escravo. As execuções subsequentes foram executadas com um processador mestre, mas com um incremento de 3 processadores escravos até o limite da arquitetura de hardware disponível, isto é, até 15 processadores escravos.
O gráĄco da Figura 50 mostra o tempo médio gasto na execução dos algoritmos para o conjunto de estados de tabuleiro variando o número de processadores escravos. Assim, observando-se o gráĄco é possível notar os seguintes pontos comuns entre todas as versões:
1. o tempo médio de execução é inversamente proporcional ao número de processadores escravos utilizados. Esta situação ocorre, pois a medida que processadores são adicionados, existe uma maior divisão de tarefas que serão executadas em paralelo, o que auxilia na agilidade da busca.
2. o maior tempo de processamento ocorreu com a utilização de apenas um processador escravo. Tal comportamento é justiĄcado pelo fato de que uma versão distribuída do Alfa-Beta possui diversas instruções adicionais o que torna o algoritmo mais complexo. Além disso, ainda existe o tempo gasto com trocas de mensagens e atualizações de dados nas estruturas de dados utilizadas.
permitiu uma abertura maior entre os limites alfa e beta. Assim, diversas podas foram perdidas durante o processo de busca e, consequentemente, diversos nós foram explorados sem necessidade agravando a ocorrência de sobrecarga de busca, conforme será explanado na seção 8.2.5.
No caso do ADABA-V2, realmente houve um tempo muito elevado quando ele foi executado com um processador escravo, mas com 3 ou mais processadores escravos ele tornou-se mais rápido que o APHID-V1, APHID-V2 e ADABA-V1. A razão deste com- portamento está relacionado à forma como esta versão opera: ela utiliza um pool de
threads para tratar as mensagens recebidas dos processadores escravos (detalhes na seção
5.4). O problema é que quando há apenas um processador escravo, todos os pacotes recebidos dos escravos devem atualizar a mesma porção da estrutura de dados AIS do mestre. Neste caso, as threads entram em Şcondição de corridaŤ (race condition)1 [82].
Evidentemente, este comportamento do ADABA-V2 seria eliminado se fosse considerada apenas uma thread no tratamento dos dados recebidos. Todavia, a mesma conĄguração foi mantida para todas as execuções para permitir veriĄcar o comportamento geral desta versão do algoritmo. Quando são incluídos mais processadores escravos, é possível obser- var a existência de um melhor aproveitamento do processamento paralelo provido pelas
threads, uma vez que existe mais chances de processadores distintos enviarem pacotes
simultaneamente. Como estes pacotes serão atualizados em AIS distintas, o problema de condição de corrida deixa de apresentar impacto negativo, conforme pode ser observado nos resultados obtidos pelo ADABA-V2.
As versões APHID-V1 e ADABA-V1 apresentaram valores muito próximos no tempo de execução em todas as variações do número de processadores. No entanto, nota-se que o APHID-V1 apresentou melhor tempo que o ADABA-V1 em todos os casos. Salienta- se que o APHID-V1 utiliza um valor que foi considerado satisfatório para a deĄnição da largura da janela de busca para o domínio do problema utilizado no contexto deste trabalho, conforme explanado nos experimentos da seção 8.1. Todavia, este valor foi obtido de modo empírico e manual. O ADABA-V1 implementa uma nova política para deĄnição automática da largura da janela de busca . Neste sentido, apesar do tempo de execução dele ser maior que o APHID-V1, é possível observar que a política proposta pelo ADABA oferece um tempo de execução próximo ao da melhor versão obtida do APHID para o problema tratado.
O ADABA-V3 apresentou um tempo médio de execução muito bom, ele apenas foi mais lento do que o APHID-V3. Este resultado demonstra que as contribuições deste trabalho, em conjunto, permitiram a obtenção de um tempo médio de execução superior às demais versões. A Ąm de expandir as análises referentes ao tempo de execução dos algoritmos, as seções 8.2.3 e 8.2.4 apresentam, respectivamente, as observações sobre o
1 A Şcondição de corridaŤ (race condidtion) ocorre quando duas ou mais threads tentam acessar o mesmo
8.2. Avaliação do desempenho do algoritmo ADABA 163
Speed-Up e eĄciência observados nas versões dos algoritmos avaliados.
8.2.3
Speed-Up
Esta seção avalia a aceleração (speed-up) dos algoritmos, que, assim como apresentado na seção 2.4.1, é calculada pela razão entre o tempo de execução da versão serial e paralela. A Tabela 9 apresenta os valores obtidos do speed-up apresentado por cada uma das versões avaliadas em função da quantidade de processadores escravos. Os valores apresentados nesta tabela estão vinculados com os tempos de execução obtidos nos testes da seção 8.2.2.
Ao analisar a Tabela 9, observa-se que as versões APHID-V1, APHID-V2, ADABA- V1 e ADABA-V2 apresentaram speed-up positivo (velocidade superior à da versão serial) a partir da utilização de 9 processadores escravos, ou seja, nas situações em que foram utilizados menos processadores estas versões foram mais lentas do que a versão serial do Alfa-Beta ou apresentaram um tempo de execução muito próximo ao dele. O ADABA-V3 mostrou-se mais rápido que a versão serial a partir da utilização de 3 processadores escra- vos. Apenas a versão APHID-V3 teve aceleração superior àquela praticada pela versão serial do Alfa-Beta independente do número de processadores escravos envolvidos. Estes resultados corroboram com o fato de que uma versão distribuída é mais complexa do que a sua respectiva versão serial. Além disso, é necessário considerar que a utilização de arquitetura de memória distribuída contribui para o aumento do tráfego de mensagens ge- rando sobrecarga de comunicação (seção 2.4.2). Nesta direção, o emprego da distribuição da busca torna-se viável quando:
1. há um número adequado de processadores escravos. Entretanto, um ponto a se destacar é que o incremento do número de processadores escravos possui um limite. A partir deste limite começa a ŞdesaceleraçãoŤ do processo da busca. Esta situação ocorre devido ao aumento da sobrecarga de comunicação. Infelizmente, devido à limitação de arquitetura, não foi possível concluir neste trabalho a partir de quantos processadores escravos o processo de busca começaria a sofrer uma degradação de desempenho.
2. deseja-se explorar níveis mais profundos da árvore de busca. Neste caso, a versão serial torna-se tão lenta que é impraticável a sua execução.
8.2.4
EĄciência
O cálculo da eĄciência dos algoritmos está diretamente relacionado com o cálculo do
speed-up, uma vez que o seu valor é dado pela razão entre o speed-up e o número de
Tabela 9 Ű Speed-Up observado para cada algoritmo variando o número de processadores escravos
Algoritmo Número de Processadores
1 3 6 9 12 15 APHID-V1 0,47 0,70 0,98 1,28 1,34 1,62 APHID-V2 0,45 0,59 0,85 1,02 1,18 1,32 APHID-V3 2,06 5,14 6,50 6,73 6,90 7,21 ADABA-V1 0,46 0,66 0,92 1,23 1,29 1,51 ADABA-V2 0,24 0,84 1,00 1,77 2.21 2,47 ADABA-V3 0,58 1,50 2,28 2,73 3,12 3,19
na situação mais simples utilizará dois processadores: 1 mestre e 1 escravo. Por esta razão, no cálculo da eĄciência é necessário considerar o processador mestre também. A Tabela 10 apresenta a eĄciência obtida por cada uma das versões dos algoritmos em função da quantidade de processadores. Foram apresentados apenas os valores das situações em que o speed-up foi superior a 1 na Tabela 9.
Tabela 10 Ű EĄciência apresentada por cada algoritmo variando o número de processado- res Número de Processadores Algoritmo 2 4 7 10 13 16 APHID-V1 0,13 0,10 0,10 APHID-V2 0,10 0,09 0,08 APHID-V3 1,03 1,28 0,93 0,67 0,53 0,45 ADABA-V1 0,12 0,10 0,09 ADABA-V2 0,18 0,17 0,15 ADABA-V3 0,37 0,33 0,27 0,24 0,20
Na Tabela 10 nota-se que há um comportamento inverso ao da aceleração, isto é, a medida que novos processadores são adicionados à busca, menor a eĄciência dos algorit- mos. Tal fato ocorre, pois quanto maior o número de processadores, maior a sobrecarga de comunicação, o que contribui para o atraso das execuções. Além disso, é importante salientar que nos testes cada estação de trabalho contém 4 núcleos de processamento. Neste contexto, quando há mais de um processo executando na mesma estação deve-se considerar os seguintes fatores de limitação: 1) há um compartilhamento da memória RAM; 2) Por se tratar de uma estação de trabalho convencional, existem diversos outros processos inerentes ao Sistema Operacional disputando estes núcleos de processamento. Um cuidado tomado no contexto da conĄguração dos experimentos (seção 8.2.1) foi limi- tar o número de processos em cada estação de trabalho à quantidade de núcleos existentes. A intenção foi usufruir dos benefícios da arquitetura multicore, sem agravar os fatores de
8.2. Avaliação do desempenho do algoritmo ADABA 165
limitação relacionados anteriormente. Acredita-se que utilizar mais estações de traba- lho executando um número de processos inferior ao limite do total de núcleos existentes aumentaria o desempenho dos algoritmos. Um fato que contribui para essa crença é a situação do ADABA-V3 que atingiu uma eĄciência de 0.37 quando utilizou um processo escravo em cada estação de trabalho, conforme conĄguração apresentada na Tabela 8.
Apesar da eĄciência dos algoritmos não estarem próximas da ideal, isto é, 1, deve-se atentar para os benefícios que a aceleração trás para um ambiente de elevada complexi- dade do espaço de estados. Quanto mais rápido o algoritmo é, mais estados ele poderá explorar em um determinado intervalo de tempo. Desta forma, as versões distribuídas permitem um melhor desempenho da busca justamente pelo fato de permitir explorar mais profundamente a árvore de busca (look-ahead).
Considerando a versão do APHID-V1 (que é a versão oĄcial para o APHID-Draughts, seção 8.1) e o ADABA-V3 (versão Ąnal do ADABA), este último foi, pelo menos, duas vezes mais rápido que o primeiro. Na prática, essa eĄciência traz os seguintes benefícios:
❏ Se for Ąxada uma profundidade de busca, a solução será retornada mais rapidamente. No caso particular do treinamento de uma rede MLP, como é o caso da arquitetura do agente jogador utilizado neste trabalho, esta agilidade é positiva visto que o processo como um todo é moroso (mais detalhes do treinamento da rede MLP da arquitetura do agente jogador de Damas tratados neste trabalho podem ser visualizados na seção 6.3).
❏ Se for Ąxado um limite de tempo para as jogadas, a versão mais ágil atingirá pro- fundidades da árvore de busca superiores. Neste caso, se for considerado o período de treinamento de uma rede MLP, certamente a qualidade da mesma será melhor. Por outro lado, se for um jogo de disputa, a tomada de decisão será mais acurada. Ainda observando a Tabela 10, destaca-se a eĄciência apresentada pelo APHID-V3 que com 2 e 3 processadores chegou a apresentar valores superiores à eĄciência ideal. Tal fato demonstra que o APHID pode ser muito eĄciente quando é deĄnido um valor pequeno de abertura da janela de busca. Todavia, esta aceleração pode degradar a qualidade da busca, conforme será apresentado na seção 8.2.6.