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

Question

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

En este momento, creo que no existe tal esfuerzo para intentar ejecutar un programa que se creó como un programa de un solo hilo como un programa de múltiples hilos de forma automática.

Es decir, el desarrollador codificaría un programa de un solo hilo. Y el compilador escupiría un programa compilado que es multihilo completo con exclusión mutua y sincronización donde sea necesario.

¿Estas optimizaciones serán visibles en el administrador de tareas en el recuento de subprocesos de proceso, o sería un nivel inferior a ese?

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 de IL (reescritura de ensamblajes) en lugar del nivel de idioma (por ejemplo, algo específico de F # / compilador). Es una pregunta interesante, y espero que algunas mentes finas hayan estado observando esto y continúen haciéndolo por un tiempo, pero a corto plazo, creo que el enfoque estará en hacer que sea más fácil para los humanos dirigir el El subprocesamiento / paralelización de programas, en lugar de que todo suceda como por arte de magia.

(Funciones de lenguaje como F # async Los flujos de trabajo y las bibliotecas como la biblioteca de tareas paralelas y otras , son buenas ejemplos de progreso a corto plazo aquí; pueden hacer la mayor parte del trabajo pesado por usted, especialmente cuando su programa es más declarativo que imperativo, pero aún requieren que el programador opte, haga un análisis para determinar si es correcto / significativo, y probablemente haga leves alteraciones en la estructura del código para que todo funcione.)

De todos modos, eso es toda especulación; ¿Quién puede decir lo que traerá el futuro? Espero con ansias descubrirlo (y con suerte hacer que algo de esto suceda). :)

Answer 2

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

Answer 3

No creo que sea posible autovectorizar 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 no es detectar cuándo se pueden realizar subcomputas en paralelo, es determinar cuándo no se degradará el rendimiento, es decir, cuando las subtareas tomarán el tiempo suficiente para calcular que vale la pena dar el golpe de rendimiento de un engendro paralelo.

Hemos investigado esto en detalle en el contexto de la computación científica y hemos adoptado un enfoque híbrido en nuestra biblioteca F # for Numerics. Nuestros algoritmos paralelos, construidos sobre la biblioteca paralela de tareas 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 suele ser una función de primera clase anónima.

Saludos, Jon Harrop.

Answer 4

Creo que la pregunta no comprende el punto de la arquitectura .NET: F #, C # y VB (etc.) se compilan en IL, que luego se compila en código de 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 la recursión de la 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 paralizarán 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 paralelismo potencial, ni sería deseable tal cosa.

Answer 5

Hay una investigación activa para la paralelización automática y la vectorización automática para una variedad de idiomas. Y uno podría esperar (ya que realmente me gusta F #) que concibirían una manera de determinar si un " puro " se usó un subconjunto libre de efectos secundarios y luego se puso en paralelo. Además, desde que Simon Peyton-Jones, el padre de Haskell está trabajando en Microsoft, me cuesta trabajo no creer que se avecinan cosas fantásticas.

Answer 6

Es posible pero poco probable. Microsoft dedica la mayor parte de su tiempo a respaldar e implementar las características solicitadas por sus clientes más importantes. Eso generalmente significa C #, VB.Net y C ++ (no necesariamente en ese orden). F # no parece que esté arriba en la lista de prioridades.

Answer 7

Microsoft está desarrollando actualmente 2 vías para la paralelización del código: PLINQ (Pararllel Linq, que debe mucho a los lenguajes funcionales) y la Biblioteca de tareas paralelas (TPL), que originalmente era parte de Robotics Studio. Una versión beta de PLINQ está disponible aquí / a>.

Pondría mi dinero en que PLINQ se convierta en la norma para la paralelización automática del código .NET.