¿Es posible que F # se optimice más que otros lenguajes .Net en el futuro?

Question

¿Es posible que Microsoft pueda hacer programas F #, ya sea en tiempo de ejecución de VM, o más probablemente en tiempo de compilación, detectar que un programa fue creado con un lenguaje funcional y paralelizarlo automáticamente mejor?

En este momento, creo que no hay tal esfuerzo para intentar y ejecutar un programa que se construyó como un programa de subproceso único como un programa de subprocesos múltiples automáticamente.

Es decir, el desarrollador codificará un único programa de subprocesos. Y el compilador escupiría un programa compilado que tiene múltiples subprocesos completos con mutexes y sincronización donde sea necesario.

¿Estas optimizaciones serían visibles en el administrador de tareas en el recuento de subproceso de proceso, o sería un nivel más bajo que eso?

Answer 1

Creo que esto es poco probable en el futuro cercano. Y si sucede, creo que sería más probable en el nivel IL (reescritura de ensamblaje) que en el nivel de idioma (por ejemplo, algo específico de F #/compilador). Es una pregunta interesante, y espero que algunas buenas mentes hayan estado analizando esto y sigan analizando esto por un tiempo, pero a corto plazo, creo que el enfoque será facilitar que los humanos dirijan el Enhebrar/paralelizar programas, en lugar de simplemente hacer que todo suceda como por arte de magia.

(Las características del lenguaje como F# async workflows, y bibliotecas como task-parallel library and others, son buenos ejemplos de progreso a corto plazo aquí; pueden hacer la mayor parte del trabajo pesado para usted, especialmente cuando su programa es más declarativo que imperativo, pero aún así requiere que el programador acepte, haga un análisis de corrección/significado y probablemente haga ligeras modificaciones a la estructura del código para que todo funcione.)

De todos modos, eso es todo especulación; ¿Quién puede decir lo que traerá el futuro? Estoy ansioso por descubrir (y espero que algo de esto suceda). :)

Answer 2

Siendo que F # se deriva de Ocaml y los compiladores Ocaml pueden optimizar sus programas mucho mejor que otros compiladores, probablemente podría hacerse.

Answer 3

Existe una investigación activa para autoparallelización y auto vectorización para una variedad de idiomas. Y uno podría esperar (ya que realmente me gusta F #) que encontrarían una forma de determinar si se utilizó un subconjunto "puro" de efectos secundarios y luego paralelizar eso. Además, dado que Simon Peyton-Jones, el padre de Haskell, trabaja en Microsoft, tengo dificultades para creer que se están produciendo cosas fantásticas.

Answer 4

Creo que la pregunta no entiende el punto de la arquitectura .NET - F #, C# y VB (etc.) todos se compilan en IL, que luego se compila en código máquina a través del compilador JIT. El hecho de que un programa se haya escrito en un lenguaje funcional no es relevante: si hay optimizaciones (como recursividad de cola, etc.) disponibles para el compilador JIT desde el IL, el compilador debería aprovecharlas.

Naturalmente, esto no significa que escribir código funcional sea irrelevante, obviamente, hay formas de escribir IL que se paralelizará mejor, pero muchas de estas técnicas podrían usarse en cualquier lenguaje .NET.

Por lo tanto, no es necesario marcar el IL como proveniente de F # para examinarlo en busca de un posible paralelismo, ni tampoco sería deseable.

Answer 5

Es posible pero poco probable. Microsoft pasa la mayor parte del tiempo soportando e implementando características solicitadas por sus clientes más grandes. Eso generalmente significa C#, VB.Net y C++ (no necesariamente en ese orden).F # no parece estar muy arriba en la lista de prioridades.

Answer 6

No creo que sea posible autovectar el código de una manera generalmente útil y la faceta de programación funcional de F # es esencialmente irrelevante en este contexto.

El problema más difícil es no detectar cuándo se pueden realizar subcomputaciones en paralelo, es determinar cuándo eso no degradará el rendimiento, es decir, cuándo las subtareas tardarán en computar que vale la pena tomar el rendimiento de un engendro paralelo .

Hemos investigado esto en detalle en el contexto de la informática científica y hemos adoptado un enfoque híbrido en nuestra biblioteca F # para Numerics. Nuestros algoritmos paralelos, basados ​​en la Biblioteca de tareas paralelas de Microsoft, requieren un parámetro adicional que es una función que proporciona la complejidad computacional estimada de una subtarea. Esto permite que nuestra implementación evite una subdivisión excesiva y garantice un rendimiento óptimo. Además, esta solución es ideal para el lenguaje de programación F # porque el parámetro de función que describe la complejidad es típicamente una función anónima de primera clase.

Cheers, Jon Harrop.

Answer 7

Microsoft está desarrollando actualmente 2 vías para la paralelización de código: PLINQ (Pararllel Linq, que debe mucho a los lenguajes funcionales) y la Task Parallel Library (TPL) que originalmente fue parte de Robotics Studio. Una versión beta de PLINQ está disponible here.

Pondría mi dinero en PLINQ convirtiéndome en la norma para la auto-paralelización del código .NET.