Reprise du message précédent :

 
Quake3 gère le SMP ? ah bon .. jamais testé ça !  
 
effectivement, pour 3dsMax et Autocad, le multiprocesseur est géré, et même recommandé si tu utilises beaucoup ce genre de softs ...

 
calmés là, hein on rigole plus....

 
si tu peux le faire .. tu peux forcer l'éxécution d'un process sur un proco déterminé ..

téde,
 
 
normalement le multi-tache des proco de nos PC, utilise un ring (faut penser au jeu de plein aire, .. le facteur n'est pas passé ...), et donc c'est chacun son tour. Le fait que ça se face très vite donne l'illusion de la simultanéité mais il est possible de faire executer 1 tache par unité d'execution simultanément au sens propre du terme. donc si ton programme se démerde bien tu l'as ta simultanéité, quoique partielle je le reconnait

[jfdsdjhfuetppo]--Message édité par barbarella le 24-04-2002 à 14:51:31--[/jfdsdjhfuetppo]

 
bin les cpus superscalaires, répertissent le flux d'instruction du thread (qui est une notion à l'origine "logicielle" ), sr plus sieurs unités, à condition qu'il n'y ait pas d'inter-dépendances génantes, après tu as mieux à partir du ppro, tu as l'exécution out-of-order, ou les instructions (éléméntaires) peuvent être éxécutée dans le désordre, les résultats étant réordonnés après calcul par une unitée....

Donc ca reste  bien un processus a la fois !
 
Il me semblait bien !

 
euh ... petite question bjone : t'as quoi comme formation ? tu as l'air de tres bien t'y connaitre en processeurs !  

http://www.ee.unb.ca/kengleha/cour [...] pter13.pdf

 
téde, le prob du multi-tache c'est pas d'en faire, c'est de savoir comment découper les tache pour faire du multi. du point de vue algo c'est parfois du haut vol et ensuite de synchroniser les résultats. ouille ça ça fait mal parfois

Nan mais on me dit que G  faux alors qu'en fait j'avais bien pris en compte le cas de plusieurs ALU, et dans la vulgarisation abusive qui nous intéresse, un proco n'execute qu'un seul processus a la fois !
 
Donc finalement, contrairement a ce que dit un certain webmaster, j'ai pas tout a fait tort ^^

en gros, le multitâche est effectué par un processeur superscalaire, au moment ou il éxécute une instruction dite "parallelle"  (y fo les 2)

 
tout a fait, y'a que le p4 avec l'hyper-threading qui aura réellement la capacité de faire 2 threads avec le même core.
 
après y'a ptet déjà un cpu (hors intel/amd => x86 kwoi) qui as une approche similaire.... mais je ne croa pas...

MOUHAHAHAHAHA ........ j'en peux plus !!!
 
Question QUIZZ (Je connais les réponses ... ingé info industrielle ) :

• Quelle est la différence entre le parallélisme, le multi tache et le multi thread ??? d
• Comment s'appelle le parallélisme sur un monoproc ?
• Quelle est la différence entre le préemptif et le non-préemptif ?
• Les OS multi proc, gérent ils des process ou des threads ?

mrpochpoch a écrit a écrit :     euh ... petite question bjone : t'as quoi comme formation ? tu as l'air de tres bien t'y connaitre en processeurs !

 
heu bts info-indus, mais bon avec un peu de programmation en asm, et du bouffage de datasheet, on a un peu un ptite idée d'un fonctionnement de cpu...

THREAD !!!

 
Non mais ^^
 
Donc je n'ai pas tort dans mon post de  début, donc je n'ai pas a l'éditer, et y en a qui cherchent la merde ici
 
Vé le bannir tiens.

TNZ a écrit a écrit : THREAD !!!

 
Thread = processus léger, il se peut qu'il n'y aie qu'un seul processus et pas de thread, donc processus et le mot général a utiliser ici ^^

 
ça depend comment tu définis processus. Il ne faut pas oublier la gestion non ordonnée des instructions ce qui rend difficile de définir le processus en court d'execution si on le defini comme un ensemble d'instructions, mais marc sur le coup du superscalaire a raison (il faut que je relise exactement ce qu'il l'a dit ).

bon, vous savez quoi, STOOOOOOOOOOOOOP
 
C'est pas un post encyclopédique non plus ^^
 
On en reste la, pour moi un processus = une tache <=> un  rpogramme pour simplifier pour m'sieu tlm, et ceux qui sont aps contents, dehors !

j'ai pâs dit qu'il avait tort marc j'ai dit qu'il cherchait la chtiote bete !

Je cherche toujours la ptite bete

Tetedeiench a écrit a écrit :     Non mais ^^   Donc je n'ai pas tort dans mon post de  début, donc je n'ai pas a l'éditer, et y en a qui cherchent la merde ici   Vé le bannir tiens.

 
là c'est faux. L'hyperthreating n'est pas du traitement simultané, mais l'un après l'autre d'ou la nécessité des hautes freq pour le P4. quant au unité d'execution (technologie rapid engine) elle gère des signaux en 1/2 freq ce qui donne unequivalent de doublement de la fréquence. Cas de 2 des ALU du P4 actuel. mais seule certaine instruction peuvent être traité ainsi (les plus simple) et dans certaine circonstance.

On oublie de parler du multitâche coopératif et du multitâche préemptif (bon, OK, là, c'est plus au niveau de l'OS que du proco...).
 
Ne pas oublier non plus que les concepts de tâche et de thread sont très liés à l'OS, pas vraiment au proco.
Un CPU, tout ce qu'il sait faire, c'est traiter des instructions de base (additionne, multiplie, décale, range ta chambre...). La finalité de ces instructions (tracer une fenêtre sous Windows, fragger le type d'en face) lui echappe totalement.

Marc a écrit a écrit : Je cherche toujours la ptite bete

 
C sur qu'avec la tienne tu as du mal a trouver...
 
Oups je m'écarte du sujet

De tout façon, le mutli-tâche peut subire des contraintes de la part des intérruptions....

 
voilà, y'a plus qu'a lire

 
Non, non, à partir du moment où il y a un processus, il y a un thread. Le thread est devenu l'unité de traitement, et non plus la tâche.
C'est pour ça que la programmation multi-thread est si chiante...

Un processus execute un programme (ou un interpréteur de commandes (shell/DCL/command.com)); ce processus possède un pointeur d'execution dans l'espace d'adressage mémoire qui lui est réservé.
 
Les threads sont des pointeurs d'execution, et quand un programme est executé dans un processus, si celui-ci est prévu pour du multi-thread, alors tu retrouves autant de pointeurs de programmes que de thread dans le même espace d'addressage mémoire, CàD dans le même programme avec les mêmes variables globales statistiques ou dynamiques, mais pas de variables locales dans la mesure où celles ci sont stockées sur la pile (SP) du thread.
 
 

Ok donc Tedeiench a raison
Mais bon en pratique c'est pas une raison pour dire que le multitache n'existe pas, surtout si on accepte la def suivante:
 
   

TNZ a écrit a écrit : Un processus execute un programme (ou un interpréteur de commandes (shell/DCL/command.com)); ce processus possède un pointeur d'execution dans l'espace d'adressage mémoire qui lui est réservé.   Les threads sont des pointeurs d'execution, et quand un programme est executé dans un processus, si celui-ci est prévu pour du multi-thread, alors tu retrouves autant de pointeurs de programmes que de thread dans le même espace d'addressage mémoire, CàD dans le même programme avec les mêmes variables globales statistiques ou dynamiques, mais pas de variables locales dans la mesure où celles ci sont stockées sur la pile (SP) du thread.

 
Pareil, mais mieux dit (plus technique, quoi).
 
Au fait, que fait ce post ici, et pas dans Soft et réseau ?

Le multitache chez Crosoft c'est d'ouvrir une page explorer et en meme temps d'ouvrir un doc word

 
tu parles d'un multitache
 

 
bin au niveau de l'implémentation, un p4 hyper-threading maintient deux contextes cpu (registres, pointeur de pile, pointeur d'instruction), et répartit les instructions des ces 2 threads, sur toutes les unités disponibles....
 
je vois pas comment on pourrait être plus proche du traitement simultannée, tu peux très bien avoir un "add" du thread 1 dans une unité, et un "sub" du thread 2 dans une autre pendant le même cycle d'horloge...

[jfdsdjhfuetppo]--Message édité par bjone le 24-04-2002 à 15:11:11--[/jfdsdjhfuetppo]

 
Du point de vue du soft, oui !
Mais du point de vue du CPU, c'est jamais qu'une seule et même unité qui fonctionne deux fois plus vite, et donc fait croire aux autres qu'il y a deux unités. Ou alors j'ai rien compris ?

Comme le P4 est superscalaire et grâce à sa gestion Hyperthreadind, il peut executer deux threads reellement simultanément non ?
 

l'hyper-threading du p4, et l'implémentation de ses unitées (l'alu qui va 2 fois plus vite etc...), sont 2 choses séparées...

[jfdsdjhfuetppo]--Message édité par bjone le 24-04-2002 à 15:13:04--[/jfdsdjhfuetppo]

 
Presque pas tout à fait.
A priori, il va les exécuter l'un après l'autre, mais deux fois plus vite, donnant ainsi l'illusion qu'il le straite simultanément.

Sensation de déjà lu au sujet des Hammer d'AMD qui font croire à l'OS qu'il y a plusieurs procs ???  

Un truc simple pour voir les limites du multi-tâche : lancer une impréssion et en même temps un jeu 3D tout simple...

Bah oui mais je comprends pas alors;
un proc superscalaire peut executer plusieurs instructions simultanement reellement si j'ai bien compris.
Pourquoi l'hyperthreading ne permetrait pas de répartir les threads sur les pipelines disponibles ?
 

Ben là tu testes les limites de ton chipset en fait d