Atores - Concorrência ou paralelismo?

[Gustavo Henrique Lima Pinto]

Pessoal, 

ainda estou dando meus primeiros passos em scala, e recentemente me surgiu uma dúvida que eu ainda não tenho muita certeza sobre.

Pelo que eu tenho visto, se usa muito atores para questões de concorrência (IO), e muito pouco tenho visto sobre paralelismo (CPU). Nesse caso, parece que o apropriado é usar coleções paralelas, e futures.

É isso mesmo? Actors são mais convenientes para concorrência? Ou posso considera-los (grosseiramente) como threads de alto nível, que podem resolver qualquer problema?

Valeu!

[Felipe Hummel]

Opa Gustavo, primeiramente acho que essa sua diferenciação entre Concorrência e Paralelismo (IO vs CPU) um pouco confusa. Acho que essa resposta no SO elucida bem a questão (junto com o comentário da mesma:  concurrency as a property of a program or system (and parallelism as the run-time behaviour of executing multiple tasks at the same time)

Atores podem ser usados para "qualquer problema". Eles são uma abstração pra facilitar a construção de programas que podem (ou não) rodar de forma paralela. Você pode ter 1 milhão de atores que são executados em sequência, um após o outro. Pode ter um programa com 1.000 atores com N atores rodando paralelamente o tempo todo.

Por exemplo, eu tenho um programa que faz download de feeds RSS. Eu tenho um Ator para cada feed que eu quero baixar.   Eles rodam concorrentemente e paralelamente em Threads diferentes. Uso vários Atores para aproveitar o fato de que a maioria passa bastante tempo esperando pelo IO.

Em outro programa, eu tenho que calcular a similaridade entre 1 Array e outros ~40 mil arrays (pra milhares de arrays por minuto). Isso é bem CPU-bound. Com atores eu posso pegar essa tarefa dividir em N partes (40.000 / N) e mandar uma parte para cada Ator executar em paralelo. (na verdade nesse caso uso Futures, mas poderia ser Actors).

Felipe Hummel

2013/2/13 Gustavo Henrique Lima Pinto <gustavohe...@gmail.com>

--
 
---
Você está recebendo esta mensagem porque se inscreveu no grupo "scala-br" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para scala-br+u...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

[Rafael de F. Ferreira]

Concorrência é uma propriedade da semântica da linguagem, relacionada (de um jeito complicado) a não-determinismo. Para alguns domínios ela é uma propriedade necessária. Por exemplo é impossível fazer um servidor de rede que atenda a mais de um usuário ao mesmo tempo sem concorrência.

Existem modelos de programação onde a concorrência é usada não só para atender aos requisitos de domínio, mas é um mecanismo de abstração fundamental. Atores é um exemplo desse modelo.

Paralelismo é uma propriedade do modelo de custo de uma linguagem/sistema, onde o custo para fazer uma operação é uma função do número de CPUs. Paralelismo não deve afetar a semântica de um programa, só a performance.

Resumindo, concorrência é quando a sua linguagem permite fazer "mais de uma coisa ao mesmo tempo" e paralelismo é quando a linguagem consegue fazer alguma coisa mais rápido com N unidades de processamento (CPUs/cores) do que com uma.

Dá para ter paralelismo sem concorrência (por exemplo processadores com SIMD) e dá para ter concorrência sem paralelismo (por exemplo em máquinas com uma unidade de processamento só e um sistema/linguagem multitarefa onde slots de computação são distribuídos por um scheduler).

Mas é muito comum implementar paralelismo usando um substrato concorrente (é o que a biblioteca de parallel collections de Scala faz, por exemplo). Além disso, existem modelos de concorrência que distribuem as tarefas entre várias CPUs, o que é o caso dos Actors de Scala e do Akka, aí você pode fazer o seu programa concorrente e esperar um ganho de performance pelo paralelismo do sistema.

--
Rafael de F. Ferreira.
http://www.rafaelferreira.net/

2013/2/13 Felipe Hummel <felipe...@gmail.com>

[Paulo "JCranky" Siqueira]

Sobre futuros, se estiver usando Akka, muitas vezes vamos acabar usando eles em conjunto com atores. Por exemplo, podemos esperar por uma resposta de um ator, e usar futuros para que essa espera não seja blocante. Ou seja, Futures são elementos muito mais poderosos do que pode parecer à primeira vista (e nem começamos a falar de composição de futuros ainda).

[]s,

2013/2/13 Rafael de F. Ferreira <raf...@rafaelferreira.net>

--
Paulo "JCranky" Siqueira
http://www.jcranky.com/
http://lojinha.paulosiqueira.com.br/