Implementar recursos adicionais do trabalho prático 1
fjorgemota opened this issue · comments
Como tratamento em casos no qual o número de threads é menor do que o número de itens no vetor e também no qual o número de itens no vetor dividido pelo número de threads não dá um número inteiro (tendo, portanto, resto > 0).
@Caique-Marques, sugestões são bem vindas aqui. ;)
Vejo que a modularização já resolveria o problema. Quando a divisão de vecsize com nthread não fosse exata, pegava o resultado e mandava as threads resolverem os cálculos normalmente. Já o resto, uma ou mais threads (depende do caso) realizaria as operações faltantes - o que também poderia solucionar o problema de nthreads > vecsize.
Outra opção que vejo para a divisão inexata, seria fazer com que a primeira thread ficasse com o valor da divisão mais o resto (ou seja, realizaria divisao+resto operações), enquanto as outras processariam normalmente.
@Caique-Marques.
Também tinha pensado em deixar todo o trabalho adicional para uma thread. Mas nesse caso deixamos de resolver um problema igualmente importante e cobrado neste trabalho: O tratamento de uma situação no qual o número de itens no vetor é menor do que o número de threads. Sugiro, assim, fazer um balanceamento dos itens adicionais (ou seja, divisão+resto) entre diferentes threads, de forma que, quando o número de itens do vetor for menor que o número de threads, tenhamos uma divisão exatamente igual à zero e um resto igual ao número de itens no vetor, e assim possamos fazer um balanceamento de tal número entre as threads existentes.
O que acha, @Caique-Marques?
Pode ser, mas fico questionando a respeito quando as divisões forem muito discrepantes, por exemplo 5/16, não vejo como todas as threads irão realizar as operações, portanto, é possível "excluir" algumas do processo?
Por isso que o balanceamento vai ser apenas parcial.
Eu vou implementar essa solução aqui. Assim que terminar eu faço o commit e envio para o Github. Portanto, não se preocupe com essa issue, se preocupe com a #3 que já vai ser um bom desafio para treinar modularização ;) - Beleza?
Abs.
Consegui implementar o algoritmo corretamente aqui.
Ficou mais simples do que eu pensava, e acredito que com a modularização proposta na issue #3 o sistema venha a ficar ainda mais simples.
Entretanto, só não vou comittar ainda pois enviei um e-mail para o professor questionando sobre se é necessário seguir a constante NTHREADS sempre, pois há casos em que ela não necessariamente precisaria ser respeitada. (como quando VECSIZE < NTHREADS).
Abs.
(era para o Github ter fechado a issue pelo commit, como ele não fechou, enfim, está concluido o trabalho (veja commit d5c262c para referência))