Répartir l'exécution d'un programme sur plusieurs processeurs
17 réponses
Hugolino
Yo!!
Je ne sais pas pourquoi, mais j'ai installé pi (apt-get install pi) qui
calcule la valeur de π avec n chiffres significatifs en saisissant
simplement 'pi n' (la valeur limite de n dépend de la quantité de
mémoire disponible).
A l'occasion de ce calcul, je me suis aperçu qu'il n'y avait qu'un seul
processeur (sur les 4 de mon i5) qui était sollicité.
J'ai récupéré les 100 000 001 caractères de cette commande dans
libreoffice writer qui lui aussi ne sollicite qu'un seul processeur
pendant la repagination du fichier texte ouvert (jusqu'au crash par
dépassement de la température maximale).
J'ai parcouru la page de man de 'tasksel' sans y comprendre grand
chose...
J'ai peu d'espoir mais peut-être y aurait-il ici un Master of the Geeks
qui m'expliquerait comment répartir la charge processeur sur les 4
(pseudo ?)-processeurs dont dispose ma linuxette.
Merci de m'avoir lu.
--
> Tu oublies que les années passées à l'Est comptent double, sinon plus,
> jeune blanc-bec.
Tu as négligé le vortex spatio-temporel d'improbabilité autour du vexin qui
sur-courbe le scalaire gravitationnel et donc emprisonne le temps.
J'ai peu d'espoir mais peut-être y aurait-il ici un Master of the Geeks qui m'expliquerait comment répartir la charge processeur sur les 4 (pseudo ?)-processeurs dont dispose ma linuxette. Merci de m'avoir lu.
Malheureusement, si le programme n'a pas été conçu et compilé pour, il n'y a rien à faire. Tu peux au mieux affecter un processus à un coeur, mais le noyau sait déjà s'occuper tout seul de répartir les processus...
Le 16/07/2018 à 21:32, Hugolino a écrit :
J'ai peu d'espoir mais peut-être y aurait-il ici un Master of the Geeks
qui m'expliquerait comment répartir la charge processeur sur les 4
(pseudo ?)-processeurs dont dispose ma linuxette.
Merci de m'avoir lu.
Malheureusement, si le programme n'a pas été conçu et compilé pour, il
n'y a rien à faire.
Tu peux au mieux affecter un processus à un coeur, mais le noyau sait
déjà s'occuper tout seul de répartir les processus...
J'ai peu d'espoir mais peut-être y aurait-il ici un Master of the Geeks qui m'expliquerait comment répartir la charge processeur sur les 4 (pseudo ?)-processeurs dont dispose ma linuxette. Merci de m'avoir lu.
Malheureusement, si le programme n'a pas été conçu et compilé pour, il n'y a rien à faire. Tu peux au mieux affecter un processus à un coeur, mais le noyau sait déjà s'occuper tout seul de répartir les processus...
Hugolino
Le 16-07-2018, Th.A.C a écrit :
Le 16/07/2018 à 21:32, Hugolino a écrit :
J'ai peu d'espoir mais peut-être y aurait-il ici un Master of the Geeks qui m'expliquerait comment répartir la charge processeur sur les 4 (pseudo ?)-processeurs dont dispose ma linuxette. Merci de m'avoir lu.
Malheureusement, si le programme n'a pas été conçu et compilé pour, il n'y a rien à faire.
C'est bien ce que je craignais... Tu me diras : je peux toujours récupérer les sources, potasser le code et recompiler... Mais je suis loin d'avoir les compétences nécessaires.
Tu peux au mieux affecter un processus à un coeur, mais le noyau sait déjà s'occuper tout seul de répartir les processus...
Oui, ça je savais. -- <rominet> Entendu chez HSC : il y a tellment de ports ouverts sur le firewall que netstat -an fait coredump Hugo (né il y a 1 711 225 176 secondes)
Le 16-07-2018, Th.A.C <aenleverraivac@free.fr.invalid> a écrit :
Le 16/07/2018 à 21:32, Hugolino a écrit :
J'ai peu d'espoir mais peut-être y aurait-il ici un Master of the
Geeks qui m'expliquerait comment répartir la charge processeur sur
les 4 (pseudo ?)-processeurs dont dispose ma linuxette.
Merci de m'avoir lu.
Malheureusement, si le programme n'a pas été conçu et compilé pour,
il n'y a rien à faire.
C'est bien ce que je craignais...
Tu me diras : je peux toujours récupérer les sources, potasser le code
et recompiler... Mais je suis loin d'avoir les compétences nécessaires.
Tu peux au mieux affecter un processus à un coeur, mais le noyau sait
déjà s'occuper tout seul de répartir les processus...
Oui, ça je savais.
--
<rominet> Entendu chez HSC : il y a tellment de ports ouverts sur le
firewall que netstat -an fait coredump
Hugo (né il y a 1 711 225 176 secondes)
J'ai peu d'espoir mais peut-être y aurait-il ici un Master of the Geeks qui m'expliquerait comment répartir la charge processeur sur les 4 (pseudo ?)-processeurs dont dispose ma linuxette. Merci de m'avoir lu.
Malheureusement, si le programme n'a pas été conçu et compilé pour, il n'y a rien à faire.
C'est bien ce que je craignais... Tu me diras : je peux toujours récupérer les sources, potasser le code et recompiler... Mais je suis loin d'avoir les compétences nécessaires.
Tu peux au mieux affecter un processus à un coeur, mais le noyau sait déjà s'occuper tout seul de répartir les processus...
Oui, ça je savais. -- <rominet> Entendu chez HSC : il y a tellment de ports ouverts sur le firewall que netstat -an fait coredump Hugo (né il y a 1 711 225 176 secondes)
Lucas Levrel
Le 17 juillet 2018, à 00:12, Hugolino a écrit :
Le 16-07-2018, Th.A.C a écrit :
Le 16/07/2018 à 21:32, Hugolino a écrit :
J'ai peu d'espoir mais peut-être y aurait-il ici un Master of the Geeks qui m'expliquerait comment répartir la charge processeur sur les 4 (pseudo ?)-processeurs dont dispose ma linuxette. Merci de m'avoir lu.
Malheureusement, si le programme n'a pas été conçu et compilé pour, il n'y a rien à faire.
C'est bien ce que je craignais... Tu me diras : je peux toujours récupérer les sources, potasser le code et recompiler...
Ben non, toute tâche n'est pas forcément parallélisable. Pour illustrer le problème : je suppose p. ex. que calculer la n-ième décimale de π nécessite d'avoir fait la (n-1)-ième avant, donc si tu répartis le calcul des différentes décimales sur les cœurs, il vont chacun leur tour attendre que le cœur précédent ait fini... -- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Le 17 juillet 2018, à 00:12, Hugolino a écrit :
Le 16-07-2018, Th.A.C <aenleverraivac@free.fr.invalid> a écrit :
Le 16/07/2018 à 21:32, Hugolino a écrit :
J'ai peu d'espoir mais peut-être y aurait-il ici un Master of the
Geeks qui m'expliquerait comment répartir la charge processeur sur
les 4 (pseudo ?)-processeurs dont dispose ma linuxette.
Merci de m'avoir lu.
Malheureusement, si le programme n'a pas été conçu et compilé pour,
il n'y a rien à faire.
C'est bien ce que je craignais...
Tu me diras : je peux toujours récupérer les sources, potasser le code
et recompiler...
Ben non, toute tâche n'est pas forcément parallélisable. Pour illustrer le
problème : je suppose p. ex. que calculer la n-ième décimale de π
nécessite d'avoir fait la (n-1)-ième avant, donc si tu répartis le calcul
des différentes décimales sur les cœurs, il vont chacun leur tour attendre
que le cœur précédent ait fini...
--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
J'ai peu d'espoir mais peut-être y aurait-il ici un Master of the Geeks qui m'expliquerait comment répartir la charge processeur sur les 4 (pseudo ?)-processeurs dont dispose ma linuxette. Merci de m'avoir lu.
Malheureusement, si le programme n'a pas été conçu et compilé pour, il n'y a rien à faire.
C'est bien ce que je craignais... Tu me diras : je peux toujours récupérer les sources, potasser le code et recompiler...
Ben non, toute tâche n'est pas forcément parallélisable. Pour illustrer le problème : je suppose p. ex. que calculer la n-ième décimale de π nécessite d'avoir fait la (n-1)-ième avant, donc si tu répartis le calcul des différentes décimales sur les cœurs, il vont chacun leur tour attendre que le cœur précédent ait fini... -- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Olivier Miakinen
Le 17/07/2018 13:10, Lucas Levrel a écrit :
Tu me diras : je peux toujours récupérer les sources, potasser le code et recompiler...
Ben non, toute tâche n'est pas forcément parallélisable. Pour illustrer le problème : je suppose p. ex. que calculer la n-ième décimale de π nécessite d'avoir fait la (n-1)-ième avant, donc si tu répartis le calcul des différentes décimales sur les cœurs, il vont chacun leur tour attendre que le cœur précédent ait fini...
C'est peut-être impossible en base 10, mais on peut le faire en base 2 ou en base 16 : <https://fr.wikipedia.org/wiki/Formule_BBP>. Du coup, on pourrait avoir trois processeurs qui se chargent de récupérer un chiffre sur trois en base 16, et un processeur qui fait la conversion de la base 16 à la base 10. Reste à savoir si c'est plus efficace qu'une méthode directe. -- Olivier Miakinen
Le 17/07/2018 13:10, Lucas Levrel a écrit :
Tu me diras : je peux toujours récupérer les sources, potasser le code
et recompiler...
Ben non, toute tâche n'est pas forcément parallélisable. Pour illustrer le
problème : je suppose p. ex. que calculer la n-ième décimale de π
nécessite d'avoir fait la (n-1)-ième avant, donc si tu répartis le calcul
des différentes décimales sur les cœurs, il vont chacun leur tour attendre
que le cœur précédent ait fini...
C'est peut-être impossible en base 10, mais on peut le faire en
base 2 ou en base 16 : <https://fr.wikipedia.org/wiki/Formule_BBP>.
Du coup, on pourrait avoir trois processeurs qui se chargent de
récupérer un chiffre sur trois en base 16, et un processeur qui
fait la conversion de la base 16 à la base 10. Reste à savoir si
c'est plus efficace qu'une méthode directe.
Tu me diras : je peux toujours récupérer les sources, potasser le code et recompiler...
Ben non, toute tâche n'est pas forcément parallélisable. Pour illustrer le problème : je suppose p. ex. que calculer la n-ième décimale de π nécessite d'avoir fait la (n-1)-ième avant, donc si tu répartis le calcul des différentes décimales sur les cœurs, il vont chacun leur tour attendre que le cœur précédent ait fini...
C'est peut-être impossible en base 10, mais on peut le faire en base 2 ou en base 16 : <https://fr.wikipedia.org/wiki/Formule_BBP>. Du coup, on pourrait avoir trois processeurs qui se chargent de récupérer un chiffre sur trois en base 16, et un processeur qui fait la conversion de la base 16 à la base 10. Reste à savoir si c'est plus efficace qu'une méthode directe. -- Olivier Miakinen
jeanm64
Le lundi 16 Juillet 2018 à 21:32 par Hugolino :
Yo!! Je ne sais pas pourquoi, mais j'ai installé pi (apt-get install pi) qui calcule la valeur de π avec n chiffres significatifs en saisissant simplement 'pi n' (la valeur limite de n dépend de la quantité de mémoire disponible). A l'occasion de ce calcul, je me suis aperçu qu'il n'y avait qu'un seul processeur (sur les 4 de mon i5) qui était sollicité. J'ai récupéré les 100 000 001 caractères de cette commande dans libreoffice writer qui lui aussi ne sollicite qu'un seul processeur pendant la repagination du fichier texte ouvert (jusqu'au crash par dépassement de la température maximale). J'ai parcouru la page de man de 'tasksel' sans y comprendre grand chose... J'ai peu d'espoir mais peut-être y aurait-il ici un Master of the Geeks qui m'expliquerait comment répartir la charge processeur sur les 4 (pseudo ?)-processeurs dont dispose ma linuxette. Merci de m'avoir lu. -- > Tu oublies que les années passées à l'Est comptent double, sinon plus, > jeune blanc-bec. Tu as négligé le vortex spatio-temporel d'improbabilité autour du vexin qui sur-courbe le scalaire gravitationnel et donc emprisonne le temps.
Je pense que c'est le scheduler du système d'exploitation qui se charge de répartir les exécutions sur les différents cœurs, un programme lamda ne peux pas s'allouer une "ressource processeur". Il y a peut-être la possibilité de faire associer des cœurs ou processeurs donnés à un niveau de priorité supérieur à XX ? mais dans ce cas je suppose qu'il faut compiler le noyau avec un ou des modules spécifiques... Peut-être avec un VMWare ou autre ... réservation de proc à telle ou telle Machine virtuelle ????
Le lundi 16 Juillet 2018 à 21:32 par Hugolino :
> Yo!!
>
> Je ne sais pas pourquoi, mais j'ai installé pi (apt-get install pi) qui
> calcule la valeur de π avec n chiffres significatifs en saisissant
> simplement 'pi n' (la valeur limite de n dépend de la quantité
> de
> mémoire disponible).
>
> A l'occasion de ce calcul, je me suis aperçu qu'il n'y avait qu'un seul
> processeur (sur les 4 de mon i5) qui était sollicité.
> J'ai récupéré les 100 000 001 caractères de cette
> commande dans
> libreoffice writer qui lui aussi ne sollicite qu'un seul processeur
> pendant la repagination du fichier texte ouvert (jusqu'au crash par
> dépassement de la température maximale).
>
> J'ai parcouru la page de man de 'tasksel' sans y comprendre grand
> chose...
>
> J'ai peu d'espoir mais peut-être y aurait-il ici un Master of the Geeks
> qui m'expliquerait comment répartir la charge processeur sur les 4
> (pseudo ?)-processeurs dont dispose ma linuxette.
>
> Merci de m'avoir lu.
>
>
> --
> > Tu oublies que les années passées à l'Est comptent
> double, sinon plus,
> > jeune blanc-bec.
> Tu as négligé le vortex spatio-temporel d'improbabilité
> autour du vexin qui
> sur-courbe le scalaire gravitationnel et donc emprisonne le temps.
Je pense que c'est le scheduler du système d'exploitation qui se charge de répartir les exécutions sur les différents cœurs, un programme lamda ne peux pas s'allouer une "ressource processeur".
Il y a peut-être la possibilité de faire associer des cœurs ou processeurs donnés à un niveau de priorité supérieur à XX ? mais dans ce cas je suppose qu'il faut compiler le noyau avec un ou des modules spécifiques...
Peut-être avec un VMWare ou autre ... réservation de proc à telle ou telle Machine virtuelle ????
Yo!! Je ne sais pas pourquoi, mais j'ai installé pi (apt-get install pi) qui calcule la valeur de π avec n chiffres significatifs en saisissant simplement 'pi n' (la valeur limite de n dépend de la quantité de mémoire disponible). A l'occasion de ce calcul, je me suis aperçu qu'il n'y avait qu'un seul processeur (sur les 4 de mon i5) qui était sollicité. J'ai récupéré les 100 000 001 caractères de cette commande dans libreoffice writer qui lui aussi ne sollicite qu'un seul processeur pendant la repagination du fichier texte ouvert (jusqu'au crash par dépassement de la température maximale). J'ai parcouru la page de man de 'tasksel' sans y comprendre grand chose... J'ai peu d'espoir mais peut-être y aurait-il ici un Master of the Geeks qui m'expliquerait comment répartir la charge processeur sur les 4 (pseudo ?)-processeurs dont dispose ma linuxette. Merci de m'avoir lu. -- > Tu oublies que les années passées à l'Est comptent double, sinon plus, > jeune blanc-bec. Tu as négligé le vortex spatio-temporel d'improbabilité autour du vexin qui sur-courbe le scalaire gravitationnel et donc emprisonne le temps.
Je pense que c'est le scheduler du système d'exploitation qui se charge de répartir les exécutions sur les différents cœurs, un programme lamda ne peux pas s'allouer une "ressource processeur". Il y a peut-être la possibilité de faire associer des cœurs ou processeurs donnés à un niveau de priorité supérieur à XX ? mais dans ce cas je suppose qu'il faut compiler le noyau avec un ou des modules spécifiques... Peut-être avec un VMWare ou autre ... réservation de proc à telle ou telle Machine virtuelle ????
zeLittle
Le Tue, 17 Jul 2018 13:10:10 +0200, Lucas Levrel a écrit:
Le 17 juillet 2018, à 00:12, Hugolino a écrit :
Le 16-07-2018, Th.A.C a écrit :
Le 16/07/2018 à 21:32, Hugolino a écrit :
J'ai peu d'espoir mais peut-être y aurait-il ici un Master of the Geeks qui m'expliquerait comment répartir la charge processeur sur les 4 (pseudo ?)-processeurs dont dispose ma linuxette. Merci de m'avoir lu.
Malheureusement, si le programme n'a pas été conçu e t compilé pour, il n'y a rien à faire.
C'est bien ce que je craignais... Tu me diras : je peux toujours récupérer les sources, potas ser le code et recompiler...
Ben non, toute tâche n'est pas forcément parallélisable . Pour illustrer le problème : je suppose p. ex. que calculer la n-ième dé cimale de π nécessite d'avoir fait la (n-1)-ième avant, donc si tu ré partis le calcul des différentes décimales sur les cœurs, il vont chacun leur tour attendre que le cœur précédent ait fini...
Peut être pas totalement, mais comme dans tout programme, il doit b ien y avoir une ou deux boucles (for, while, repeat, etc) dans lesquelles on peut créer à chaque fois un worker-thread utilisant un proc. o u cœur dispo., workers s'attendant tous en fin de leur tâche pour ordonnan cer leur travail en commun, et le présenter aux workers de la boucle su ivante.
Le Tue, 17 Jul 2018 13:10:10 +0200, Lucas Levrel <lucas.levrel@u-pec.fr> a
écrit:
Le 17 juillet 2018, à 00:12, Hugolino a écrit :
Le 16-07-2018, Th.A.C <aenleverraivac@free.fr.invalid> a écrit :
Le 16/07/2018 à 21:32, Hugolino a écrit :
J'ai peu d'espoir mais peut-être y aurait-il ici un Master of the
Geeks qui m'expliquerait comment répartir la charge processeur sur
les 4 (pseudo ?)-processeurs dont dispose ma linuxette.
Merci de m'avoir lu.
Malheureusement, si le programme n'a pas été conçu e t compilé pour,
il n'y a rien à faire.
C'est bien ce que je craignais...
Tu me diras : je peux toujours récupérer les sources, potas ser le code
et recompiler...
Ben non, toute tâche n'est pas forcément parallélisable . Pour illustrer
le problème : je suppose p. ex. que calculer la n-ième dé cimale de π
nécessite d'avoir fait la (n-1)-ième avant, donc si tu ré partis le
calcul des différentes décimales sur les cœurs, il vont chacun leur tour
attendre que le cœur précédent ait fini...
Peut être pas totalement, mais comme dans tout programme, il doit b ien y
avoir une ou deux boucles (for, while, repeat, etc) dans lesquelles on
peut créer à chaque fois un worker-thread utilisant un proc. o u cœur
dispo., workers s'attendant tous en fin de leur tâche pour ordonnan cer
leur travail en commun, et le présenter aux workers de la boucle su ivante.
Le Tue, 17 Jul 2018 13:10:10 +0200, Lucas Levrel a écrit:
Le 17 juillet 2018, à 00:12, Hugolino a écrit :
Le 16-07-2018, Th.A.C a écrit :
Le 16/07/2018 à 21:32, Hugolino a écrit :
J'ai peu d'espoir mais peut-être y aurait-il ici un Master of the Geeks qui m'expliquerait comment répartir la charge processeur sur les 4 (pseudo ?)-processeurs dont dispose ma linuxette. Merci de m'avoir lu.
Malheureusement, si le programme n'a pas été conçu e t compilé pour, il n'y a rien à faire.
C'est bien ce que je craignais... Tu me diras : je peux toujours récupérer les sources, potas ser le code et recompiler...
Ben non, toute tâche n'est pas forcément parallélisable . Pour illustrer le problème : je suppose p. ex. que calculer la n-ième dé cimale de π nécessite d'avoir fait la (n-1)-ième avant, donc si tu ré partis le calcul des différentes décimales sur les cœurs, il vont chacun leur tour attendre que le cœur précédent ait fini...
Peut être pas totalement, mais comme dans tout programme, il doit b ien y avoir une ou deux boucles (for, while, repeat, etc) dans lesquelles on peut créer à chaque fois un worker-thread utilisant un proc. o u cœur dispo., workers s'attendant tous en fin de leur tâche pour ordonnan cer leur travail en commun, et le présenter aux workers de la boucle su ivante.
Lucas Levrel
Le 30 juillet 2018, à 10:25, zeLittle a écrit :
Le Tue, 17 Jul 2018 13:10:10 +0200, Lucas Levrel a écrit:
Ben non, toute tâche n'est pas forcément parallélisable. Pour illustrer le problème : je suppose p. ex. que calculer la n-ième décimale de π nécessite d'avoir fait la (n-1)-ième avant, donc si tu répartis le calcul des différentes décimales sur les cœurs, il vont chacun leur tour attendre que le cœur précédent ait fini...
Peut être pas totalement, mais comme dans tout programme, il doit bien y avoir une ou deux boucles (for, while, repeat, etc) dans lesquelles on peut créer à chaque fois un worker-thread utilisant un proc. ou cœur dispo., workers s'attendant tous en fin de leur tâche pour ordonnancer leur travail en commun, et le présenter aux workers de la boucle suivante.
D'une part, une boucle n'est pas forcément parallélisable selon la méthode que tu décris : il faut que les passes successives soient indépendantes. Typiquement, l'exemple de la repagination donné par le PO doit contenir plus ou moins (en simplifiant) : while(il reste du texte) : remplit une page avec du texte restant ; mais tu ne peux pas remplir la page N tant que tu ne sais pas quel texte il reste après avoir rempli la page N-1. D'autre part, il ne s'agit pas de paralléliser la première boucle venue, mais les portions critiques du code. Et là il faut que le corps de la boucle, si boucle il y a, soit suffisamment conséquent pour amortir le coût de la création des « workers », qui n'est pas du tout anecdotique... -- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
Le 30 juillet 2018, à 10:25, zeLittle a écrit :
Le Tue, 17 Jul 2018 13:10:10 +0200, Lucas Levrel <lucas.levrel@u-pec.fr> a
écrit:
Ben non, toute tâche n'est pas forcément parallélisable. Pour illustrer le
problème : je suppose p. ex. que calculer la n-ième décimale de π nécessite
d'avoir fait la (n-1)-ième avant, donc si tu répartis le calcul des
différentes décimales sur les cœurs, il vont chacun leur tour attendre que
le cœur précédent ait fini...
Peut être pas totalement, mais comme dans tout programme, il doit bien y
avoir une ou deux boucles (for, while, repeat, etc) dans lesquelles on peut
créer à chaque fois un worker-thread utilisant un proc. ou cœur dispo.,
workers s'attendant tous en fin de leur tâche pour ordonnancer leur travail
en commun, et le présenter aux workers de la boucle suivante.
D'une part, une boucle n'est pas forcément parallélisable selon la méthode
que tu décris : il faut que les passes successives soient indépendantes.
Typiquement, l'exemple de la repagination donné par le PO doit contenir
plus ou moins (en simplifiant) :
while(il reste du texte) : remplit une page avec du texte restant ;
mais tu ne peux pas remplir la page N tant que tu ne sais pas quel texte
il reste après avoir rempli la page N-1.
D'autre part, il ne s'agit pas de paralléliser la première boucle venue,
mais les portions critiques du code. Et là il faut que le corps de la
boucle, si boucle il y a, soit suffisamment conséquent pour amortir le
coût de la création des « workers », qui n'est pas du tout anecdotique...
Le Tue, 17 Jul 2018 13:10:10 +0200, Lucas Levrel a écrit:
Ben non, toute tâche n'est pas forcément parallélisable. Pour illustrer le problème : je suppose p. ex. que calculer la n-ième décimale de π nécessite d'avoir fait la (n-1)-ième avant, donc si tu répartis le calcul des différentes décimales sur les cœurs, il vont chacun leur tour attendre que le cœur précédent ait fini...
Peut être pas totalement, mais comme dans tout programme, il doit bien y avoir une ou deux boucles (for, while, repeat, etc) dans lesquelles on peut créer à chaque fois un worker-thread utilisant un proc. ou cœur dispo., workers s'attendant tous en fin de leur tâche pour ordonnancer leur travail en commun, et le présenter aux workers de la boucle suivante.
D'une part, une boucle n'est pas forcément parallélisable selon la méthode que tu décris : il faut que les passes successives soient indépendantes. Typiquement, l'exemple de la repagination donné par le PO doit contenir plus ou moins (en simplifiant) : while(il reste du texte) : remplit une page avec du texte restant ; mais tu ne peux pas remplir la page N tant que tu ne sais pas quel texte il reste après avoir rempli la page N-1. D'autre part, il ne s'agit pas de paralléliser la première boucle venue, mais les portions critiques du code. Et là il faut que le corps de la boucle, si boucle il y a, soit suffisamment conséquent pour amortir le coût de la création des « workers », qui n'est pas du tout anecdotique... -- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
Nicolas George
Lucas Levrel , dans le message , a écrit :
D'une part, une boucle n'est pas forcément parallélisable selon la méthode que tu décris : il faut que les passes successives soient indépendantes.
Tu as parfaitement raison en général.
while(il reste du texte) : remplit une page avec du texte restant ; mais tu ne peux pas remplir la page N tant que tu ne sais pas quel texte il reste après avoir rempli la page N-1.
Note que le problème est même plus compliqué que ça : pour avoir une vraiment bonne pagination, il faut considérer le problème dans sa globalité plutôt qu'utiliser un algorithme glouton comme tu le décris, car couper la page en cours un petit peu plus tôt peut dégrader légèrement son apparence mais permettre d'améliorer plus celle de la page suivante. On utilise pour trouver l'optimal une variante de l'algorithme de Dijkstra. Les traitements de texte WYSIWYG n'ont pas la puissance pour faire ça en temps réel, et donc conduisent à une pagination sous-optimale.
Lucas Levrel , dans le message
<alpine.LSU.2.21.999.1807301210220.2984@coulomb.u-pec.fr>, a écrit :
D'une part, une boucle n'est pas forcément parallélisable selon la méthode
que tu décris : il faut que les passes successives soient indépendantes.
Tu as parfaitement raison en général.
while(il reste du texte) : remplit une page avec du texte restant ;
mais tu ne peux pas remplir la page N tant que tu ne sais pas quel texte
il reste après avoir rempli la page N-1.
Note que le problème est même plus compliqué que ça : pour avoir une
vraiment bonne pagination, il faut considérer le problème dans sa
globalité plutôt qu'utiliser un algorithme glouton comme tu le décris,
car couper la page en cours un petit peu plus tôt peut dégrader
légèrement son apparence mais permettre d'améliorer plus celle de la
page suivante. On utilise pour trouver l'optimal une variante de
l'algorithme de Dijkstra.
Les traitements de texte WYSIWYG n'ont pas la puissance pour faire ça en
temps réel, et donc conduisent à une pagination sous-optimale.
D'une part, une boucle n'est pas forcément parallélisable selon la méthode que tu décris : il faut que les passes successives soient indépendantes.
Tu as parfaitement raison en général.
while(il reste du texte) : remplit une page avec du texte restant ; mais tu ne peux pas remplir la page N tant que tu ne sais pas quel texte il reste après avoir rempli la page N-1.
Note que le problème est même plus compliqué que ça : pour avoir une vraiment bonne pagination, il faut considérer le problème dans sa globalité plutôt qu'utiliser un algorithme glouton comme tu le décris, car couper la page en cours un petit peu plus tôt peut dégrader légèrement son apparence mais permettre d'améliorer plus celle de la page suivante. On utilise pour trouver l'optimal une variante de l'algorithme de Dijkstra. Les traitements de texte WYSIWYG n'ont pas la puissance pour faire ça en temps réel, et donc conduisent à une pagination sous-optimale.
zeLittle
Le Mon, 30 Jul 2018 22:50:54 +0200, zeLittle a écrit:
c'est à dire le comptage d'opérations générée en assembleur et effectuées par le processeur
Pour cela, ce gimmick répété tel un mantra peut aider l'i nformaticien errant: "look the code, Luke!".
Le Mon, 30 Jul 2018 22:50:54 +0200, zeLittle
<noreplay@noreplay.net.invalid> a écrit:
c'est à dire le comptage d'opérations générée en assembleur et
effectuées par le processeur
Pour cela, ce gimmick répété tel un mantra peut aider l'i nformaticien
errant: "look the code, Luke!".
Le Mon, 30 Jul 2018 22:50:54 +0200, zeLittle a écrit:
c'est à dire le comptage d'opérations générée en assembleur et effectuées par le processeur
Pour cela, ce gimmick répété tel un mantra peut aider l'i nformaticien errant: "look the code, Luke!".
Doug713705
Le 2018-07-30, zeLittle nous expliquait dans fr.comp.os.linux.configuration () :
Le Mon, 30 Jul 2018 22:50:54 +0200, zeLittle a écrit:
c'est à dire le comptage d'opérations générée en assembleur et effectuées par le processeur
Pour cela, ce gimmick répété tel un mantra peut aider l'informaticien errant: "look the code, Luke!".
La phrase exacte est plus probablement "Use the source, Luke". -- Et moi je reste assis les poumons dans la sciure A filer mes temps morts à la mélancolie. Soleil, soleil, N'est ce pas merveilleux de se sentir piégé ? H.F. Thiéfaine- 713705 Cherche Futur
Le 2018-07-30, zeLittle nous expliquait dans
fr.comp.os.linux.configuration
(<op.zmzgo3dg3tmzun@mainate.home>) :
Le Mon, 30 Jul 2018 22:50:54 +0200, zeLittle
<noreplay@noreplay.net.invalid> a écrit:
c'est à dire le comptage d'opérations générée en assembleur et
effectuées par le processeur
Pour cela, ce gimmick répété tel un mantra peut aider l'informaticien
errant: "look the code, Luke!".
La phrase exacte est plus probablement "Use the source, Luke".
--
Et moi je reste assis les poumons dans la sciure
A filer mes temps morts à la mélancolie.
Soleil, soleil,
N'est ce pas merveilleux de se sentir piégé ?
H.F. Thiéfaine- 713705 Cherche Futur
Le 2018-07-30, zeLittle nous expliquait dans fr.comp.os.linux.configuration () :
Le Mon, 30 Jul 2018 22:50:54 +0200, zeLittle a écrit:
c'est à dire le comptage d'opérations générée en assembleur et effectuées par le processeur
Pour cela, ce gimmick répété tel un mantra peut aider l'informaticien errant: "look the code, Luke!".
La phrase exacte est plus probablement "Use the source, Luke". -- Et moi je reste assis les poumons dans la sciure A filer mes temps morts à la mélancolie. Soleil, soleil, N'est ce pas merveilleux de se sentir piégé ? H.F. Thiéfaine- 713705 Cherche Futur
