Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • ALICE-open-data ALICE-open-data
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ALICE-open-data
  • ALICE-open-dataALICE-open-data
  • Wiki
  • Home

Home · Changes

Page history
Add to Efficiency Test section authored May 25, 2020 by Breno Rilho Lemos's avatar Breno Rilho Lemos
Hide whitespace changes
Inline Side-by-side
Home.md
View page @ 287079de
......@@ -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.
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>
......
Clone repository
  • Documentação da instalação da interface TGeoCad
  • Home

Os conteúdos dos repositórios estão sob licenças livres e são responsabilidade dos próprios autores, não representando as opiniões e posicionamento da UFRGS ou do CTA.