Par ce que je voulais dire: lorsque vous concevez vos effets secondaires de l'application gratuitement, etc, le code F # sera-t-il distribué automatiquement sur tous les cœurs?F # vous fournit-il un parallélisme automatique?
Non, je ne crains pas. Étant donné que F # n'est pas un langage fonctionnel pur (au sens le plus strict du terme), il serait plutôt difficile de le faire, je crois. La principale façon de faire bon usage du parallélisme dans F # est d'utiliser Async Workflows (principalement via le module Async je crois). La TPL (Task Parallel Library), qui est introduite avec .NET 4.0, va remplir un rôle similaire dans F # (bien qu'elle puisse notamment être utilisée dans tous les langages .NET), bien que je ne puisse pas dire Je sais exactement comment cela va s'intégrer avec le cadre asynchrone existant. Peut-être que Microsoft conseillera simplement l'utilisation du TPL pour tout, ou peut-être qu'ils laisseront les deux comme une option et deviendront finalement la norme de facto ...
Quoi qu'il en soit, voici quelques articles sur la programmation/workflow asynchrone en F # pour vous aider à démarrer.
Non ce n'est pas le cas. Vous devez toujours marshaler explicitement les appels aux autres threads via l'un des nombreux mécanismes supportés par F #.
Non, je suis assez sûr qu'il ne sera pas automatiquement paralléliser pour vous. Il faudrait savoir que votre code était sans effets secondaires, ce qui pourrait être difficile à prouver, d'une part.
Bien sûr, F # peut rendre plus facile pour paralléliser votre code, en particulier si vous n'avez pas d'effets secondaires ... mais c'est une question différente.
Le système de type de F # ne distingue-t-il pas les fonctions pures et impures? Il ne devrait donc pas être si difficile de savoir qu'une opération était sans effets secondaires. –
Merci Jon. En prouvant que vous voulez dire, vous devez utiliser des choses comme les contrats? –
Je ne suis pas au courant de cette distinction, mais c'est loin de dire que ce n'est pas là. Vraisemblablement, cela exclut toute interaction avec le cadre - et qu'en est-il des exceptions? –
Ma compréhension est que ce ne sera pas Parallel Extensions is being modified pour le rendre consommable par F #. Ce qui ne le rendra pas automatiquement multi-thread, devrait le rendre très facile à réaliser.
Bonne prise Richard ... courant dans le sommeil faible je ne peux pas croire que j'ai écrit ça – JoshBerke
Comme les autres mentionnés, F # ne se mettra pas automatiquement à l'échelle des cœurs et nécessitera toujours un framework tel que le port de ParallelFX mentionné par Josh.
F # est généralement associé à un potentiel de traitement parallèle car il est par défaut que les objets sont immuables, ce qui supprime le besoin de verrouillage pour de nombreux scénarios.
Eh bien, vous avez votre réponse, mais je voulais juste ajouter que je pense que c'est la limite la plus importante de F # découlant du fait que c'est un hybride impératif/langage fonctionnel.
Je voudrais voir une extension à F # qui déclare une fonction pur. C'est-à-dire qu'il n'a pas d'effets secondaires qui ne sont pas indiqués par le type de la fonction. L'idée serait qu'une fonction n'est pure que si elle fait référence à d'autres fonctions «connues-pures». Bien sûr, cela ne serait utile que s'il était alors possible d'exiger qu'un délégué soit passé en tant que paramètre de fonction faisant référence à une fonction pure.
Merci Daniel. Je pensais que F # avait un mot-clé "pur". Ce n'est pas? –
F # ne le rend pas automatique, il le rend simplement facile.
Encore une autre chance de lier à Luca's PDC talk. Huit minutes à partir de 52h20 sont une démonstration impressionnante des flux de travail F # asynchrones. Ça berce!
Je vais vérifier cela, merci. –
Sur les annotations de pureté: Code Contracts ont un attribut Pur. Je me souviens avoir déjà entendu certaines parties de la BCL. Potentiellement, cet attribut pourrait aussi être utilisé par des cadres de parallélisation, mais je ne suis pas au courant de ce genre de travail pour le moment. En outre, je ne suis même pas sûr de savoir comment les contacts de code sont utilisables à partir de F #, donc beaucoup d'inconnues ici.
Encore, il sera intéressant de voir comment tout cela se réunit.
Je pense avoir vu quelque chose dans le BCL dans le réflecteur. –
"Étant donné que F # n'est pas un langage fonctionnel pur ". En fait, la pureté n'est pas pertinente. –
@Jon: C'est là que vous vous trompez. C'est très pertinent. Le compilateur ne peut pas faire les suppositions nécessaires de cette façon. – Noldorin
Nous avons eu des compilateurs vectoriels pour des langages impératifs comme Fortran depuis des décennies. Mon point était qu'ils se sont révélés aussi pratiquement inutiles que la pureté dans le contexte du parallélisme multicœur. –