Reprodução dos Experimentos do Artigo” Introducing a Stream Processing

Framework for Assessing Parallel Programming Interfaces”

Thales Santin, Pedro Vaz, Elise Scheibel

Pontifícia Universidade Católica do Rio Grande do Sul, Porto Alegre, Brasil.
E-mail: thales.santin@edu.pucrs.br, pedro.vaz@edu.pucrs.br, elise.scheibel@edu.pucrs.br
Resumo - Com a computação de grandes quantidades de dados produzidos diariamente por
nós ainda sendo uma tarefa de alta prioridade, há uma maior necessidade do uso de métodos
orientados para tal, um destes é Stream Parallelism. Esse trabalho, portanto, executa uma
reprodução dos experimentos sobre Stream Parallelism, realizados a partir da introdução de
um Stream Processing Framework, para a avaliação de Parallel Programming Interfaces.

I. Introdução
Stream Processing(SP) é uma tecnologia de processamento de dados em crescimento
que, diferente dos processadores de dados tradicionais Batch-oriented, processa os dados em
tempo real. Em SP, a informação é continuamente processada conforme novos dados chegam
para análise, aplicando uma série de computações como estágios em uma Pipeline, processando
incrementalmente.
Considerando isso, esse ensaio estudou os conceitos e ferramentas utilizadas, com
objetivo de reproduzir os experimentos realizados no artigo [1]”Introducing a Stream
Processing Framework for Assessing Parallel Programming Interfaces” e analisar se há
concordância entre os dados. Este artigo introduz um framework de processamento de Streams
que avalia Parallel Programming Interfaces (PPIs), para que usuários possam identificar com
mais facilidade os operadores básicos e implementar paralelismo a partir de várias PPIs.

II. Framework
A principal característica do framework consiste em Stream Processing Applications
organizadas como uma Application Programming Interface (API). Para construir essa API, os
operadores da aplicação original são desmembrados e alocados em novos códigos para, então,
poderem ser chamados individualmente. Portanto, a base desse framework é composta de APIs
que representam cada aplicação e um conjunto de aplicações sequenciais que as instanciam.
Conforme essas aplicações são paralelizadas com diferentes PPIs, as implementações paralelas
são integradas nesse conjunto. Em adição às aplicações sequenciais e implementações paralelas,
a framework também providencia ferramentas para adicionar novas PPIs ou modificar
livremente as já existentes. Tudo isso é realizado através da linha de comando do terminal, onde
usuários podem editar, configurar, compilar, executar, adicionar métricas de execução, entre
outras funcionalidades.
Uma das vantagens desse framework é facilitar a adesão de novos programadores a essa
tecnologia devido à longa curva de aprendizado para a identificação dos operadores de um
código. Com essa ferramenta em mãos, usuários apenas precisam inserir a função de chamada
de cada operador.
 Identificar todas as variáveis dos operadores e suas dependências pode ser uma tarefa
ainda mais complicada que identificar operadores. Por isso, a API também providencia
abstração para os dados comunicados entre eles. Ela o realiza encapsulando os dados de forma
que cada operador use a mesma estrutura de dados. Na API, essa classe genérica é chamada de
“item” e essa estrutura é a única variável comunicada entre todos os operadores de uma
aplicação.
A API também insere métricas de execução e gerencia a fonte de dados, a qual pode ser
o disco, a memória ou a network.

III. Metodologia
O experimento original foi realizado em um computador com 32 de RAM e dois
processadores Intel(R) Xeon(R) CPU E5-2620 v3 2.40GHz, para um total de 12 núcleos e 24
threads com Hyper-Threading. O sistema operacional usado foi Ubuntu Server 18.04, 64 bits,
kernel 4.15.0-88-generic, e GCC 7.5.0 usando -O3 flag. A reprodução do experimento foi feita
em um computador com 32 RAM e um processador Intel(R) Xeon(R) CPU E5530 @ 2.40GHz,
com 8 núcleos e 16 threads. O sistema operacional usado foi Ubuntu Server 20.04.2, 64bits,
kernel 5.4.0-65-generic, e GCC 9.3.0 usando -O3 flag.
O monitoramento das aplicações na reprodução foi feito da mesma forma que a do
experimento original, utilizando as rotinas da própria API. Essas rotinas permitem
monitoramento do runtime e do uso da CPU/Memória com precisão de microssegundos,
adquirido no pseudo-arquivo “/proc/[pid]/stat”. O monitoramento é feito a cada 250 ms. Foram
usadas de 1 a 16 réplicas, sendo a réplica 0 uma aplicação sequencial.
Para a aplicação Bzip2 foi usado, como arquivo de entrada, uma imagem ISO de 671.6
MB. Para a aplicação Lane Detection, o arquivo de entrada é um vídeo MPEG-4 com resolução
640 × 360 e 1858 frames. Para a aplicação Person Recognition, o arquivo de entrada também é
um vídeo MPEG-4 com resolução 640 × 360, porém com 450 frames. Cada resultado representa
a média de 10 execuções e desvio padrão, com barras de erro incluídas nos gráficos.

IV. Análise dos Resultados

Os resultados obtidos das execuções tiveram seus desvios padrões e margem de erro
calculados a partir de um script escrito na linguagem Python com a biblioteca ‘math’ nativa da
linguagem e colocados em gráficos utilizando a biblioteca de gráficos Plotlib[2]. Os gráficos,
Fig. 1, estão apresentados abaixo, seguidos dos gráficos, Fig. 2, do trabalho original com os
resultados obtidos por este.
 Fig. 1: resultados de performance usando até 16 réplicas.

Fig. 2: resultados de performance originais usando até 24 réplicas.

Comparativamente, os resultados deste artigo são em menor escala, devido às restrições

de maquinário e tempo, tendo até 16 réplicas enquanto o original tem até 24 réplicas, porém o
valor comparativo está justamente no fator de que a reprodução foi feita um ambiente diferente
da do original. Outro ponto importante de se ressaltar é o fato de que as PPIs FastFlow e Spar
foram ambas testadas apenas na configuração de no mapping.
Em relação aos resultados obtidos pelo Stream Processing Application (SPA) Bzip2 a
reprodução obteve comportamentos pelas Parallel Programming Interfaces (PPIs) não muito
similares com os do trabalho original com spikes em latência em algumas execuções, como por
exemplo nas réplicas 10, 11, 14 e 16 da PPI Tbb, há suspeitas desse comportamento se dar
devido a caches. No aspecto de throughput, ‘Itens per second’, o comportamento já se torna
muito mais similar, porém o plateau que ocorre no trabalho original não foi alcançado na
reprodução, muito provavelmente devido ao menor número de réplicas.
Os resultados de ambas as SPAs Lane Detection e Person Recognition no gráfico de
latência, porém se assemelham muito aos obtidos originalmente, com uma depressão e eventual
constante ascensão no decorrer do gráfico para as PPIs Spar e Fastflow, para o Tbb a ascensão
não é tão proeminente na reprodução, porém ainda pode ser observada.A diferença, porém, se
nota nos pontos em que a depressão termina e a ascensão começa entre os gráficos, no caso da
reprodução a ascensão começa na réplica 8 em ambas Lane Detection e Person Recognition
enquanto no original está começa na réplica 12. Nos gráficos de throughput também se observa
o mesmo padrão onde os gráficos são semelhantes, porém os pontos de mudança de
comportamento da linha são diferentes.

V. Conclusão
Este trabalho revisou o estudo” Introducing a Stream Processing Framework for
Assessing Parallel Programming Interfaces“e reproduziu seus dados em novo experimento e
ambiente, com objetivo de analisar o grau de disparidade dos resultados.
A conclusão geral do artigo é de que as semelhanças nos resultados reforçam a eficiência
do framework descrito no artigo original, porém, as diferenças entre os resultados,
principalmente nos que diziam respeito a SPA Bzip2, trazem dúvidas em relação a
reprodutibilidade dos resultados em diferentes ambientes e quais diferenças entre estes podem
causar tais divergências.
O próximo passo no nosso estudo será ampliar o framework para comportar uma nova
PPI chamada std::thread, estendendo a cobertura de PPIs.

Reconhecimentos
Esse trabalho foi realizado com a ajuda de dois membros do artigo original, Dalvan
Griebler e Adriano Marques Garcia, que auxiliaram com orientações sobre o framework e seu
funcionamento e auxílio técnico quando foi necessário.
Agradecemos também às nossas mães, que tem experiencia com escrita acadêmica e
revisaram o artigo.

Referencias
[1] A. M. Garcia, D. Griebler, L. G. L. Fernandes and C. Schepke, "Introducing a Stream
Processing Framework for Assessing Parallel Programming Interfaces," 2021 29th Euromicro
International Conference on Parallel, Distributed and Network-Based Processing (PDP),
2021, pp. 84-88, doi: 10.1109/PDP52278.2021.00021.
[2] Biblioteca para geração de gráficos usada. Matplotlib, 2012. Disponivel em:
<https://matplotlib.org/>. Acesso em: 6 de maio de 2021.