... | @@ -362,11 +362,37 @@ Em breve seção. |
... | @@ -362,11 +362,37 @@ Em breve seção. |
|
|
|
|
|
Durante aproximadamente dois dias, foi deixado um *notebook* gerando uma série de animações de colisões de partículas de eventos do Experimento ALICE por meio do código desenvolvido, com o fim de conhecer os recursos utilizados no processo: tempo e memória. Foram gerados três clipes - um para cada câmera - de cada um dos quinze eventos selecionados a partir do ESD *Run139038_Orbit7548473_BunchCross1534*, com crescente multiplicidade. O objetivo principal foi estimar a quantidade dos recursos necessários para se gerar um número maior de clipes, inclusive de eventos com multiplicidade bem mais elevada que aquela mais alta contemplada no teste, de 1004 partículas.
|
|
Durante aproximadamente dois dias, foi deixado um *notebook* gerando uma série de animações de colisões de partículas de eventos do Experimento ALICE por meio do código desenvolvido, com o fim de conhecer os recursos utilizados no processo: tempo e memória. Foram gerados três clipes - um para cada câmera - de cada um dos quinze eventos selecionados a partir do ESD *Run139038_Orbit7548473_BunchCross1534*, com crescente multiplicidade. O objetivo principal foi estimar a quantidade dos recursos necessários para se gerar um número maior de clipes, inclusive de eventos com multiplicidade bem mais elevada que aquela mais alta contemplada no teste, de 1004 partículas.
|
|
|
|
|
|
O teste consiste na execução de um *script* em *bash* que executa, por sua vez, para cada multiplicidade desejada, o *script* *workflow_sketch.sh*, responsável pela automatização das etapas do projeto, com a instrução de animar apenas um evento, com todas as três câmeras.
|
|
O teste consiste na execução de um *script* em *bash* que executa, por sua vez, para cada multiplicidade desejada, o *script* *workflow_sketch.sh*, responsável pela automatização das etapas do projeto, com a instrução de animar apenas um evento, com todas as três câmeras. Eis o código usado: [efficiency_data_collecting.sh](uploads/8421b49f3895c7a8ee32ae0af454b444/efficiency_data_collecting.sh)
|
|
|
|
|
|
O seguinte gráfico representa a memória computacional máxima utilizada no processo de se extrair os dados
|
|
O seguinte gráfico, gerado no **gnuplot** com o código [plot_memory.sh](uploads/c6bf122f1e60b6f080420a4e9a8815d0/plot_memory.sh), representa a memória computacional máxima utilizada, para clipes de cinco segundos, no processo de extrair os dados e gerar as animações nas três câmeras de cada evento acionado.
|
|
|
|
|
|
(em desenvolvimento)
|
|
![Memory-efficiency](uploads/c5018f3822332c3a1afd08952a002b78/Memory-efficiency.png)
|
|
|
|
|
|
|
|
Similarmente, o próximo gráfico representa os tempos computacionais conhecidos como **real time**, **user time** e **kernel time** no processamento dos (mesmos) três clipes de cinco segundos de cada evento. Segue uma breve explicação dos tempos mencionados.
|
|
|
|
|
|
|
|
**real time**: O tempo de fato gasto na execução do processo do início ao fim, como que medido por um ser humano com um cronômetro.
|
|
|
|
|
|
|
|
**user time**: O tempo acumulado gasto por todas as CPU's durante a computação
|
|
|
|
|
|
|
|
**kernel time** (ou **system time**): O tempo acumulado gasto por todas as CPU's durante tarefas relacionadas ao sistema, como alocação de memória.
|
|
|
|
|
|
|
|
Nota: Ocasionalmente, a soma **user time** + **kernel time** pode ser maior que o **real time**, pois múltiplos processadores podem trabalhar em paralelo.
|
|
|
|
|
|
|
|
![Time-efficiency](uploads/37c07a6f507334d710a5ab22b1a9ab06/Time-efficiency.png)
|
|
|
|
|
|
|
|
Outras configurações a respeito dos clipes gerados para o teste:
|
|
|
|
Resolução: 100%
|
|
|
|
FPS: 24
|
|
|
|
Geometrias incluídas: ITS, TPC, TRD, EMCal
|
|
|
|
Transparência: 1 (padrão)
|
|
|
|
|
|
|
|
Ao passo que foi observada uma "anomalia" no terceiro evento do último gráfico, isto é, um ponto que desvia bastante do padrão de pontos, suspeitou-se de algum tipo de falha externa da análise de rendimento, caso contrário deveria haver alguma particularidade em tal evento, ausente nos demais. Para averiguar as hipóteses, foi repetido o teste com as mesmas condições, porém apenas com os seis primeiros eventos contemplados na primeira amostra, e um evento adicional com multiplicidade muito próxima à do evento investigado, conforme consta no *script* em *bash* [efficiency_data_collecting_2.sh](uploads/2138c93d572767f9b11cec836ae7fac0/efficiency_data_collecting_2.sh).
|
|
|
|
|
|
|
|
Observou-se que o ponto original foi "corrigido" de modo a adaptar-se ao padrão dos outros pontos, enquanto o novo evento introduzido também se encaixou adequadamente, como mostra o gráfico abaixo.
|
|
|
|
|
|
|
|
![Time-efficiency](uploads/09c4e15d2ffa6a41ab7a71b4c03bd798/Time-efficiency.png)
|
|
|
|
|
|
|
|
Em ambos os gráficos gerados, na primeira análise, nota-se um padrão linear de pontos até a multiplicidade um pouco maior que 600. Na análise da memória, isso é coerente com a memória RAM do *notebook* utilizado, de 8GB, pois é aproximadamente neste valor de uso de memória que o gráfico torna-se praticamente constante.
|
|
|
|
|
|
|
|
|
|
### Abordagem utilizando máquina virtual <a name="docum8"></a>
|
|
### Abordagem utilizando máquina virtual <a name="docum8"></a>
|
... | | ... | |