Mudanças entre as edições de "Python Concorrente"
| Linha 7: | Linha 7: | ||
=== Concorrência em Python === |
=== Concorrência em Python === |
||
| − | Ao contrário de Go e Erlang, Python não foi originalmente projetada com foco em programação concorrente. |
+ | Ao contrário de Go e Erlang, Python não foi originalmente projetada com foco em programação concorrente. O interpretador padrão (CPython) tem uma trava global (a GIL) que impede a execução simultânea de threads escritas em Python. Isso não era um problema quando as CPUs tinham apenas um núcleo, mas hoje até celulares tem CPUs multi-core. Esta é uma limitação que existe também no interpretador padrão de Ruby (MRI), e o motivo de existir é simplificar o código em C do interpretador e facilitar a intergração de bibliotecas externas em C que não são thread-safe. As implementações de Python e Ruby em Java (Jython e JRuby) não tem a limitação da GIL. |
| − | === Mesmo com a GIL dá para usar threads === |
||
| + | === Usando threads apesar da GIL === |
||
| ⚫ | A GIL |
||
| + | |||
| ⚫ | A GIL impede qualquer paralelismo no código escrito em Python, mas as funcionalidades da plataforma (interpretador, bibliotecas, API do sistema operacional) não são necessariamente limitadas pela GIL. '''Todas as chamadas da biblioteca padrão de Python que fazem I/O de rede ou arquivos liberam a GIL.''' Portanto, em qualquer processamento onde o limitante é o I/O (''I/O bound'') o uso de threads em Python pode acelerar muito o processamento em relação a uma solução sequencial que vai passar a maior parte do tempo aguardando I/O. Mas para processamentos limitados pela CPU (''CPU bound'') usar threads em Python não ajuda e pode até atrapalhar. Claro que bibliotecas externas escritas em C |
||
Edição das 14h02min de 16 de janeiro de 2015
Concurrency is about dealing with lots of things at once. Parallelism is about doing lots of things at once.
Rob Pike, co-inventor da linguagem Go -- Concurrency is not Parallelism (it's better)
Concorrência em Python
Ao contrário de Go e Erlang, Python não foi originalmente projetada com foco em programação concorrente. O interpretador padrão (CPython) tem uma trava global (a GIL) que impede a execução simultânea de threads escritas em Python. Isso não era um problema quando as CPUs tinham apenas um núcleo, mas hoje até celulares tem CPUs multi-core. Esta é uma limitação que existe também no interpretador padrão de Ruby (MRI), e o motivo de existir é simplificar o código em C do interpretador e facilitar a intergração de bibliotecas externas em C que não são thread-safe. As implementações de Python e Ruby em Java (Jython e JRuby) não tem a limitação da GIL.
Usando threads apesar da GIL
A GIL impede qualquer paralelismo no código escrito em Python, mas as funcionalidades da plataforma (interpretador, bibliotecas, API do sistema operacional) não são necessariamente limitadas pela GIL. Todas as chamadas da biblioteca padrão de Python que fazem I/O de rede ou arquivos liberam a GIL. Portanto, em qualquer processamento onde o limitante é o I/O (I/O bound) o uso de threads em Python pode acelerar muito o processamento em relação a uma solução sequencial que vai passar a maior parte do tempo aguardando I/O. Mas para processamentos limitados pela CPU (CPU bound) usar threads em Python não ajuda e pode até atrapalhar. Claro que bibliotecas externas escritas em C