As várias simulações foram feitas em várias máquinas em ambiente não controlado. Além disso, a Macra Aethra permite configurar uma escala de desempenho ao determinar o número dethreadsa atribuir a cada componente das heurísticas. Assim, analisar o desempenho do programa por máquina não é praticável.
A Macra Aethra possibilita o uso de cache das avaliações intermédias. Porém, esta funcionalidade foi usada em poucas simulações pelo que não serão analisados esses resultados quanto ao desempenho. Em consulta informal junto dos voluntários que a utilizaram, ficou a sugestão de que o uso de tal estrutura não terá trazido melhorias; podendo até aumentar um pouco o tempo de execução. Uma possível explicação para este comportamento estará no uso mais intensivo da memória que interage com o GC (Garbage Collector) do Java competindo por tempo de processamento.
Para mitigar os efeitos não controlados, calcula-se o valor médio de obtenção de um resultado, por teste, independentemente da máquina onde foi executado. De cada simulação de cada teste foi determinado o tempo de obtenção médio pelo quociente do tempo total sobre a contagem de resultados obtidos, independentemente de qual tenha sido a máquina. Finalmente, aplica-se novamente a média aritmética a todas as sessões de um dado teste. Este valor ponderado final denomina-se tempo médio de obtenção de um resultado. Note-se que pelos motivos acima, as simulações que usaramcachenão foram incluídas nesta determinação. Estes valores estão tabelados na listagem de resultados (anexo C na página 85).
Na figura 8.1 na página seguinte representa-se, sob a forma de gráfico de barras, os tempos médios de obtenção de resultados por cada grupo de testes, discriminados por configuração usada: DD (Default-Default), DL (Default-Light), LD (Light-Default) e LL (Light-Light). Em cada gráfico, os dois conjuntos de barras à esquerda correspondem à expA (Experiência A) enquanto os dois da direita se referem à expB (Experiência B), numa notação simplificada de projetos: “s-ac” projeto com único recurso, testado na expA; “m-ac” projeto com múltiplos recursos, testado na expA; “s-nac” projeto com único recurso, testado na expB; “m-nac” projeto com múltiplos recursos, testado na expB.
Em todos os casos, a configuração LL – a configuração mais ligeira – apresenta tempos de obtenção muito inferiores aos ocorridos com as outras configurações. Tal era esperado dado o seu carácter simplista. As configurações que combinam versões leves com pesadas – DL e LD – por norma não coincidem, havendo um nítido maior tempo de obtenção através da DL. Em destaque, a DD surge como aquela que comporta o maior tempo de obtenção, à exceção de casos nos grupos MP_Net02 e MP_Net05. Combinando as observações, conclui-se que a configuração dada à componente EMA (Electromagnetic Algorithm) domina (tem efeito mais expressivo) a dada à heurística baseada em p-EVA (EVA adaptado a Permutações), de acordo com a complexidade da dita.
465
s-ac m-ac s-nac m-nac Grupo MP_Net01
9
7
2
s-ac m-ac s-nac m-nac Grupo MP_Net02
690
s-ac m-ac s-nac m-nac Grupo MP_Net03
1
0
48
s-ac m-ac s-nac m-nac Grupo MP_Net04
7
3
7
s-ac m-ac s-nac m-nac Grupo MP_Net05
922
s-ac m-ac s-nac m-nac Grupo MP_Net06
952
s-ac m-ac s-nac m-nac Grupo MP_Net07
7
82
s-ac m-ac s-nac m-nac Grupo MP_Net08
356
7
s-ac m-ac s-nac m-nac Grupo MP_Net09
355
1
s-ac m-ac s-nac m-nac Grupo MP_Net10
6
7
1
5
s-ac m-ac s-nac m-nac Grupo MP_Net11
8
1
0
7
s-ac m-ac s-nac m-nac Grupo MP_Net12 1 1 6 7 7
s-ac m-ac s-nac m-nac Grupo MP_Net13
9265
s-ac m-ac s-nac m-nac Grupo MP_Net14
DD; DL; LD; LL;
s-ac: único recurso,expA; s-nac: único recurso,expB; m-ac: múltiplos recursos,expA; m-nac: múltiplos recursos,expB.
Figura 8.1: Gráficos de barras para os tempos médios de obtenção de um resultado, em milissegundos, por configuração, para cada grupo de projetos testados.
projetos tendo em conta a multiplicidade de recursos. Concretamente, as versões de múltiplos recursos levam mais tempo que as de único recurso. Apesar deste fenómeno ocorrer em ambas as experiências e para (quase) todos os grupos, há uma outra tendência observável: os tempos de obtenção na expB são maiores que na expA. Dado os projetos na expB estarem sem restrições de quantidade máxima de quantidade de recurso, ou seja, numa versão simplificada do modelo matemático de otimização, tal comportamento é intrigante. Pela primeira parte da observação, não parece que a razão possa estar nos projetos nem na abordagem implementada para suportar os casos sem restrição de disponibilidade. Procurando razões externas, há o factor da heterogeneidade das máquinas usadas. Aliás, pela tabela 7.2 na página 36, sabe-se que o grupo de trabalho nas duas experiências não foi o mesmo. No início desta secção, esclarece-se que se usou o tempo médio de obtenção de um resultado como aproximação a um cenário independente daquela heterogeneidade. É claro que tal aproximação beneficia de um maior número de amostras. Ora, na expA houve 149 sessões de simulação, tendo sido obtidos, em média, 13671 resultados em cada. Por seu lado, na expB, foram executadas 373 sessões com uma média de 454 resultados. Portanto, os tempos médios de obtenção apurados para a expB podem estar demasiado sensíveis a casos extremos pontuais quando comparados aos da expA. Outro factor a ter em consideração é a JVM (Java Virtual Machine) que terá sido usada. Verifica-se que em todas as simulações foi usada a versão 7 da Java HotSpot. Na expA a modalidadeclientfoi usada cerca de 13% das sessões; ao passo que na expB rondou os 43% sendo que nas restantes foi usada a modalidadeserver. Como aclientestá orientada para um regime de execução de maior interatividade com o utilizador, não usa certas otimizações que melhorariam o desempenho nos casos mais intensivos.
“These two systems are different binaries. They are essentially two different compilers (JITs) interfacing to the same runtime system. The client system is optimal for applications which need fast startup times or small footprints, the server system is optimal for applications where the overall performance is most important. In general the client system is better suited for interactive applications such as GUIs. Some of the other differences include the compilation policy, heap defaults, and inlining policy.”
in http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#compiler_types
Portanto, quer o menor número de resultados obtidos por sessão quer o tipo de máquina virtual estarão a suportar a tendência para maiores tempos de obtenção observados na expB.
Numa última observação, os tempos para a DD, nas versões de múltiplos recursos da expA dos grupos MP_Net09 ao MP_Net14, são muito superiores aos restantes. Partindo do raciocínio usado na análise anterior, este comportamento parece ser sensível às características próprias daqueles grupos. Nos outros, poderá estar presente alguma interação com as propriedades dos projetos. Porém, com os dados recolhidos, não é possível aferir qual o impacto isolado de cada fator. Ressalva-se, ainda, que o grupo MP_Net13 é particularmente penoso também na versão a um único recurso. Crê-se que as mesmas conclusões permanecem válidas neste caso particular.