f# - sharp - programacion.net ejemplos
¿Es posible que F#se optimice más que otros lenguajes.Net en el futuro? (7)
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 lenguaje (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 flujos de trabajo asincrónicos F # y bibliotecas como la biblioteca paralela a tareas y otras son buenos ejemplos de progreso a corto plazo, pueden hacer la mayor parte del trabajo pesado para usted, especialmente cuando su programa es más declarativo que imperativo, pero todavía requieren 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 toda especulación; ¿Quién puede decir lo que traerá el futuro? Estoy ansioso por descubrir (y espero que algo de esto suceda). :)
¿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 construido con un lenguaje funcional y paralelizarlo automáticamente mejor?
En este momento, creo que no hay tal esfuerzo para tratar de ejecutar un programa que se creó 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 completo con mutexes y sincronización donde sea necesario.
¿Estas optimizaciones serían visibles en el administrador de tareas en el recuento de subprocesos de proceso, o sería un nivel más bajo que eso?
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án mejor, pero muchas de estas técnicas podrían usarse en cualquier lenguaje .NET.
Por lo tanto, no hay necesidad de marcar el IL como procedente de F # para examinarlo en busca de un posible paralelismo, ni sería deseable.
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.
Hay 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, me resulta difícil no creer que vienen cosas fantásticas.
Siendo que F # se deriva de compiladores Ocaml y Ocaml puede optimizar sus programas mucho mejor que otros compiladores, probablemente podría hacerse.
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 era parte de Robotics Studio. Una versión beta de PLINQ está disponible aquí .
Pondría mi dinero en PLINQ convirtiéndome en la norma para la auto-paralelización del código .NET.
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 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 el tiempo suficiente para calcular que vale la pena tomar el golpe de 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 la 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.
Saludos, Jon Harrop.