Dois-je toujours utiliser un flux parallèle lorsque cela est possible?

Avec Java 8 et lambdas, il est facile d'itérer les collections en tant que flux et tout aussi facile d'utiliser un flux parallèle. Deux exemples tirés de la documentation , le second utilisant parallelStream:

myShapesCollection.stream()
    .filter(e -> e.getColor() == Color.RED)
    .forEach(e -> System.out.println(e.getName()));

myShapesCollection.parallelStream() // <-- This one uses parallel
    .filter(e -> e.getColor() == Color.RED)
    .forEach(e -> System.out.println(e.getName()));

Tant que je ne me soucie pas de la commande, serait-il toujours avantageux d'utiliser le parallèle? On pourrait penser qu'il est plus rapide de diviser le travail sur plus de cœurs.

Y a-t-il d'autres considérations? Quand utiliser le flux parallèle et quand utiliser le non parallèle?

^{(Cette question est posée pour déclencher une discussion sur comment et quand utiliser des flux parallèles, pas parce que je pense que toujours les utiliser est une bonne idée.)}

Un flux parallèle a une surcharge beaucoup plus élevée par rapport à un flux séquentiel. La coordination des fils prend beaucoup de temps. J'utiliserais des flux séquentiels par défaut et ne considérerais que les flux parallèles si

• J'ai une quantité énorme d'articles à traiter (ou le traitement de chaque article prend du temps et est parallélisable)

• J'ai un problème de performance en premier lieu

• Je n'exécute pas déjà le processus dans un environnement multi-thread (par exemple: dans un conteneur Web, si j'ai déjà plusieurs demandes à traiter en parallèle, l'ajout d'une couche supplémentaire de parallélisme à l'intérieur de chaque demande pourrait avoir des effets plus négatifs que positifs. )

Dans votre exemple, les performances seront de toute façon déterminées par l'accès synchronisé à System.out.println(), et rendre ce processus parallèle n'aura aucun effet, ni même un effet négatif.

De plus, n'oubliez pas que les flux parallèles ne résolvent pas comme par magie tous les problèmes de synchronisation. Si une ressource partagée est utilisée par les prédicats et les fonctions utilisés dans le processus, vous devrez vous assurer que tout est thread-safe. En particulier, les effets secondaires sont des choses dont vous devez vraiment vous inquiéter si vous opérez en parallèle.

En tout cas, mesurez, ne devinez pas! Seule une mesure vous dira si le parallélisme en vaut la peine ou non.

L'API Stream a été conçue pour faciliter l'écriture de calculs d'une manière qui soit abstraite de la façon dont ils seraient exécutés, facilitant ainsi le passage du séquentiel au parallèle.

Cependant, ce n'est pas parce que c'est facile, c'est toujours une bonne idée, et en fait, c'est une mauvaise idée de simplement laisser tomber .parallel()partout simplement parce que vous le pouvez.

Tout d'abord, notez que le parallélisme n'offre aucun avantage autre que la possibilité d'une exécution plus rapide lorsque davantage de cœurs sont disponibles. Une exécution parallèle impliquera toujours plus de travail qu'une exécution séquentielle, car en plus de résoudre le problème, elle doit également effectuer la répartition et la coordination des sous-tâches. L'espoir est que vous serez en mesure d'obtenir la réponse plus rapidement en répartissant le travail sur plusieurs processeurs; si cela se produit réellement dépend de beaucoup de choses, y compris la taille de votre ensemble de données, la quantité de calcul que vous faites sur chaque élément, la nature du calcul (en particulier, le traitement d'un élément interagit-il avec le traitement des autres?) , le nombre de processeurs disponibles et le nombre d'autres tâches en concurrence pour ces processeurs.

De plus, notez que le parallélisme expose également souvent le non-déterminisme dans le calcul qui est souvent caché par les implémentations séquentielles; parfois cela n'a pas d'importance ou peut être atténué en contraignant les opérations impliquées (c'est-à-dire que les opérateurs de réduction doivent être sans état et associatifs).

En réalité, parfois le parallélisme accélérera votre calcul, parfois non, et parfois même le ralentira. Il est préférable de développer d'abord en utilisant l'exécution séquentielle, puis d'appliquer le parallélisme là où

(A) vous savez qu'il y a effectivement un avantage à augmenter les performances et

(B) qu'il fournira réellement des performances accrues.

(A) est un problème commercial et non technique. Si vous êtes un expert en performances, vous pourrez généralement consulter le code et déterminer (B), mais le chemin intelligent est de mesurer. (Et, ne vous embêtez pas jusqu'à ce que vous soyez convaincu de (A); si le code est assez rapide, mieux vaut appliquer vos cycles cérébraux ailleurs.)

Le modèle de performance le plus simple pour le parallélisme est le modèle "NQ", où N est le nombre d'éléments et Q est le calcul par élément. En général, vous devez que le produit NQ dépasse un certain seuil avant de commencer à obtenir un avantage en termes de performances. Pour un problème à faible Q comme «additionner des nombres de 1 à N», vous verrez généralement un seuil de rentabilité entre N = 1000 et N = 10000. Avec des problèmes à Q plus élevé, vous verrez des points morts à des seuils inférieurs.

Mais la réalité est assez compliquée. Donc, jusqu'à ce que vous atteigniez l'expertise, identifiez d'abord quand le traitement séquentiel vous coûte réellement quelque chose, puis mesurez si le parallélisme vous aidera.

J'ai regardé l'une des présentations de Brian Goetz (Java Language Architect et responsable des spécifications pour Lambda Expressions) . Il explique en détail les 4 points suivants à considérer avant de passer à la parallélisation:

Coûts de fractionnement / décomposition
- Parfois, le fractionnement est plus cher que de simplement faire le travail!
Coûts de répartition / gestion des tâches
- Peut faire beaucoup de travail dans le temps qu'il faut pour remettre le travail à un autre thread.
Coûts de combinaison des résultats
- Parfois, la combinaison implique la copie de nombreuses données. Par exemple, l'ajout de numéros est bon marché tandis que la fusion d'ensembles coûte cher.
Localité
- L'éléphant dans la pièce. C'est un point important que tout le monde peut manquer. Vous devriez considérer les échecs de cache, si un CPU attend des données à cause des échecs de cache, alors vous ne gagneriez rien à la parallélisation. C'est pourquoi les sources basées sur des tableaux se parallélisent le mieux car les prochains index (proches de l'index actuel) sont mis en cache et il y a moins de chances que le CPU subisse un échec de cache.

Il mentionne également une formule relativement simple pour déterminer une chance d'accélération parallèle.

Modèle NQ :

N x Q > 10000

où,
N = nombre d'éléments de données
Q = quantité de travail par élément

JB a frappé le clou sur la tête. La seule chose que je peux ajouter, c'est que Java 8 ne fait pas de traitement parallèle pur, il fait du paraquentiel . Oui, j'ai écrit l'article et je fais du F / J depuis trente ans, donc je comprends le problème.

D'autres réponses ont déjà couvert le profilage pour éviter une optimisation prématurée et des frais généraux dans le traitement parallèle. Cette réponse explique le choix idéal des structures de données pour le streaming parallèle.

En règle générale, les gains de performance du parallélisme sont les meilleurs sur les flux sur ArrayList, HashMap, HashSetet des ConcurrentHashMapcas; tableaux; intgammes; et longplages. Ce que ces structures de données ont en commun, c'est qu'elles peuvent toutes être divisées avec précision et à moindre coût en sous-gammes de toutes les tailles souhaitées, ce qui facilite la répartition du travail entre les threads parallèles. L'abstraction utilisée par la bibliothèque de flux pour effectuer cette tâche est le séparateur, qui est renvoyé par la spliteratorméthode sur Streamet Iterable.

Un autre facteur important que toutes ces structures de données ont en commun est qu'elles fournissent une localité de référence bonne à excellente lorsqu'elles sont traitées séquentiellement: les références d'éléments séquentielles sont stockées ensemble en mémoire. Les objets référencés par ces références peuvent ne pas être proches les uns des autres en mémoire, ce qui réduit la localité de référence. La localité de référence s'avère extrêmement importante pour la parallélisation des opérations en masse: sans elle, les threads passent une grande partie de leur temps inactif, en attendant que les données soient transférées de la mémoire dans le cache du processeur. Les structures de données avec la meilleure localité de référence sont des tableaux primitifs car les données elles-mêmes sont stockées de manière contiguë en mémoire.

Source: article n ° 48 Soyez prudent lorsque vous créez des flux parallèles, efficace Java 3e par Joshua Bloch

Ne parallélisez jamais un flux infini avec une limite. Voici ce qui se passe:

    public static void main(String[] args) {
        // let's count to 1 in parallel
        System.out.println(
            IntStream.iterate(0, i -> i + 1)
                .parallel()
                .skip(1)
                .findFirst()
                .getAsInt());
    }

Résultat

    Exception in thread "main" java.lang.OutOfMemoryError
        at ...
        at java.base/java.util.stream.IntPipeline.findFirst(IntPipeline.java:528)
        at InfiniteTest.main(InfiniteTest.java:24)
    Caused by: java.lang.OutOfMemoryError: Java heap space
        at java.base/java.util.stream.SpinedBuffer$OfInt.newArray(SpinedBuffer.java:750)
        at ...

Même si vous utilisez .limit(...)

Explication ici: Java 8, l'utilisation de .parallel dans un flux provoque une erreur OOM

De même, n'utilisez pas parallèle si le flux est ordonné et contient beaucoup plus d'éléments que vous souhaitez traiter, par exemple

public static void main(String[] args) {
    // let's count to 1 in parallel
    System.out.println(
            IntStream.range(1, 1000_000_000)
                    .parallel()
                    .skip(100)
                    .findFirst()
                    .getAsInt());
}

Cela peut s'exécuter beaucoup plus longtemps car les threads parallèles peuvent fonctionner sur de nombreuses plages de numéros au lieu de la plage cruciale 0-100, ce qui peut prendre très longtemps.