10
votes

Quels sont les avantages des expressions Lambda pour les systèmes multicœux?

Le didacticiels Java pour Lambda Expressions dit suivant:

Cette section traite des fonctionnalités incluses dans le projet Lambda, qui vise soutenir la programmation dans un environnement multi-enseignements en ajoutant des fermetures et caractéristiques connexes à la langue java.

Ma question est de savoir quels avantages concrets ai-je avec les expressions de Lambda selon les systèmes multicœux et la programmation simultanée / parallèle?


1 commentaires

lambdafaq.org/whay-are-lambda-expressions -Ed-ajoué-to-java " L'avantage que ce changement apporte est que les collections peuvent désormais organiser leur propre itération en interne, transférer la responsabilité de la parallélisation du code client dans le code de la bibliothèque. "


3 Réponses :


8
votes

Le parallélisme est trivial pour mettre en œuvre par ex. Si vous avez une collection et que vous implémentez une Lambda ainsi: xxx

puis la collection elle-même peut paralliser cette opération sans que vous ayez à faire le filetage, etc. Le parallélisme est traité dans la collection mappe () implémentation.

dans un système purement fonctionnel (I.E. Aucun effet secondaire), vous pouvez le faire pour chaque Lambda. Pour un environnement non purement fonctionnel, vous devez sélectionner le Lambdas pour lequel cela s'appliquerait (car votre Lambda peut ne pas fonctionner en toute sécurité en parallèle). par exemple. dans Scala, vous devez explicitement Prendre le vue parallèle sur une collection afin de mettre en œuvre ce qui précède.


6 commentaires

Juste pour ajouter à votre réponse: cette capacité à paralléliser n'est pas spécifique à Lambdas, mais aux foncteurs, c'est-à-dire encapsulation de la logique de traitement dans un objet. Avec les versions précédentes de Java, vous pourriez déjà faire cela, mais c'était ... maladroit;) Les Lambdas sont donc un grand sucre syntaxique pour écriture des foncteurs, en particulier des foncteurs d'un coup.


@Serious: C'est un peu trompeur d'appeler le sucre syntaxique Lambdas. Ils sont mis en œuvre très différemment aux classes intérieures anonymes, ce qui aurait été l'option "maladroite" antérieure. En fin de compte, ils seront beaucoup plus efficaces dans la paralLeLising (certains) du code pour les systèmes multicœurs.


Intéressant, comment sont-ils mis en œuvre en Java? Parce que dans C # Lambdas sont compilés sous forme de classes et de méthodes, la seule sorte de foncteur une plate-forme de faible niveau prend en charge. La partie de fermeture est traitée via des champs. Comme .net et le jre sont des plates-formes similaires, je pense que cela devrait être similaire ...


En regardant Java 8 (version précoce), ils sont mis en œuvre comme des classes anonymes. Je ne suis pas sûr que c'est la mise en œuvre finale


Pour autant que je sache (j'ai lu précoce des spécifications de projets Lambda), des classes intérieures anonymes sont également utilisées en Java.


Je pense que dans Java 8 Lambda Expressions sont compilées dans des implémentations de classe, car les fonctions ne sont pas traitées comme des citoyens de première classe ou en d'autres termes, il n'y a pas de type de fonction en Java. De plus, ce n'est pas seulement des expressions Lambda aidant à des systèmes multicœurs, mais les améliorations de l'API de collections pour leur permettre d'utiliser des expressions Lambda qui ajoutent à l'avantage possible dans les systèmes multicœurs.



7
votes

Quelque matériau de référence:


0 commentaires

2
votes

En tout respect de la fonction Java 8 Lambda et d'intention des développeurs, je voudrais poser: Quelle est la nouvelle et pourquoi elle est meilleure que l'approche de la fonction d'interface / méthode traditionnelle? Pourquoi c'est mieux que (supposons) foreach (IAPPLY) où:

iapply est interface xxx

comment Il empêche le parallélisme? Au moins la mise en œuvre de l'IAPPLY peut être réutilisée, héritée (étendue), être mise en œuvre en classe statique.
Le dernier argument est important après des dizaines d'exemples d'erreurs de juniors que j'ai vus, qui manquent que le code Lambda accède à cela de la classe extérieure peut être une cause de séjours de classe en mémoire après une référence distincte, elle est déjà null.
De ce point de vue, la référence aux membres statiques d'une classe sont très importantes (les analogies d'un cas de délégués C # "et principalement - d'une main-Lambda est une excellente encapsulation, d'une autre non réutilisable et simultanément - violation des principes de base de la culture de l'OOD: Accès gratuit aux membres de la maîtrise. Du point de vue de la culture de la programmation - inverse à 70 ème années du siècle dernier.
Programmation fonctionnelle? -Je voise, mais pourquoi mélanger est les phénomènes de l'OOP que Java est. Ood a un magnifique motif nommé découplage de comportement de données qui fournit élégamment les mêmes possibilités? L'argument - c'est la même chose comme dans Java Script ... Nu, vraiment! Donnez des outils pour intégrer le script Java en Java et écrire des morceaux de système dans le script Java. Donc, je ne vois toujours pas vraiment tellement de vrais avantages, car il y a une vague de publicité.


0 commentaires