Discussion :

[Furikawari]

Knuth parle bien de parallélisme et multi-core (bien que pour la partie multi-core il ne le cite pas explicitement, mais c'est assez clair dans son propos) et pas uniquement de multi-threading en environnement mono-proc mono-core (et encore même dans ce cas là, je demande à voir une GUI potable faîte avec un seul thread...).

Evidemment mon opinion n'est absolument pas biaisée par le fait que j'ai fait ma thèse dans un labo de parallélisme... (et pourtant je l'ai rédigée avec LaTeX )

Edit pour Millie : je pensais aux chapîtres en écrivant section, j'avais oublié que section était un mot clef, toutes mes confuses

[etdmi3]

je m'excuse une autre fois.
quel est la différence entre un processeur qui est basé sur le multithreading
et un processeur multicore ?
Et comment une application peut-elle tourner sur chaqu'un des deux?

[etdmi3]

Si les besoins de synchronisation sont réduits par rapport au nombre de calculs indépendants, il est certain que l'on y gagne (j'ai vu des codes de calcul de modélisation météo gagner un facteur 3.2 en passant de 1 à 4 core).

je m'excuse une autre fois.
je n'arrive pas à comprendre comment peut-on gagner en réduisant la synchronisation dans un processeur multicore et est ce que c'est la même chose pour le multithreading
quel est la différence entre un processeur qui est basé sur le multithreading
et un processeur multicore ?
Et comment une application peut-elle tourner sur chaqu'un des deux?

[millie]

Le multithreading est une notion liée à l'OS. L'OS permet de faire tourner plusieurs threads en même temps (virtuellement parlant) -> en fait, il y a des changements de contexte effectué par l'OS lorsqu'il y a changement de thread et gros changement de contexte lorsqu'il y a changement de processus.

Sur un processeur monocore et les machines monoprocesseur comme les gens ont eu pendant longtemps (je parle pas des serveurs), il n'y a qu'un seul thread qui peut tourner en même temps (il n'y a qu'une instruction machine effectuée par cycle). L'OS donne l'autorisation sucessivement à tous les threads en cours d'exécution pour le thread s'exécute un court laps de temps.

Sur un processeur multicore ou sur des machines multiprocesseur, il peut y avoir un thread associé à un coeur (c'est l'OS qui s'en occupe), l'ordinateur est capable d'effectuer un certains nombre d'opération simultané (par coeur/processeur), sachant que chaque processeur/coeur ont également des registres à eux (genre registre pour la pile etc. ce qui permet de simplifier la répartition d'un thread par coeur/processeur). Donc grosso modo, il peut y avoir 2 flots d'exécution simultané sur un dualcore.

[souviron34]

je m'excuse une autre fois.
je n'arrive pas à comprendre comment peut-on gagner en réduisant la synchronisation dans un processeur multicore et est ce que c'est la même chose pour le multithreading
quel est la différence entre un processeur qui est basé sur le multithreading
et un processeur multicore ?
Et comment une application peut-elle tourner sur chaqu'un des deux?

je n'ai pas parlé de "réduire la synchronisation".

J'ai dit "si les besoins de synchro ne sont pas trop importants". C'est à dire si il n'y a pas à synchroniser à chaque opération (ou quelques)..

Physiquement, il n'y a pas "un processeur multicore", il y a une machine bi-, tri-, quadri-, multi-processeurs... un "core" est un CPU. On peut avoir plusieurs processeurs sur une machine, ou plusieurs CPU (avec leurs drivers) sur le même processeur, mais cela revient au même : N "processing units" indépendantes.

La limitation est la même pour les 2 cas : puisque les tâches tournent indépendamment l'une de l'autre sur chacun des "core" ou des processeurs, il faut les synchroniser entre elles (si ce n'est pas N fois le même programme qui tourne, mais un programme splitté sur N CPUs).

Même si le changement de contexte est moins pénalisant pour les threads, comme l'explique Millie, il n'en st pas moins vrai que c'est pénalisant.

Or doncques, si il y a trop de synchronisation, on perd d'un côté ce qu'on gagne de l'autre.

D'où ma remarque que ça ne s'applique pas partout, et que le gain n'est pas proportionnel de toutes façons... Et que, compte tenu de ça, il me semble plus qu'évident que cela ne devrait être utilisé que dans des cas spécifiques , et pas à tout va comme maintenant...

(je ne sais pas si c'est toujours le cas, mais des constructeurs comme Silicon Graphics fournissaient dans la fin des années 80 début 90 des constantes (un fichier d'entête) à inclure du style "define N_CPUS 4", et un paralléliseur de code qui transformaient les boucles en "for ( i = 0 ; i < NCPUS ; i++)").

[Jedai]

je m'excuse une autre fois.
quel est la différence entre un processeur qui est basé sur le multithreading
et un processeur multicore ?
Et comment une application peut-elle tourner sur chaqu'un des deux?

Aucun processeur n'est "basé sur le multithreading", un ordinateur multicore contient une puce qui contient plusieurs CPU et qui peut donc exécuter deux (ou plus) listes d'instructions en même temps, un ordinateur multi-processeur contient plusieurs puces, éventuellement multicores elle-même.
Le multithreading recouvre 2 notions : une sorte de processus léger géré au niveau de l'OS et l'une des façon de construire un programme pour exécuter des tâches en parallèles, avec synchronisation de temps en temps par des primitives. Un programme écrit en style multithread utilise généralement (mais pas toujours) les threads de l'OS pour faire tourner les threads qu'il décrit.

La plupart des critiques actuelles portent sur le style multithread, pas tellement sur le concept au niveau OS qui est utile par lui même, les détracteurs du multithread pensent que ce style n'est pas la bonne solution à terme pour écrire des programmes qui tirent profit du parallélisme rendu possible par les processeurs multicores. Ils mettent en avant le nombre de bugs facile à introduire dans ce modèle et la difficulté à les déceler et les éliminer par la suite. Il y a un certain nombre d'alternatives, mais le multithread reste le plus utilisé.
Le débat a toujours existé, mais il gagne une audience de plus en plus large avec l'apparition de multicore de plus en plus "multi" auprès du grand public : il devient intéressant d'être capable de tirer partie de toute cette puissance de calcul massivement parallèle, et la fréquence des processeurs n'augmente plus vraiment, pour poursuivre la course en avant dont l'informatique avait pris l'habitude, il faut changer le modèle.

--
Jedaï

[dapounet]

Le débat a toujours existé, mais il gagne une audience de plus en plus large avec l'apparition de multicore de plus en plus "multi" auprès du grand public : il devient intéressant d'être capable de tirer partie de toute cette puissance de calcul massivement parallèle, et la fréquence des processeurs n'augmente plus vraiment, pour poursuivre la course en avant dont l'informatique avait pris l'habitude, il faut changer le modèle.

Un message intéressant à ce sujet : http://forum.canardpc.com/showpost.p...9&postcount=89.

[etdmi3]

merci encore pour votre aide.
les choses deviennent plus claires.

[souviron34]

Un message intéressant à ce sujet : http://forum.canardpc.com/showpost.p...9&postcount=89.

merci

[GnuVince]

Premièrement, les programmeurs sont baisés: les constructeurs de microprocesseurs ne vont pas arrêter d'ajouter des coeurs et les consommateurs vont devenir de plus en plus mécontents de voir que seulement un processeur sur quatre est utilisé pour exécuter une tâche (et ça va devenir 1/8 et 1/12 et 1/24...)

Donc en dépit des commentaires de Dr Knuth sur l'utilité des processeurs avec plusieurs coeurs et le manque d'imagination et d'ingéniosité des constructeurs de matériel, la réalité est que les multi-coeurs sont là pour rester.

Qu'est-ce qu'on fait? Je veux tout d'abord parler de la différence entre les mots "concurrence" et "parallélisme": la concurrence est quand plusieurs tâches non-reliées s'exécutent en même temps (ex.: analyser un document et rafraîchir une barre de progression.) Le parallélisme est quand on se sert de plusieurs processeurs (ou de plusieurs ordinateurs) pour accélérer le traitement d'une tâche. Le parallélisme est plus "rare", car ce ne sont pas toutes les tâches qui s'y prêtent bien ou facilement.

Maintenant, comment rendre facile la programmation de programmes à plusieurs threads? On entend des histoires d'horreur à gauche et à droite sur les dead locks, les race conditions, la synchronisation, etc. Certainement, si on désire que les programmeurs se servent de tous les coeurs, ça doit être assez facile. Sur Wikipedia, la page sur le thread safety donne quelques indicateurs qui suggèrent qu'une fonction n'est pas thread-safe. Un point important, éviter les effets de bord.

Les langages fonctionnels ont longtemps été ridiculisés par les programmeurs de langages impératifs et orienté-objet comme étant de la masturbation académique sans aucune valeur pratique. L'avènement des processeurs multi-coeur pourrait marquer l'entrée de la programmation fonctionnelle dans les paradigmes utilisés en entreprise. La plupart de ces langages prônent des structures de données non-modifiables, donc idéales dans le cadre où plusieurs threads vont examiner leur valeur.

Au cours des dernières années, le paradigme fonctionnel a connu une poussée, sans doute à cause du problème des processeurs multi-coeurs: les langages tels que C# et Java commencent à intégrer des concepts pris directement du monde fonctionnel, Microsoft montrent un intérêt marqué pour le F#, les langages Erlang et Haskell gagnent en popularité, Clojure, un dialecte de Lisp avec un focus plus poussé pour la programmation fonctionnelle et intégré à la machine virtuelle Java -- qui a été annoncé il y a seulement un an -- gagne aussi en popularité et beaucoup de Lispeux le voit comme étant le futur de Lisp.

Un des créateur de Haskell et du compilateur GHC, Simon Peyton-Jones, annonçait récemment qu'à son avis, le grand changement des 10 prochaines années sera un courant qui rendra le paradigme fonctionnel le défaut dans la plupart des langages avec une façon d'être impératif quand c'est nécessaire.

Pour ceux qui comprennent l'anglais, vous pouvez visionner une présentation très intéressante par Rich Hickey, le créateur de Clojure, sur les problèmes de concurrence causés par le paradigme impératif et comment Clojure s'est attaqué à ces problèmes: http://blip.tv/file/812787

[etdmi3]

comment le matériel peut-il améliorer la qualité du parallélisme dans une machine et en particulier avec la techno multicore.
Quelles sont les attributions de la compilation(parallélisme automatique)dans ce domaine et comment peut-on l'améliorer pour éviter la programmation manuelle.
merci

[souviron34]

Premièrement, les programmeurs sont baisés:
..
Maintenant, comment rendre facile la programmation de programmes à plusieurs threads?
..

Tu prouves la confusion...


Répétons encore une fois

Programmer un multi-core n'est pas synonyme de programmer à plusieurs threads ...

Certaines bibliothèques, commandes d'OS, etc.. existent pour affecter un programme (binaire) à un core en particulier, par exemple...


Et, revenons encore à cette notion, programmer à plusieurs threads, si je suis ton raisonnement, n'est pas faire du parallélisme.

Or, avec ta définition de la concurrence, ce ne serait utile que dans ce cas, puisque les cas de parallélisme seraient, tu en conviens, "rares"..

Ce qui suppose, d'après toi-même "quand plusieurs tâches non-reliées s'exécutent en même temps ". OK.

Maintenant explique-moi comment chacune de ces tâches indépendantes devrait inclure la possibilité de multi-threads, revenant dans les faits à un parallélisme...

Ce qui est en contradiction avec ce que tu dis...

comment le matériel peut-il améliorer la qualité du parallélisme dans une machine et en particulier avec la techno multicore.
Quelles sont les attributions de la compilation(parallélisme automatique)dans ce domaine et comment peut-on l'améliorer pour éviter la programmation manuelle.
merci

On va pas faire le rapport à ta place

[GnuVince]

souviron34: Je voudrais te répondre, mais ton message n'est pas clair du tout. Si tu pouvais le ré-éditer pour qu'on puisse en saisir le sens, je pourrai répondre à tes questions.

[souviron34]

dans le début de mon post, j'avais fait une plaisanterie entre "baisé" et "biaisé" ..

Bon, OK..

Alors voilà..

Tu commences par :

Qu'est-ce qu'on fait? Je veux tout d'abord parler de la différence entre les mots "concurrence" et "parallélisme": la concurrence est quand plusieurs tâches non-reliées s'exécutent en même temps (ex.: analyser un document et rafraîchir une barre de progression.) Le parallélisme est quand on se sert de plusieurs processeurs (ou de plusieurs ordinateurs) pour accélérer le traitement d'une tâche. Le parallélisme est plus "rare", car ce ne sont pas toutes les tâches qui s'y prêtent bien ou facilement.

Et ensuite tu passes à :

Maintenant, comment rendre facile la programmation de programmes à plusieurs threads?

ça se rattache à quoi ? faire du multi-thread pour faire du multi-thread ? concurrence ? parallèlisme ?

C'est la question que je pose.

D'après ta définition de la concurrence, aucun besoin de faire du multi-thread pour cela. Une application mono-thread, ou sans aucun thread mais lancée avec les fonctionalités (fournies en général par les constructeurs ou par une commande de l'OS directement) permettant l'affectation à un core particulier, marche de manière indépendante des autres.

Et en ce qui concerne le parallélisme, tu dis toi-même que ce cas est (comme on le disait au dessus), plutôt rare, et d'autres moyens sont disponibles pour ces cas-là.

[SpiceGuid]

@NokyDaOne
Vu que tu sais déjà de quoi tu parles la question ne se pose même pas: Haskell sans hésitation.

Il y a bien des choses sur .Net mais là il faut gratter le verni de la propagande MS pour faire la différence entre une véritable avancée et un écran de fumée.
Avec Haskell tu es certain d'avoir the real thing.

Premièrement, les programmeurs sont baisés: les constructeurs de microprocesseurs ne vont pas arrêter d'ajouter des coeurs et les consommateurs vont devenir de plus en plus mécontents de voir que seulement un processeur sur quatre est utilisé pour exécuter une tâche (et ça va devenir 1/8 et 1/12 et 1/24...)

Dans un premier temps oui, mais dès que les acheteurs auront compris que le multi-core ça sert à faire de multiples choses simultanément et pas une seule chose multi-fois plus vite, là c'est les fondeurs qui vont souffrir.
Tôt ou tard le consommateur va finir par penser: je ne veux pas 32 coeurs, je veux 2 coeurs pour 16 fois moins cher.

[etdmi3]

bonjour à tous,
je voudrais savoir est ce que plus on divise les taches(cad avoir des taches de plus petites de taille) sur un système multicore plus on garantira les performances et cela ne serait pas une solution pour le pb actuel

[Furikawari]

Dépendance des données. Je n'en dis pas plus sinon je redige ton rapport à ta place comme le disait Souviron.

[Jedai]

bonjour à tous,
je voudrais savoir est ce que plus on divise les taches(cad avoir des taches de plus petites de taille) sur un système multicore plus on garantira les performances et cela ne serait pas une solution pour le pb actuel

Non, c'est un des gros problème de la parallélisation automatique : lancer une tâche a toujours un coût (plus ou moins constant) en plus du coût de la tâche à exécuter, ce surcoût signifie qu'on doit trouver un équilibre entre le parallélisme obtenu (le nombre de tâche créées) et la taille de chacune de ces tâches.
C'est particulièrement vrai si on utilise simple un thread noyau par tâche, mais passer à des threads utilisateurs ou autre modèle ne fait que modifier l'équilibre, il n'en supprime pas le besoin.

--
Jedaï

[etdmi3]

J'éspère que je serai cette fois-ci dans le bon emplacement et ce n'est pas du rapport cette fois ci
si j'ai à choisir une approche ,laquelle est meilleure?
un petit nombre de processeurs très puissants sur un système parallèle à mémoire partagée ou un grand nombre de processeurs simples sur un système parallèle à mémoire distribuée .
je suppose que les hypothèses du pb sont fixes ou standards
Est ce qu'on peut avoir des performances de calculs globales proches?
je serais reconnaissante d'avoir une réponse détaillée et merci

[etdmi3]

C'est particulièrement vrai si on utilise simple un thread noyau par tâche, mais passer à des threads utilisateurs ou autre modèle ne fait que modifier l'équilibre, il n'en supprime pas le besoin.

--
Jedaï

Dans ce cas ,on revient aux contraintes des logiciels et des applications développées par les programmeurs qui "must be aware about this problem"
cad développer leur application en tenant compte de ces contraintes