Threads

CENTRO FEDERAL DE EDUCAÇÃO TECNOLÓGICA DE MINAS GERAIS
CAMPUS VII - UNIDADE TIMÓTEO - Engenharia da Computação
Laboratório de Programação Concorrente
Prof. Lucas Pantuza Amorim

Atividade: Rembrandt
Nome: Thiago de Sousa Goveia
Data: 15/ 10/ 2014
Atividade 2
Houve perda de performance com a implementação concorrente. Como há apenas um manipulador para a janela, e mais de uma tarefa de impressão sendo executada, o manipulador fica sobrecarregado e não pode melhorar em nada este cenário, já que consegue exibir imprimir um único pixel por vez. Foram verificados os seguintes valores:
1 Thread: 1,316 segundos
2 Threads: 2,336 segundos
4 Threads: 2,434 segundos
8 Threads: 2,691 segundos
16 Threads: 4,009 segundos

Atividade Especial
A perda de performance na geração de imagem, que piora com o uso de threads, deve-se principalmente a dois fatores:
1. Alto custo de Entrada e saída: Os processos de entrada e saída (imprimir na tela) são de alto custo de tempo. No caso da implementação atual, a função setPixel é invocada, para uma janela de tamanho N, N 2 vezes. Dessa forma, o delay de impressão, também é aumentado N2 vezes.
2. Comportamento da API: Mesmo quando a função setPixel é chamada em várias threads, ainda temos um grande delay. Na verdade ele aumenta. Isso ocorre porque a API do windows trabalha de forma sequência, já que na implementação, há apenas um manipulador para a janela, que é referenciado nas várias threads criadas. Assim, quanto mais threads, maior é a sobrecarga desse manipulador, já que ele escalona a impressão entre as threads e não a faz concorrentemente, como é feito o cálculo das cores.

Com essas considerações, teríamos um ganho de performance na implementação sequencial ou com threads, basicamente reduzindo o custo de I/O: viabilizamos a performance realizando todos os cálculos de cores, em memória, calculando e armazenando as cores de cada pixel na forma de array ou mapa de bits (bitmap), por exemplo. Este