Hi,
 
Conceptuellement, j'ai du mal à voir pourquoi  la programmation multi-thread permet d'augmenter la vitesse d'exécution d'un programme ?
 
Etant donné que le code de chaque thread est exécuté séquentiellement et non parallèlement où se situe le gain en vitesse ??
 
C'est valable uniquement pour les processeurs possédant 2 unités d'exécutions ?
 
Merci !

Thread1 seul: |thread1 bosse|thread1 I/O|cpu idle|thread1 rebosse|............
 
multithread:   |thread1 bosse|thread1 I/O|thread2 bosse|thread1 rebosse|

c'est effectivement surtout valable pour les processeurs multi core , et pour les machine multi processeurs, ce qui représente une bonne partie des machien vendues ces deux dernières années

Et pratiquement, si on possède une machine de type Intel Core 2 Duo, et que l'on se sert d'une librairies tel que Boost pour gérer les threads, l'utilisation des 2 cores est automatiques ?

rien n'ets automatique avec les threads. Y a pas de magie.
Boost::thread permet juste d'expliciter simplement les sections de ton programme qui utilsieront des threads.

comment faire alors? Il faut utiliser l'asm ou bien ??

v_v
non , tu structure ton code de façon à profiter du parallélisme puis tu démarre des fonctions concurrentes avec des threads

c'est à dire il faut le structurer de quelle manière ?

De maniere a pouvoir faire plusieurs choses en meme temps si possible.

mais quand on utilise des threads, notre programme est toujours conçu de manière à pouvoir faire plusieurs choses en meme temps non ?

oui mais c'est toi qui spécifie ce découpage.
Rancarde toi sur le parallélisme en général, la je pense que tu manques de base.

ça marche thx

Le multithreading (ou multiprocessing) permet potentiellement 3 choses:

1. Augmenter la réactivité (d'une interface). En ayant une UI vivant dans un thread/process donné et toute l'exécution dans 1..n autres threads/process (mais jamais dans le thread/process d'UI), l'UI continue à répondre même quand on lance des opérations lourtes (en terme de CPU) derrière. Sans multi(thread|process), dès qu'on lance une action un peu violente l'UI se retrouve intégralement bloquée.

2. Bosser en parallèle à de l'I/O. Si on programme avec des séquences IO/calcul, la partie calcul doit attendre la fin de l'IO (potentiellement longue) avant de pouvoir se lancer, même si elle ne dépend pas de l'IO. De même si on fait de l'IO sur k sources différentes, en mono(thread|process) (et sauf à utiliser des trucs genre select/kpoll) on doit faire toutes les IO l'une après l'autre, puis faire le processing associé. En multi, on peut faire toutes les IOs en même temps, puis dès qu'une IO donnée est terminée lancer les processings qui y sont liés.

3. Enfin ça permet d'augmenter la puissance de calcul totale dispo quand on bosse avec du hardware threadé (avec des threads "virtuels" genre CoolThreads/Hyper-Threading, du multicore ou du multiCPU), mais ce genre de gains impose que la tâche soit parallélisable (ce qui n'est pas toujours le cas, en tout cas pas nécessairement facilement)

Pas nécessairement, il y a des languages avec des compilos auto-parallélisant (Vienna Fortran Compiler, Paradigm C/C++ Compiler, Polaris Fortran Compiler) et des techniques alternatives aux threads classiques dans lesquelles tu spécifies plutôt les bouts non parallélisables (STM)

 
Pour le commun des utilisateurs, cela reste vrai, la preuve la question du PO pour qui le concept meme de parallelisation ets flou.
Et bon, les compilo // automatique ... à part sur du Data-Parallel de mamie, je les ai jamais vu faire grand chose. Cela étant, cela suffit pourtant à pas mal de monde.

Ca c'est sûr, ils sont pas magiques non plus, et les possibilités d'inférences sont limitées dans des langages permettant des effets de bord de partout

d'ou l'attrait pour le parallelisme fonctionel au sens propre (genre BSML ou Parallel Haskell).

 
Merci pour ta réponse bien développé. Maintenant je suis curieux de voir comment on peut effectivement parallélisé son code.

Certains processeurs ont deux coeurs (e.g: Intel Core 2 duo) tant dis que d'autres ont deux coeurs (ou plus) avec en plus la particularité de pouvoir faire tourner chacun deux threads (e.g: Intel Core i7).
Cela veut-il dire que deux processus peuvent tourner simultanément ?(un sur chaque core).  
Ou est-ce que cela permet uniquement de faire travailler 4 threads simultanément ?