Usando Clojure em vez de Python por razões de escalabilidade (vários núcleos), boa ideia? [fechadas]


8

Depois de ler http://clojure.org/rationale e outras comparações de desempenho entre o Clojure e muitas linguagens, comecei a pensar que, além da facilidade de uso, não deveria mais codificar no Python, mas no Clojure. Na verdade, comecei a me sentir irresponsável por não aprender Clojure, vendo seus benefícios.

Isso faz sentido? Não posso fazer um uso realmente eficiente de todos os núcleos usando uma linguagem mais imperativa como Python do que um dialeto Lisp ou outra linguagem funcional? Parece que todos os benefícios advêm do uso de dados imutáveis. Não posso fazer exatamente isso em Python e ter todos os benefícios?

Uma vez comecei a aprender um pouco de Common Lisp, li e fiz quase todos os exercícios de um livro emprestado da minha biblioteca da universidade (achei muito bom, apesar da baixa popularidade na Amazon). Mas, depois de um tempo, me vi lutando demais para fazer algumas coisas simples. Eu acho que há coisas que são mais imperativas em sua natureza, que dificultam modelar essas coisas de maneira funcional.

Então, o Python é tão poderoso quanto o Clojure para criar aplicativos que tiram vantagem desse novo futuro multinúcleo?

Observe que não acho que o uso de semáforos, mecanismos de bloqueio ou outro mecanismo de concorrência semelhante seja uma boa alternativa à paralelização "automática" de Clojure.


5
Com base no que você parece estar tentando realizar, você também deve considerar o erlang .
Jerry Coffin

2
Ainda não está aqui e pode nunca funcionar bem, mas os planos de STM dos caras do PyPy (bem, principalmente um: Armin Rigo) parecem legais e estão tangivelmente relacionados a essa pergunta.

Respostas:


4

Não posso fazer um uso realmente eficiente de todos os núcleos usando uma linguagem mais imperativa como Python do que um dialeto lisp ou outra linguagem funcional?

Você definitivamente pode . Dependendo do tipo do problema (por exemplo, processar partes claramente separáveis ​​de alguma grande tarefa computacional em paralelo), pode até ser bastante fácil. Acho que a maior parte da concorrência no mundo ainda é feita diretamente em linguagens imperativas, embora o paradigma esteja mudando para soluções funcionais.

O Python não é exatamente conhecido por seus recursos de simultaneidade. Um exemplo de uma linguagem imperativa bem estabelecida com excelente suporte a simultaneidade é o Java.

Parece que todos os benefícios advêm do uso de dados imutáveis. Não posso fazer exatamente isso em Python e ter todos os benefícios?

O truque com dados imutáveis ​​é que, se você fizer isso com estruturas de dados simples e tradicionais, como matrizes, você terá uma cópia maciça e coleta de lixo, prejudicando o desempenho. Em vez disso, você deseja dados efetivamente imutáveis , que podem ser implementados com várias estruturas de dados persistentes , como é feito no Clojure. Tais estruturas poderiam ser feitas em praticamente qualquer linguagem como bibliotecas, mas é claro que o suporte direto à linguagem é sempre melhor.


8

O Python é extremamente ruim para aplicativos que precisam de vários threads, mas é causado por deficiência nas máquinas virtuais disponíveis, não na própria linguagem. Os geradores do Python seriam realmente bons candidatos à paralelização implícita. O problema é que a implementação padrão, CPython, pode executar apenas o código python em uma CPU, apenas chamadas em bibliotecas nativas podem ser executadas em paralelo. O tempo de execução do PyPy planeja corrigi-lo, mas ainda não existe e, embora as implementações Jython e IronPython não tenham a limitação, elas são bastante incompletas (elas não possuem grande parte da biblioteca padrão, você deve usar a biblioteca padrão do ambiente de hospedagem neles).

No entanto, existem muitas outras linguagens projetadas e implementadas com paralelismo. É claro que o paralelismo é muito mais fácil em linguagens funcionais, e é por isso que todas as linguagens com bom suporte a paralelismo são funcionais ou têm forte suporte para programação funcional. Eu posso imaginar:

  • Haskell , a linguagem funcional pura e não estrita mais usada. Sua natureza pura e não estrita permite que o compilador paralelize algumas coisas implicitamente.
  • Erlang é uma linguagem funcional estrita, projetada especificamente para implementar servidores paralelos robustos, com suporte interno para distribuição em clusters.
  • Clojure, é claro. Como outros lisps, ele é projetado para programação funcional, mas também suporta programação imperativa.
  • Go é uma nova linguagem processual compilada projetada para simultaneidade, embora nem os tempos de execução nem a própria linguagem ainda estejam muito maduros.
  • Rust é uma nova linguagem processual compilada projetada para simultaneidade, baixa sobrecarga e verificação estática da segurança de memória e simultaneidade. Também não é muito maduro.

Go acabou de lançar o seu 1.0 após cerca de dois anos de desenvolvimento de código aberto.
Sonia

1
E o Python possui o pacote de multiprocessamento.
Sonia

Eu realmente não sabia que o haskell pode ser rápido (mais rápido que o python). Eu 'aprendi' no meu primeiro curso de programação, eu definitivamente preciso vê-lo novamente.
Julio Rodrigues

1
@Vandell: Haskell é uma linguagem compilada estaticamente, por isso é muito mais rápida. De acordo com o The Computer Language Benchmarks Game , Haskell é aproximadamente comparável a Java e Mono.
Jan Hudec

@ Sonia: ... que é o que eu chamo de não muito madura. Geralmente, são necessários 10 anos ou mais para que a especificação do idioma seja estabelecida. Eu pelo menos espero que o Go siga Java e C # e obtenha genéricos um dia.
Jan Hudec

2

Os caras aqui deram respostas realmente excelentes.

A programação simultânea geralmente é difícil por causa do "estado de compartilhamento". A programação funcional pode não ser a resposta definitiva, mas certamente a torna possível sem perder o cabelo.

O Clojure com certeza é uma opção viável, mas mesmo com suas excelentes ferramentas de concorrência, você pode precisar criar outra coisa. Verifique Prismatic para um exemplo:

Nossa escolha de idioma de back-end é Clojure na JVM. Existem outras grandes linguagens funcionais na JVM, como Scala, mas o que gostamos no Clojure é que ele possui um núcleo pequeno e simples focado no processamento de dados representados em seu excelente conjunto de estruturas de dados persistentes (ou seus equivalentes java.util mutáveis, quando houver necessidade). Embora façamos uso pesado do núcleo do Clojure, não usamos suas primitivas de simultaneidade (átomos, refs, STM etc.) porque uma função como pmap não possui controle refinado suficiente para nossas necessidades. Em vez disso, optamos por criar nossas próprias abstrações de simultaneidade no Clojure sobre o excelente pacote java.util.concurrent.

Se você realmente quer enlouquecer, verifique também a Julia Programming Language .

Julia não impõe nenhum estilo particular de paralelismo ao usuário. Em vez disso, fornece vários blocos de construção principais para computação distribuída, tornando-o flexível o suficiente para suportar vários estilos de paralelismo e permitindo que os usuários adicionem mais.


2

Além do que Jan Hudec escreveu, eu gostaria de mencionar o Scala , que, além de um estilo de programação funcional, também suporta um estilo de programação imperativo / orientado a objetos.

Scala oferece paralelismo através de atores (também usado por Erlang).

Observe que não acho que o uso de semáforos, mecanismos de bloqueio ou outro mecanismo de concorrência semelhante seja uma boa alternativa à paralelização 'automática' do Clojure.

Os atores são uma maneira orientada a objetos de abstrair dos processos / encadeamentos subjacentes: você basicamente vê apenas objetos sendo executados simultaneamente e enviando mensagens um para o outro. Portanto, se você deseja uma maneira orientada a objetos de implementar o paralelismo, também daria uma olhada nas linguagens (ou estruturas) que suportam o modelo de ator.

Você pode encontrar alguns links na wikipedia , para Python existe, por exemplo, Pykka .

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.