Comment s'appelle ce concept sur Java - lié à la parallelisation

Bonsoir,

En Java je sais qu'il est possible de demander au compilateur d’exécuter 2 opérations de calcul mathématique simultanément.

Résultat dans la console du compilateur parfois le résultat 1 sort avant le 2 , parfois c'est l'inverse .

Il y a une notion de parallélisation et une seconde notion dont j'ai oublié le nom.

En mode parallèle , il y a un calcul "langage" VS un calcul "machine" . En somme Java et / ou la JVM arrive à prendre en charge le calcul a la place du PC ...

Pas moyen de mettre un nom dessus. Et vous est ce que cela vous parle ? Je demande car je n'arrive plus à mettre la main sur la doc qui en parle.

Merci de l'aiguillage ;)

Dites moi si c'est pas clair je peux essayer d'apporter des exemples de " cas "

Salut,

J'ai l'impression que tu veux parler de thread mais pas avec les bons termes.

Par exemple "En somme Java et / ou la JVM arrive à prendre en charge le calcul a la place du PC" n'a pas vraiment de sens : le code de la JVM est exécuté par le PC, comme tout programme d'ailleurs, ou plus précisément au final par le microprocesseur, en résumé (il y a d'autres composants qui peuvent être utilisés pour des fonctions particulières, par exemple des GPU pour du graphique par exemple).

Et le compilateur sert à compiler, soit transformer du code source en bytecode, pas vraiment à faire des calculs, bien que le processus de compilation comprend sûrement un certain nombre de calculs entre autres. Que le compilateur parallélise ou pas ne concerne pas les développeurs, en dehors d'une saine curiosité technique : c'est sa cuisine interne et ce qui compte c'est d'obtenir les .class qui correspondent au .java.

Les threads peuvent être en effet simulés par la JVM, soit natifs (traités par le système d'exploitation, qui délègue éventuellement aux microprocesseurs)

Bonjour,

C'est bien cela , c'est bien le thread en effet.

Merci de votre aide

Je rejoins ce que Joel t'as très bien expliqué. (comme d'habitude ;)

Mais quand tu dis

Citation:

---

Résultat dans la console du compilateur parfois le résultat 1 sort avant le 2 , parfois c'est l'inverse .

---

Il peut y avoir plusieurs raisons à cela.

Mais dans mes vagues souvenirs (cours de C sous unix des années 2000), si tu as plusieurs threads qui écrivent sur la sortie standard (stdout ou System.out si tu préfères) tu n'as aucunes garantie de l'ordre d'affichage. (en imaginant que l'execution se fait toujours de la même manière)

Que si tu écrits sur la sortie erreur tu auras plus de garantie.

Joel, qu'en penses tu ? (j'aimerais être sur de ma mémoire car je ne trouve pas de réference sur le net, et ressortir mes cours des années 2000 n'est plus possible).

Citation:

---

Envoyé par wax78

Joel, qu'en penses tu ?

---

Je ne suis pas un expert du domaine, loin de là, mais à ce que je sache oui rien n'est vraiment garanti sur l'ordre. L’ordonnanceur, lorsqu'il est logique, donne un peu de temps à chaque process, selon différentes circonstances. On peut paramétrer la priorité, et j'imagine que quand l’ordonnanceur à un choix à faire il l'utilise ça pour savoir quel thread privilégier, mais pour le reste, je n'y connais pas grand chose. La garanti est faible d'autant plus que même deux threads faisant exactement la même chose au sens algorithmique ne s'exécuteront pas forcément exactement de la même manière (sauf peut-être sur un vrai système temps réel et encore) . Il y a tellement de petits phénomènes qui peuvent légèrement faire varier l'exécution : disponibilité des ressources physiques et logiques, réveil de tâches de fond, impacts de calculs (un simple parcourt de chaînes de taille différente, une décompression d'images différentes, un décryptage de clef différente, un parcourt de compositions de tailles différentes... Donc dans l'absolu, un process commencé après un autre peut afficher son résultat avant que l'autre ait affiché son résultat suivant.
Pour le System.out, à priori on a un buffer en mode producteur/consommateur : les producteurs se mettent en attente de pouvoir balancer leur flux dans le buffer (ça a l'air mais ce n'est pas sale) ;) le consommateur réveille tout le monde, ils se ruent tous la-dessus comme des affamés, y'en un qui est élu, lequel et pourquoi, no lo sé, et les autres retournent se pieuter jusqu'à la prochaine.

Je suis d'accord avec ce que tu dis.

Il va falloir que je regarde si je retrouve cette histoire dans mes vieux livre de cours car ça me perturbe d'avoir quelque chose ainsi en tête et de ne plus savoir la raison :)

edit : Peut être que comme tu dis, stdout est bufferisé, mais pas stderr (ou quelque chose dans le gout)