Discussion :

[Etudiante_Ines]

bonjour

svp j'ai fait ce code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
for(i=1;i<=3;i++)
			  {
 
 
				  Thread t=new Thread()
 
			  }

Est ce que les 3 thread créé s'exécutent en parallèle ou non dans le boucle For

[maxime8n]

Si tu oublie le start déjà sa peut pas marcher

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Thread t = new Thread();
t.start();

Sinon tu peut essayer

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class MyThread extends Thread{
 
	public static void main (String[] args){
 
		for(int i=0;i<3;i++){
			Thread t = new MyThread();
			t.start();
		}
	}
	@Override
	public void run(){		
		System.out.println(System.currentTimeMillis());
	}
 
}

Tu verra que les trois Threads affiche le même temps en milisecondes

[thelvin]

Si tu oublie le start déjà sa peut pas marcher

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Thread t = new Thread();
t.start();

Certes.

Sinon tu peut essayer

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class MyThread extends Thread{
 
	public static void main (String[] args){
 
		for(int i=0;i<3;i++){
			Thread t = new MyThread();
			t.start();
		}
	}
	@Override
	public void run(){		
		System.out.println(System.currentTimeMillis());
	}
 
}

Tu verra que les trois Threads affiche le même temps en milisecondes

Euh. Et alors ?


Pour répondre à la question : oui, des Threads ça s'exécute en parallèle. C'est à ça que ça sert. On a pas de raison d'aller chercher des Thread, si ce n'est pas pour que ça s'exécute en parallèle.

[maxime8n]

Euh. Et alors ?.

Bah tu vois que les trois threads on démarré en même temps

[thelvin]

Bah tu vois que les trois threads on démarré en même temps

Non. Ils ont démarré l'un après l'autre, mais à très peu de temps d'intervalle.

On ferait trois fois System.out.println(System.currentTimeMillis()); sans aucun thread, ça ferait pareil.
En principe ils sont séparés par un peu plus de temps, parce que là on se tape des IO bloquantes en séquence, alors que les threads, justement, passent la main à d'autres threads quand ils tombent sur une IO bloquante, ce qui fait que les threads ne font qu'appeler trois fois System.currentTimeMillis() et ensuite seulement affichent leurs résultats.
Ça augmente les chances d'avoir peu de temps de différence, mais ça ne garantit pas d'en avoir moins qu'avec une approche en séquence.

[Etudiante_Ines]

merci beaucoup

donc lorsque je mets beaucoup de Thread: plus que 20 Thread dans un boucle FOR il n'est pas garantit d'optimiser le temps d’exécution ( c'est mon but )

[thelvin]

donc lorsque je mets beaucoup de Thread: plus que 20 Thread dans un boucle FOR il n'est pas garantit d'optimiser le temps d’exécution ( c'est mon but )

Bien sûr que non.

- D'abord parce que dans tes exemples les threads font des trucs très courts, et que juste créer les threads, les démarrer et attendre qu'ils aient fini, est plus long que le travail lui-même.

- Ensuite parce que tu n'as certainement pas 20 cœurs de processeur pour paralléliser tout ça, et que les threads ne passent pas forcément leur temps dans des IO bloquantes.

=> Si les threads amélioraient toujours les performances, on aurait pas besoin de les programmer. Java ferait des threads partout sans qu'on lui demande, afin d'avoir les meilleures performances.

[JoeChip]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
		for(int i=0;i<3;i++){
			Thread t = new MyThread();
			t.start();
		}

Je ne comprend pas l'utilité de t :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
		for(int i=0;i<3;i++)
			new MyThread().start();

est plus simple et plus efficace.

[Etudiante_Ines]

donc c'est quoi la solution ??? je veux optimiser le temps d’exécution du code sachant que j'ai plus que 20 règles indépendantes et je veux qu'ils s’exécutent en parallèle

[thelvin]

donc c'est quoi la solution ???

Qu'est-ce qui te fait penser qu'il y en a une ? De toute façon, que ça soit le cas ou non, on va pas deviner...

je veux optimiser le temps d’exécution du code sachant que j'ai plus que 20 règles indépendantes

C'est assez vague, quand même.

et je veux qu'ils s’exécutent en parallèle

Peut-être pas toutes en parallèles ? Un truc comme par exemple 3 threads qui se partagent les 20 travaux à faire ?
S'il n'y a pas d'IO, et si le traitement n'est pas complètement immédiat, on aime bien N threads ou N+1 threads, avec N le nombre de cœurs disponibles. Comme on ne sait pas à l'avance le nombre de cœurs disponibles, on pourrait par exemple se caler sur 5 threads.

Mais si le traitement est immédiat et qu'il n'y a pas d'IO, les faire en parallèle, ça n'optimise rien du tout, bien au contraire.

[hwoarang]

je veux optimiser le temps d’exécution du code sachant que j'ai plus que 20 règles indépendantes et je veux qu'ils s’exécutent en parallèle

Il ne faut pas oublier que lorsqu'on utilise des threads, la JVM est obligée de gérer leur ordonnancement. Donc ce n'est pas toujours interessant d'en utiliser. Dans ton cas, qu'est ce qui te fait penser qu'utiliser des threads ameliorerait les performances ?
Elles font quoi ces regles ?

[Etudiante_Ines]

se sont des règles SWRL ( je suis débutante dans le domaine des webs semantiques, ontologie, regles swrl ) mais maintenant je fais la tache : optimiser le temps de matching entre ces règles sachant qu'il y a plus que 20 règles indépendantes

[thelvin]

Oui mais, on va pas faire ton boulot, et en ce qui me concerne je ne sais pas ce que c'est, du matching de règles SWRL. Et ça ne m'intéresse pas de le savoir non plus, c'est ton travail.

Puisque quelqu'un te demande de l'optimiser, et qu'elles sont indépendantes, alors on peut supposer que le calcul n'est pas immédiat, qu'il est parallélisable, et que c'est intéressant de le paralléliser.

S'il n'y a pas d'IO en jeu, et on peut supposer qu'il n'y en a pas, l'approche est de créer quelques threads, quelques, un nombre relativement petit, et qu'ils se partagent le travail à faire : chaque thread prend un travail dans la pile de travaux à faire, et le fait. Quand il a terminé, il en prend un autre, et ainsi de suite.
On appelle ça un pool de threads.
L'intérêt est d'en avoir plusieurs pour paralléliser le travail, mais de ne pas en avoir trop. En avoir trop ferait passer plus de temps à gérer les threads qu'à les exécuter.

Le plus simple pour cela est d'utiliser ThreadPoolExecutor.

[tchize_]

Dans l'absolu, si on soupconne que c'est optimisable par multi threading, faire le code de multithreading, puis faire des mesures et regarder.

Si chaque règle prend plusieurs secondes -> oui tu risque d'y gagner
Si chaque règle est rapide mais qu'on fait 50.000 demande de comparaison pas seconde -> non tu va rien y gagner.

[cylere]

donc c'est quoi la solution ??? je veux optimiser le temps d’exécution du code sachant que j'ai plus que 20 règles indépendantes et je veux qu'ils s’exécutent en parallèle

Pourquoi ne pas envisager Observer/Observable, les règles ne seront pas appliquées en parallèles mais simultanément en time sharing, c'est Java qui gère/optimise les threads.
Ce Pattern Observateur est très souple. Il est tout à fait adapté pour l'application de règles indépendantes.
Sinon il faut voir les outils de parallélisation.

[tchize_]

Par défaut ce patter n'a rien de multithreadé. De plus je vois pas le rapport entre une observation de changement d'état (pattern observer) et ce que veux faire la personne ici: un algorithme de validation multi règles.

[cylere]

Pas si simple : dans la documentation Observable.html

La conclusion :
Note that this notification mechanism is has nothing to do with threads and is completely separate from the wait and notify mechanism of class Object.

et un peu avant :
The order in which notifications will be delivered is unspecified. The default implementation provided in the Observable class will notify Observers in the order in which they registered interest,but subclasses may change this order, use no guaranteed order, deliver notifications on separate threads, or may guarantee that their subclass follows this order, as they choose.

L'optimisation les utilise au mieux.

Donc si l'objet est en Observable et que chaque règles a son Observer, cela devrait convenir,
Changer l'objet observé + setChanged() + notifyObservers() lance l'application/l'exécution simultanée des vingt règles sélectionnées

[thelvin]

Oui, c'est possible d'utiliser les Observable en contexte multithreadé, à condition de se taper tout le boulot soi-même, mais en quoi ça aide à faire du multithreadé ?
En quoi le pattern observateur aide-t-il à faire quoi que ce soit dans la question ?

[cylere]

Oui, c'est possible d'utiliser les Observable en contexte multithreadé, à condition de se taper tout le boulot soi-même, mais en quoi ça aide à faire du multithreadé ?
En quoi le pattern observateur aide-t-il à faire quoi que ce soit dans la question ?

C'est à Etudiante_Ines de voir selon son problème réel :
le Pattern Observateur répond-il au besoin ou non ? (Si Java n'a pas voulu utiliser des threads 'visibles' et laisse le compilateur générer et gérer ceux qui sont nécessaires, ce n'est sûrement pas gratuit)

Sinon qu'elle précise sa demande

[thelvin]

C'est à Etudiante_Ines de voir selon son problème réel :
le Pattern Observateur répond-il au besoin ou non ?

... Je reconnais que c'est pas totalement impossible, mais il me semble qu'il y aurait eu, je sais pas, n'importe quoi d'autre de plus pertinent, à aborder d'abord, non ?

(Si Java n'a pas voulu utiliser des threads 'visibles' et laisse le compilateur générer et gérer ceux qui sont nécessaires,[...])

... Ok, j'ai aucune idée de ce que tu as en tête.