# Bi-processeur, OK mais pourquoi faire ?



## Scorpion (9 Septembre 2005)

Ca sert à quoi d'avoir une architecture bi-processeurs ? J'imagine que ca aider à faire tourner plusieurs applis ouvertes en même temps, mais pourriez vous m'en dire plus ?


----------



## geoffrey (9 Septembre 2005)

C'est assez simple, à la place d'avoir un processeur qui travaille et qui ne peut donc traiter les instructions qu'une apres l'autre, le bi-proc en traitera deux en meme temps. Et certaines applis gourmandes (si elles ont été devloppées pour), utiliserons les deux proc en meme temps.


----------



## Scorpion (9 Septembre 2005)

geoffrey a dit:
			
		

> C'est assez simple, à la place d'avoir un processeur qui travaille et qui ne peut donc traiter les instructions qu'une apres l'autre, le bi-proc en traitera deux en meme temps. Et certaines applis gourmandes (si elles ont été devloppées pour), utiliserons les deux proc en meme temps.


C'est d'une simplicité Biblique.


----------



## geoffrey (9 Septembre 2005)

Apres y'a encore la notion de mutli-threading, qui permet le multi tache (un seul processeur pouvant executer plusieurs applications à la fois proprement)


----------



## mfay (9 Septembre 2005)

En plus ça peut aider le multi-processeur.

Pas de problème pour Graver un DVD, faire un DIVX, et jouer en même temps. C'est là qu'on voit que le mac est fortement multi-tache. (Sur PC les trois choses en même temps, ça plante  )


----------



## Apca (9 Septembre 2005)

Scorpion a dit:
			
		

> Ca sert à quoi d'avoir une architecture bi-processeurs ?



A bi-Processer bien sur !  :rateau: 

J'en suis content moi, car au lieu d'avoir le processeur qui tourne à fonds lors du tache, ils travaillent tous les deux en commun, et se partagent le travaillent   :love:


----------



## Bibi75 (9 Septembre 2005)

Est-ce que c'est vraiment flagrant un bi-pro par rapport à un Imac ?? Est-ce que les jeux en tirent profit ?


----------



## Apca (9 Septembre 2005)

Bibi75 a dit:
			
		

> Est-ce que c'est vraiment flagrant un bi-pro par rapport à un Imac ?? Est-ce que les jeux en tirent profit ?



Je crois pas que c'est si flagrant que ca ! D'accord un bi pro ira toujours mieux. Pour moi je trouve que en plus d'un bon processeur, il faut surtout une bonne carte graphique.


----------



## PA5CAL (10 Septembre 2005)

Bi-proc, qui tourne deux fois plus vite... c'est à voir !

Soit, les unités de calcul et la mémoire cache de chaque processeur peuvent travailler en parallèle sans se gêner.

Mais dès qu'il s'agit d'accéder au bus, à la mémoire, à la vidéo et au disque, il commence à y avoir des embouteillages ! Et ça arrive plutôt fréquemment quand la taille du programme ou le volume des données deviennent importants. 



			
				mfay a dit:
			
		

> (...) Pas de problème pour Graver un DVD, faire un DIVX, et jouer en même temps. (...)


Voilà trois exemples d'application qui sollicitent fortement les ressources les plus lentes de la machine, qui représentent un goulet d'étranglement. Il y a fort à parier que, pendant une partie non négligeable du temps, lorsqu'un des processeurs travaillera (et chargera/déchargera sa cache) son jumeau attendra qu'on veuille bien le nourrir en instructions et en données.

Un bi-processeur ne travaille donc pas forcément deux fois plus vite qu'un mono-processeur. Simplement, on utilise au maximum la bande passante du bus et de la mémoire.



			
				Apca a dit:
			
		

> (...) au lieu d'avoir le processeur qui tourne à fonds lors du tache, ils travaillent tous les deux en commun, et se partagent le travail (...)


... A condition d'avoir développé les programmes en conséquence. Par exemple, une application mono-thread ne tournera que sur un seul des processeurs à la fois.

On arrive à des résultats spectaculaires quand on fait tourner des programmes optimisés pour cette configuration particulière, et notamment les calculs intensifs parallélisés sur deux threads (traitement du signal, traitement d'image, simulation électrique...).

En revanche, l'exécution de deux applications indépendantes gourmandes en flux de données n'est pas vraiment intéressante.


----------



## NightWalker (10 Septembre 2005)

Je trouve que l'exemple de la gravure de DVD et encodage de DIVX est un bon exemple... ces deux tâches peuvent bien être réparties sur les deux proc étant donné que les deux n'utilisent aucune ressource commune. Et OS X est parfaitement optimisé pour distribuer les tâches...


----------



## PA5CAL (10 Septembre 2005)

NightWalker a dit:
			
		

> (...) les deux n'utilisent aucune ressource commune (...)


... Et la mémoire ? Et le bus ? Et le disque dur ?


----------



## Kilian2 (10 Septembre 2005)

Regardez ici


----------



## NightWalker (10 Septembre 2005)

PA5CAL a dit:
			
		

> ... Et la mémoire ? Et le bus ? Et le disque dur ?


Yep mais tu as le gestionnaire de mémoire qui gère et protège tout ça, et n'oublies pas que chaque proc possède son propre bus... Et quand on sait que chaque proc possède un bus à la moitiè de la fréquence du proc lui même... c'est carrément négligeable...

Dans les deux exemples que j'ai cité utilise d'avantage le proc et la mémoire pour l'encodage en  Divx... et l'encodage DVD pour la gravure... je n'ai pas dit non plus que 2 proc = 2x plus rapide...


----------



## Apca (10 Septembre 2005)

PA5CAL a dit:
			
		

> ... A condition d'avoir développé les programmes en conséquence. Par exemple, une application mono-thread ne tournera que sur un seul des processeurs à la fois.



Pourtant, quands j'ai une application lancée les deux processeurs travaillent en même temps, quelle que soit l'application.


----------



## PA5CAL (10 Septembre 2005)

Apca a dit:
			
		

> Pourtant, quands j'ai une application lancée les deux processeurs travaillent en même temps, quelle que soit l'application.


C'est parce que l'appli n'est pas la seule à tourner. Les appels système de l'appli peuvent être pris en charge par le deuxième processeur, et le thread peut tourner sur l'un, puis sur l'autre processeur, mais pas sur les deux en même temps.

Il m'est arrivé de devoir coder du calcul intensif (temps réel) sur une machine multiprocesseurs (ce n'était pas un ordinateur personnel). Pour tirer parti au mieux de l'architecture, l'algo de calcul devait être scindé en plusieurs threads synchronisés, les plus indépendants possibles, et utilisant au maximum les informations déjà présente dans la mémoire commune. Le même algo pour un environnement monoprocesseur n'aurait rien eu de commun avec ce qui a été fait. Même pas la méthode de calcul retenue. Sinon ce serait du gâchis.


----------

