Bonjour,
Question certainement naïve d'un néophyte complet, vous voudrez bien m'en
excuser.
Il y a quelques années, j'avais essayé quelques distributions de Linux, plus
par curiosité que par nécessité. Mais j'ai été rebuté par le côté
"bricolage". La philosophie de l'époque était qu'il fallait mettre les mains
dans le cambouis pour arriver a faire ce qu'on voulait et en particulier à
gérer ses périphériques.
Il semble que les choses ont bien évolué, c'est en tout cas ce qu'on entend
un peu partout. Peut-on aujourd'hui affirmer que Linux est aussi simple et
convivial que XP pour un profane? Si c'est le cas, je me lance de suite. Et
quelle distribution conseillez-vous à un débutant ?
Merci pour vos lumières.
Phil
Et quand on a une *très* laide écriture de gaucher contrarié, on fait comment? ;-)
On fait un effort ?
Je suis gaucher contrarié et j'ai une jolie écriture :)
Ah mais je sais avoir une jolie écriture, mais au prix d'une vitesse d'écriture digne d'un élève de CE. ;-)
R12y
Non c'est le compilateur (ou l'auteur du programme) qui doit paralléléliser. Ou le processeur.
Je comprends pas.
Si c'est le processeur qui parallelise, le programmeur n'a pas besoin de changer ses habitudes de programmation lors du passage au dual core, puisque le dual core va lui-même paralleliser. C'est ça?
Non c'est le compilateur (ou l'auteur du
programme) qui doit paralléléliser.
Ou le processeur.
Je comprends pas.
Si c'est le processeur qui parallelise, le programmeur n'a pas besoin de
changer ses habitudes de programmation lors du passage au dual core,
puisque le dual core va lui-même paralleliser. C'est ça?
Non c'est le compilateur (ou l'auteur du programme) qui doit paralléléliser. Ou le processeur.
Je comprends pas.
Si c'est le processeur qui parallelise, le programmeur n'a pas besoin de changer ses habitudes de programmation lors du passage au dual core, puisque le dual core va lui-même paralleliser. C'est ça?
Non c'est le compilateur (ou l'auteur du programme) qui doit paralléléliser. Ou le processeur.
Je comprends pas.
Si c'est le processeur qui parallelise, le programmeur n'a pas besoin de changer ses habitudes de programmation lors du passage au dual core, puisque le dual core va lui-même paralleliser. C'est ça?
Désolé hein, je me suis embrouillé... :-)
Oui et non. Le processeur va pas mal aider pour essayer de détecter ce qu'il peut exécuter en parallèle, mais le programmeur doit un peu l'aider quand même. En gros, pour grossir le trait (parce que ce cas est précisément couvert par le compilateur ou le processeur), si jamais tu fais un truc du genre
resultat <- a + b + c +d
Il vaudrait mieux faire
resultat <- (a+b) + (c+d)
Ce qui va plus ou moins se traduire en
res1 <- a + b res2 <- c + d res1 <- res1 + res2
Bref. Le gros problème en ce moment, c'est qu'au niveau du système, c'est bien, tu as un certain niveau de parallélisme qui a été mis en place, et qui permet au moins de gérer deux programmes en parallèle (c'est déjà ça), et plus finement si les programmes utilisent correctement les threads. Mais c'est loin d'être le cas de tous les programmes.
En ce moment, il y a un énorme enjeu en ce qui concerne l'optimisation de compilation, car justement les compilateurs ne prennent pas bien en compte (voire pas du tout) l'aspect "multi-coeur" des nouveaux procs. GCC va dans le bon sens en faisant de la vectorisation (d'un autre côté, j'ai ouï dire que c'était la condition sine qua none pour que certaines boites acceptent de mettre quelques ingés sur le projet ...).
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
Non c'est le compilateur (ou l'auteur du
programme) qui doit paralléléliser.
Ou le processeur.
Je comprends pas.
Si c'est le processeur qui parallelise, le programmeur n'a pas besoin de
changer ses habitudes de programmation lors du passage au dual core,
puisque le dual core va lui-même paralleliser. C'est ça?
Désolé hein, je me suis embrouillé... :-)
Oui et non. Le processeur va pas mal aider pour essayer de détecter ce
qu'il peut exécuter en parallèle, mais le programmeur doit un peu l'aider
quand même. En gros, pour grossir le trait (parce que ce cas est
précisément couvert par le compilateur ou le processeur), si jamais tu
fais un truc du genre
resultat <- a + b + c +d
Il vaudrait mieux faire
resultat <- (a+b) + (c+d)
Ce qui va plus ou moins se traduire en
res1 <- a + b
res2 <- c + d
res1 <- res1 + res2
Bref. Le gros problème en ce moment, c'est qu'au niveau du système, c'est
bien, tu as un certain niveau de parallélisme qui a été mis en place, et
qui permet au moins de gérer deux programmes en parallèle (c'est déjà ça),
et plus finement si les programmes utilisent correctement les threads.
Mais c'est loin d'être le cas de tous les programmes.
En ce moment, il y a un énorme enjeu en ce qui concerne l'optimisation de
compilation, car justement les compilateurs ne prennent pas bien en compte
(voire pas du tout) l'aspect "multi-coeur" des nouveaux procs. GCC va dans
le bon sens en faisant de la vectorisation (d'un autre côté, j'ai ouï dire
que c'était la condition sine qua none pour que certaines boites acceptent
de mettre quelques ingés sur le projet ...).
--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)
Non c'est le compilateur (ou l'auteur du programme) qui doit paralléléliser. Ou le processeur.
Je comprends pas.
Si c'est le processeur qui parallelise, le programmeur n'a pas besoin de changer ses habitudes de programmation lors du passage au dual core, puisque le dual core va lui-même paralleliser. C'est ça?
Désolé hein, je me suis embrouillé... :-)
Oui et non. Le processeur va pas mal aider pour essayer de détecter ce qu'il peut exécuter en parallèle, mais le programmeur doit un peu l'aider quand même. En gros, pour grossir le trait (parce que ce cas est précisément couvert par le compilateur ou le processeur), si jamais tu fais un truc du genre
resultat <- a + b + c +d
Il vaudrait mieux faire
resultat <- (a+b) + (c+d)
Ce qui va plus ou moins se traduire en
res1 <- a + b res2 <- c + d res1 <- res1 + res2
Bref. Le gros problème en ce moment, c'est qu'au niveau du système, c'est bien, tu as un certain niveau de parallélisme qui a été mis en place, et qui permet au moins de gérer deux programmes en parallèle (c'est déjà ça), et plus finement si les programmes utilisent correctement les threads. Mais c'est loin d'être le cas de tous les programmes.
En ce moment, il y a un énorme enjeu en ce qui concerne l'optimisation de compilation, car justement les compilateurs ne prennent pas bien en compte (voire pas du tout) l'aspect "multi-coeur" des nouveaux procs. GCC va dans le bon sens en faisant de la vectorisation (d'un autre côté, j'ai ouï dire que c'était la condition sine qua none pour que certaines boites acceptent de mettre quelques ingés sur le projet ...).
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
Manuel Leclerc
En ce moment, il y a un énorme enjeu en ce qui concerne l'optimisation de compilation, car justement les compilateurs ne prennent pas bien en compte (voire pas du tout) l'aspect "multi-coeur" des nouveaux procs. GCC va dans le bon sens en faisant de la vectorisation (d'un autre côté, j'ai ouï dire que c'était la condition sine qua none pour que certaines boites acceptent de mettre quelques ingés sur le projet ...).
A mon humble avis à moi que j'ai, pour tirer parti du multi-coeur, il faut programmer en multi-thread et je ne vois pas ce que le pauvre compilateur C vient faire là dedans.
-- Hein ?
En ce moment, il y a un énorme enjeu en ce qui
concerne l'optimisation de compilation, car justement
les compilateurs ne prennent pas bien en compte
(voire pas du tout) l'aspect "multi-coeur" des nouveaux
procs. GCC va dans le bon sens en faisant
de la vectorisation (d'un autre côté, j'ai ouï dire que
c'était la condition sine qua none pour que certaines
boites acceptent de mettre quelques ingés sur le projet ...).
A mon humble avis à moi que j'ai, pour tirer parti du
multi-coeur, il faut programmer en multi-thread et je
ne vois pas ce que le pauvre compilateur C vient faire
là dedans.
En ce moment, il y a un énorme enjeu en ce qui concerne l'optimisation de compilation, car justement les compilateurs ne prennent pas bien en compte (voire pas du tout) l'aspect "multi-coeur" des nouveaux procs. GCC va dans le bon sens en faisant de la vectorisation (d'un autre côté, j'ai ouï dire que c'était la condition sine qua none pour que certaines boites acceptent de mettre quelques ingés sur le projet ...).
A mon humble avis à moi que j'ai, pour tirer parti du multi-coeur, il faut programmer en multi-thread et je ne vois pas ce que le pauvre compilateur C vient faire là dedans.
-- Hein ?
talon
R12y wrote:
Non c'est le compilateur (ou l'auteur du programme) qui doit paralléléliser. Ou le processeur.
Je comprends pas.
Si c'est le processeur qui parallelise, le programmeur n'a pas besoin de changer ses habitudes de programmation lors du passage au dual core, puisque le dual core va lui-même paralleliser. C'est ça?
Désolé hein, je me suis embrouillé... :-)
Oui tu t'es embrouillé. La parallélisation en question se fait dans le processeur, elle ne risque donc pas de répartir les instructions sur les deux processeurs. Il s'agit de convertir les instructions CISC en instructions plus élémentaires RISC et de les exécuter en parallèle et de façon désordonnée. C'est dans *chaque* processeur* qu'il y a une unité de décodage qui fait ça, puis des unités de dispatch qui dispatche les instructions sur les registres, qui font de la prédiction de branchement pour optimiser ça, etc. Il y a beaucoup plus de registres rééls que le maigre lot que présente le x86 à l'extérieur. Ce que le compilateur réalise est tout autre, il s'agit d'envoyer des paquets d'instructions CISC aux deux processeurs, ce qui suppose qu'ils puissent s'exécuter indépendamment, et soient suffisamment gros pour que ça vaille le coup. La fois où j'avais essayé ça avec le compilateur Intel sur un programme de calcul, ça divisait à peu prés par 10 les performances du programme! Comme tu vois ce n'est pas trivial. Par contre j'avais vu une multiplications par 2 sur une SUN biproc avec le compilateur SUN, sur un autre programme de calcul. Morale, ça a plus de chance de marcher si c'est le programmeur qui programme lui même les threads.
Non c'est le compilateur (ou l'auteur du
programme) qui doit paralléléliser.
Ou le processeur.
Je comprends pas.
Si c'est le processeur qui parallelise, le programmeur n'a pas besoin de
changer ses habitudes de programmation lors du passage au dual core,
puisque le dual core va lui-même paralleliser. C'est ça?
Désolé hein, je me suis embrouillé... :-)
Oui tu t'es embrouillé. La parallélisation en question se fait dans le
processeur, elle ne risque donc pas de répartir les instructions sur les deux
processeurs. Il s'agit de convertir les instructions CISC en instructions
plus élémentaires RISC et de les exécuter en parallèle et de façon
désordonnée. C'est dans *chaque* processeur* qu'il y a une unité de décodage
qui fait ça, puis des unités de dispatch qui dispatche les instructions sur
les registres, qui font de la prédiction de branchement pour optimiser ça,
etc. Il y a beaucoup plus de registres rééls que le maigre lot
que présente le x86 à l'extérieur. Ce que le compilateur réalise est tout
autre, il s'agit d'envoyer des paquets d'instructions CISC aux deux
processeurs, ce qui suppose qu'ils puissent s'exécuter indépendamment, et
soient suffisamment gros pour que ça vaille le coup. La fois où j'avais essayé
ça avec le compilateur Intel sur un programme de calcul, ça divisait à peu
prés par 10 les performances du programme! Comme tu vois ce n'est pas trivial.
Par contre j'avais vu une multiplications par 2 sur une SUN biproc avec le
compilateur SUN, sur un autre programme de calcul. Morale, ça a plus de chance
de marcher si c'est le programmeur qui programme lui même les threads.
Non c'est le compilateur (ou l'auteur du programme) qui doit paralléléliser. Ou le processeur.
Je comprends pas.
Si c'est le processeur qui parallelise, le programmeur n'a pas besoin de changer ses habitudes de programmation lors du passage au dual core, puisque le dual core va lui-même paralleliser. C'est ça?
Désolé hein, je me suis embrouillé... :-)
Oui tu t'es embrouillé. La parallélisation en question se fait dans le processeur, elle ne risque donc pas de répartir les instructions sur les deux processeurs. Il s'agit de convertir les instructions CISC en instructions plus élémentaires RISC et de les exécuter en parallèle et de façon désordonnée. C'est dans *chaque* processeur* qu'il y a une unité de décodage qui fait ça, puis des unités de dispatch qui dispatche les instructions sur les registres, qui font de la prédiction de branchement pour optimiser ça, etc. Il y a beaucoup plus de registres rééls que le maigre lot que présente le x86 à l'extérieur. Ce que le compilateur réalise est tout autre, il s'agit d'envoyer des paquets d'instructions CISC aux deux processeurs, ce qui suppose qu'ils puissent s'exécuter indépendamment, et soient suffisamment gros pour que ça vaille le coup. La fois où j'avais essayé ça avec le compilateur Intel sur un programme de calcul, ça divisait à peu prés par 10 les performances du programme! Comme tu vois ce n'est pas trivial. Par contre j'avais vu une multiplications par 2 sur une SUN biproc avec le compilateur SUN, sur un autre programme de calcul. Morale, ça a plus de chance de marcher si c'est le programmeur qui programme lui même les threads.
