Python Eficaz

def run(self):
self.factors = list(factorize(self.number))
Depois, iniciamos uma thread para fatorar cada número em paralelo.
start = time()
threads = []
for number in numbers:
thread = FactorizeThread(number)
thread.start()
threads.append(thread)
Por fim, esperamos que todas as threads terminem.
for thread in threads:
thread.join()
end = time()
print('Took %.3f seconds' % (end - start))
>>>
Took 1.061 seconds
Surpresa! O resultado levou ainda mais tempo que a implementação serial de
factorize. Com uma thread por número, poderíamos esperar um desempenho um
pouco menor que 4× mais rápido, e de fato isso acontece em outras linguagens.
Não se chega a 4× por conta do trabalho adicional que o Python teve para criar
as threads e coordená-las durante a execução. Em máquinas com apenas dois
núcleos (dual-core e afins) poderíamos esperar uma melhora no desempenho de
quase 2×. Contudo, jamais poderíamos esperar que o desempenho dessas threads
fosse pior quando se tem mais de um núcleo de CPU para explorar. Esse
pequeno exemplo demonstra o efeito nefasto do GIL em programas que rodem
sobre o interpretador-padrão CPython.
Existem maneiras de fazer o CPython usar mais núcleos, mas elas não
funcionam com a classe Thread padrão (consulte o Item 41: “Considere usar
concurrent.futures para obter paralelismo real”) e por isso uma implementação
dessas precisaria de um esforço substancial por parte do programador. Sabendo
dessas limitações, poderíamos honestamente questionar: afinal, o Python suporta
mesmo esse negócio de threads? Há duas boas razões para tal.
Primeiro, muitas threads fazem com que nosso programa pareça fazer muitas
www.full-ebook.com