ExecutorService: le seuil de rentabilité surprenant des performances - règles empiriques?

1. À l'aide de exécuteurs est au sujet en utilisant les Processeurs et /ou de cœurs du PROCESSEUR, donc, si vous créez un pool de thread qui utilise la quantité de Cpu au mieux, vous devez avoir autant de threads que les Processeurs /cœurs.
2. Vous avez raison, la création de nouveaux objets de coûts trop. Donc une façon de réduire les dépenses est de l'utilisation des lots. Si vous connaissez le type et la quantité de calculs à faire, vous créez des lots. Alors, pensez-mille(s) calculs effectués dans une tâche exécutée. Vous créer des lots pour chaque thread. Dès que le calcul est fait en java.util.de façon concomitante.L'avenir), vous créez la prochaine fournée. Même la création de nouveaux lots peut être fait en parallèle (4 CPUs -> 3 threads de calcul, 1 fil pour le lot de provisionnement). En fin de compte, vous pouvez vous retrouver avec plus de débit, mais avec une augmentation de la demande en mémoire (lots, mise en service).

Edit: j'ai changé ton exemple et je laisse courir mon petit dual-core x200 ordinateur portable.

provisioned 2 batches to be executed
simpleCompuation:14
computationWithObjCreation:17
computationWithObjCreationAndExecutors:9

Comme vous le voyez dans le code source, j'ai pris le lot de provisionnement et exécuteur testamentaire du cycle de vie de la mesure, trop. C'est plus juste par rapport aux deux autres méthodes.

Voir les résultats par vous-même...

import java.util.List;
import java.util.Vector;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;
public class ExecServicePerformance {
private static int count = 100000;
public static void main( String[] args ) throws InterruptedException {
final int cpus = Runtime.getRuntime().availableProcessors();
final ExecutorService es = Executors.newFixedThreadPool( cpus );
final Vector< Batch > batches = new Vector< Batch >( cpus );
final int batchComputations = count / cpus;
for ( int i = 0; i < cpus; i++ ) {
batches.add( new Batch( batchComputations ) );
}
System.out.println( "provisioned " + cpus + " batches to be executed" );
//warmup
simpleCompuation();
computationWithObjCreation();
computationWithObjCreationAndExecutors( es, batches );
long start = System.currentTimeMillis();
simpleCompuation();
long stop = System.currentTimeMillis();
System.out.println( "simpleCompuation:" + ( stop - start ) );
start = System.currentTimeMillis();
computationWithObjCreation();
stop = System.currentTimeMillis();
System.out.println( "computationWithObjCreation:" + ( stop - start ) );
//Executor
start = System.currentTimeMillis();
computationWithObjCreationAndExecutors( es, batches );    
es.shutdown();
es.awaitTermination( 10, TimeUnit.SECONDS );
//Note: Executor#shutdown() and Executor#awaitTermination() requires
//some extra time. But the result should still be clear.
stop = System.currentTimeMillis();
System.out.println( "computationWithObjCreationAndExecutors:"
+ ( stop - start ) );
}
private static void computationWithObjCreation() {
for ( int i = 0; i < count; i++ ) {
new Runnable() {
@Override
public void run() {
double x = Math.random() * Math.random();
}
}.run();
}
}
private static void simpleCompuation() {
for ( int i = 0; i < count; i++ ) {
double x = Math.random() * Math.random();
}
}
private static void computationWithObjCreationAndExecutors(
ExecutorService es, List< Batch > batches )
throws InterruptedException {
for ( Batch batch : batches ) {
es.submit( batch );
}
}
private static class Batch implements Runnable {
private final int computations;
public Batch( final int computations ) {
this.computations = computations;
}
@Override
public void run() {
int countdown = computations;
while ( countdown-- > -1 ) {
double x = Math.random() * Math.random();
}
}
}
}

Je ne pense pas que cela soit réaliste puisque vous êtes en train de créer un nouvel exécuteur testamentaire de service chaque fois que vous faites l'appel de la méthode. Sauf si vous avez très étrange exigences qui semble irréaliste - en général, vous devez créer le service lorsque votre application démarre, puis de soumettre des travaux.

Si vous essayez de l'analyse comparative de nouveau, mais initialiser le service comme un champune fois, à l'extérieur de la boucle de chronométrage; alors vous verrez les frais généraux réels de la soumission Runnables pour le service par rapport à l'exécution par vous-même.

Mais je ne pense pas que vous aurez compris le point entièrement Exécuteurs testamentaires ne sont pas censés être là pour l'efficacité, ils sont là pour faire de la coordination et de la remise en arrêt de travail pour un pool de threads plus simple. Ils seront toujours moins efficace que de simplement en invoquant Runnable.run() vous-même (car, à la fin de la journée, l'exécuteur testamentaire de service a encore besoin pour ce faire, après avoir fait quelques un service de ménage supplémentaire à l'avance). C'est quand vous les utilisez à partir de plusieurs threads ayant besoin d'un traitement asynchrone, qu'ils brillent vraiment.

Également considérer que vous êtes à la recherche relative de la différence de temps de essentiellement des coûts fixes (Exécuteur testamentaire de frais généraux est le même, que vos tâches prendre 1ms ou 1hr) par rapport à une très petite quantité variable (de votre trivial exécutables). Si l'exécuteur testamentaire prend 5ms supplémentaire pour exécuter un 1ms tâche, qui n'est pas très favorable de la figure. Si elle prend 5ms supplémentaire pour exécuter un 5 seconde tâche (p. ex. non-trivial de requête SQL), c'est tout à fait négligeable et entièrement en vaut la peine.

Donc, dans une certaine mesure, cela dépend de votre situation - si vous avez une très-section critique, l'exécution de beaucoup de petites tâches, que vous n'avez pas besoin d'être exécutées en parallèle ou de manière asynchrone ensuite, vous aurez rien d'un Exécuteur testamentaire. Si vous êtes de traitement plus lourd des tâches en parallèle et que vous voulez répondre de manière asynchrone (par exemple, une webapp) puis Exécuteurs sont grands.

Qu'ils sont le meilleur choix pour vous, dépend de votre situation, mais vraiment, vous devez essayer les tests avec des données représentatives. Je ne pense pas qu'il serait prématuré d'en tirer des conclusions à partir des tests que vous avez fait, à moins que vos tâches sont vraiment que trivial (et vous ne voulez pas de réutiliser l'exécuteur exemple...).

Voici les résultats sur ma machine (OpenJDK 8 sur 64 bits Ubuntu 14.0, Thinkpad W530)

simpleCompuation:6
computationWithObjCreation:5
computationWithObjCreationAndExecutors:33

Il y a certainement des frais généraux. Mais rappelez-vous ce que ces nombres sont: millisecondes pour 100 itérations. Dans votre cas, la surcharge a été d'environ 4 microsecondes par itération. Pour moi, la surcharge a été d'environ un quart de la microseconde.

La surcharge est de la synchronisation, les structures de données internes, et peut-être un manque de JIT optimisation dus à la complexité des chemins de code (certainement plus complexe que votre boucle for).

Les tâches qui vous fait envie pour paralléliser en vaudrait la peine, malgré le quart de la microseconde frais généraux.

Pour info, ce serait un très mauvais calcul pour paralléliser. J'ai haussé le fil à 8 (le nombre de cœurs):

simpleCompuation:5
computationWithObjCreation:6
computationWithObjCreationAndExecutors:38

Il n'a pas fait les choses plus vite. C'est parce que Math.random() est synchronisé.

Fixe ThreadPool ultime de porpose est de réutiliser déjà créé des threads. Donc, les gains de performance sont vu dans l'absence de la nécessité de recréer un nouveau thread à chaque fois qu'une tâche est soumise. D'où le temps d'arrêt doit être prise à l'intérieur de l'soumis tâche. Seulement dans la dernière déclaration de la méthode run.