É possível que F # será otimizado mais do que outras linguagens .Net no futuro?

Question

É possível que a Microsoft será capaz de fazer programas F #, quer em tempo de execução VM, ou mais provavelmente em tempo de compilação, detectar que um programa foi construído com uma linguagem funcional e automaticamente paralelizar-lo melhor?

Agora eu acredito que não existe tal esforço para tentar executar um programa que foi criado como um programa de rosca única como um programa multi threaded automaticamente.

Ou seja, o desenvolvedor poderia codificar um único programa de rosca. E o compilador iria cuspir um programa compilado que é multi-threaded completo com semáforos e sincronização quando necessário.

Será que essas otimizações ser visível no Gerenciador de tarefas na contagem da linha de processo, ou seria o nível mais baixo do que isso?

Answer 1

Eu acho que isso é improvável no futuro próximo. E se isso acontecer, eu acho que seria mais provável no nível IL (montagem reescrever) ao invés de nível de linguagem (por exemplo, algo específico para F # / compilador). É uma pergunta interessante, e espero que algumas mentes finas foram olhando para isso e vai continuar a olhar para isso por um tempo, mas no curto prazo, acho que o foco estará em tornar mais fácil para os seres humanos para dirigir o rosqueamento / paralelização de programas, em vez de apenas ter tudo acontecer como que por magia.

(Língua características como F # async workflows , e bibliotecas, como o biblioteca de tarefas paralelas e outros , são bons exemplos de progresso a curto prazo aqui, pois eles podem fazer a maior parte do trabalho pesado para você, especialmente quando o programa é mais declarativo do que imperativo, mas eles ainda exigem o programador para opt-in, fazer uma análise quanto à correção / significação, e provavelmente make ligeiras alterações na estrutura do código para fazer tudo funcionar.)

De qualquer forma, isso é tudo especulação; quem pode dizer o que o futuro trará? Estou ansioso para descobrir (e, esperamos fazer alguns dos que isso aconteça). :)

Answer 2

Sendo que F # é derivado de compiladores Ocaml e OCaml pode otimizar seus programas muito melhor do que outros compiladores, ele provavelmente poderia ser feito.

Answer 3

Eu não acredito que é possível autovectorize código de uma maneira geral, útil e a faceta de programação funcional F # é essencialmente irrelevante neste contexto.

O problema mais difícil não é detectar quando você pode executar subcomputations em paralelo, é determinar quando que não vai desempenho degrade, ou seja, quando as subtarefas terá suficientemente longo para calcular que vale a pena tomar a batida de um spawn paralelo performance.

Nós pesquisamos isso em detalhes no contexto da computação científica e adotamos uma abordagem híbrida em nossa F # para a biblioteca Numerics. Nossos algoritmos paralelos, construídos em cima de Tarefas da Microsoft Biblioteca paralela, requerem um parâmetro adicional que é uma função dando a complexidade computacional estimado de uma subtarefa. Isso permite que a nossa implementação para evitar a subdivisão excessiva e garantir o desempenho ideal. Além disso, esta solução é ideal para a linguagem de programação # F porque o parâmetro função que descreve a complexidade é tipicamente uma função de primeira classe anônima.

Cheers, Jon Harrop.

Answer 4

Eu acho que a questão não é o ponto do .NET architecture-- F #, C # e VB (etc.) todos get compilado para IL, que então é compilado para código de máquina via o compilador JIT. O fato de que um programa foi escrito em uma linguagem funcional não é relevant-- se há otimizações (como recursão de cauda, ??etc.) disponíveis para o compilador JIT do IL, o compilador deve tirar proveito dela.

Naturalmente, isto não significa que escrever código funcional é irrelevant-- obviamente, existem maneiras de escrever IL que paralelizar melhor-- mas muitas dessas técnicas podem ser usadas em qualquer linguagem .NET.

Assim, não há necessidade de bandeira do IL como vindo de F #, a fim de examiná-lo para o potencial de paralelismo, nem uma coisa desejável.

Answer 5

Não há pesquisa ativa para autoparallelization e auto vetorização para uma variedade de idiomas. E se poderia esperar (desde que eu realmente gosto de F #) que eles iriam concive uma maneira de determinar se foi utilizado um subconjunto livre de efeito colateral "puro" e, em seguida, paralelizar isso. Também desde Simon Peyton-Jones o pai de Haskell está trabalhando no Microsoft eu tenho um tempo difícil não beliving há algum fantástico coisas comming.

Answer 6

É possível, mas improvável. Microsoft passa a maior parte de seu tempo apoiando e recursos solicitados pelos seus maiores clientes de execução. Isso normalmente significa C #, VB.Net e C ++ (não necessariamente nessa ordem). se F # não parecer que é no topo da lista de prioridades.

Answer 7

A Microsoft está actualmente a desenvolver 2 caminhos para a paralelização de código: PLINQ (Pararllel Linq, que deve muito a linguagens funcionais) e da biblioteca paralela de tarefas (TPL) que era originalmente parte do Robotics Studio. A versão beta do PLINQ está disponível aqui .

Eu colocaria meu dinheiro em PLINQ se tornando a norma para auto-paralelização de código .NET.