Est-il possible que F # soit optimisé plus que d'autres langages .Net à l'avenir?

Question

Est-il possible que Microsoft puisse créer des programmes F #, soit au moment de l'exécution de la machine virtuelle, ou plus vraisemblablement au moment de la compilation, détecter qu'un programme a été créé avec un langage fonctionnel et le paralléliser automatiquement?

À l'heure actuelle, j'estime qu'aucun effort de ce type n'a été fait pour essayer d'exécuter automatiquement un programme construit en tant que programme à un seul thread en tant que programme à plusieurs threads.

C’est-à-dire que le développeur coderait un programme à thread unique. Et le compilateur cracherait un programme compilé multi-thread complet avec mutex et synchronisation si nécessaire.

Ces optimisations seraient-elles visibles dans le gestionnaire de tâches dans le nombre de threads de processus ou serait-il de niveau inférieur à celui-ci?

Answer 1

Je pense que cela est peu probable dans un proche avenir. Et si cela se produit, je pense que ce serait plus probable au niveau IL (réécriture d'assemblage) plutôt qu'au niveau de la langue (par exemple, quelque chose de spécifique à F # / compilateur). C'est une question intéressante, et je m'attends à ce que certains grands esprits se penchent sur cette question et continueront à l'examiner pendant un certain temps, mais à court terme, je pense que l'objectif sera de permettre aux humains de diriger plus facilement la threading / parallélisation des programmes, plutôt que de tout avoir comme par magie.

(Fonctions linguistiques telles que F # async Les flux de travail et les bibliothèques telles que la bibliothèque parallèle à une tâche et autres sont satisfaisants. Voici des exemples de progrès à court terme: ils peuvent faire le gros du travail pour vous, en particulier lorsque votre programme est plus déclaratif qu’impératif, mais ils exigent néanmoins du programmeur qu’il choisisse, effectue une analyse de correction / signification et de légères modifications à la structure du code pour que tout fonctionne correctement.)

Quoi qu'il en soit, ce ne sont que des spéculations; qui peut dire ce que l'avenir apportera? J'ai hâte de le savoir (et, espérons-le, de le réaliser). :)

Answer 2

Etant donné que F # est dérivé d’Ocaml et que les compilateurs peuvent optimiser vos programmes bien mieux que d’autres compilateurs, cela pourrait probablement être fait.

Answer 3

Je ne pense pas qu'il soit possible d'autovectoriser le code de manière généralement utile et la facette de programmation fonctionnelle de F # est essentiellement sans importance dans ce contexte.

Le problème le plus difficile n’est pas de détecter le moment où vous pouvez effectuer des sous-calculs en parallèle, mais de déterminer quand cela ne dégradera pas les performances, c’est-à-dire lorsque les sous-tâches prendront suffisamment de temps pour calculer qu’il vaut la peine de prendre le coup de performance d’un spawn parallèle.

Nous avons étudié cela en détail dans le contexte du calcul scientifique et nous avons adopté une approche hybride dans notre bibliothèque F # for Numerics. Nos algorithmes parallèles, construits sur la bibliothèque de tâches parallèle de Microsoft, nécessitent un paramètre supplémentaire qui est une fonction donnant la complexité de calcul estimée d'une sous-tâche. Cela permet à notre implémentation d'éviter une subdivision excessive et d'assurer des performances optimales. De plus, cette solution est idéale pour le langage de programmation F # car le paramètre de fonction décrivant la complexité est généralement une fonction anonyme de première classe.

Salut, Jon Harrop.

Answer 4

Je pense que la question manque l’intérêt de l’architecture .NET - F #, C # et VB (etc.) sont tous compilés en IL, qui sont ensuite compilés en code machine via le compilateur JIT. Le fait qu'un programme ait été écrit dans un langage fonctionnel n'est pas pertinent - s'il existe des optimisations (telles que la récursion par la queue, etc.) disponibles pour le compilateur JIT à partir de l'IL, le compilateur devrait en tirer parti.

Naturellement, cela ne signifie pas que l'écriture de code fonctionnel est sans importance - il existe évidemment des façons d'écrire IL qui permet une meilleure parallélisation - mais bon nombre de ces techniques pourraient être utilisées dans n'importe quel langage .NET.

Il n’est donc pas nécessaire de signaler l’IL comme étant issu de F # afin de rechercher un parallélisme potentiel, et une telle chose ne serait pas souhaitable.

Answer 5

Des recherches actives sur l'autoparallélisation et la vectorisation automatique sont disponibles pour différentes langues. Et on pourrait espérer (puisque j'aime beaucoup F #) qu'ils concerteraient un moyen de déterminer si un "pur" ou "pur" sous-ensemble libre d'effets secondaires a été utilisé et ensuite paralléliser cela. De plus, depuis que Simon Peyton-Jones, le père de Haskell, travaille chez Microsoft, j'ai du mal à croire que des choses fantastiques vont se produire.

Answer 6

C'est possible mais peu probable. Microsoft passe le plus clair de son temps à supporter et à mettre en œuvre les fonctionnalités demandées par leurs plus gros clients. Cela signifie généralement C #, VB.Net et C ++ (pas nécessairement dans cet ordre). F # ne semble pas figurer en bonne place sur la liste des priorités.

Answer 7

Microsoft développe actuellement deux voies pour la parallélisation du code: PLINQ (Pararllel Linq, qui doit beaucoup aux langages fonctionnels) et la Task Parallel Library (TPL), qui faisait à l'origine partie de Robotics Studio. Une version bêta de PLINQ est disponible ici .

Je mettrais mon argent sur PLINQ, qui deviendrait la norme en matière de parallélisation automatique du code .NET.