[Le saviez vous ?] Le MULTITACHE n'existe pas en réalité !

Recherche :

Sujet auquel vous répondez

Sujet : [Le saviez vous ?] Le MULTITACHE n'existe pas en réalité !

mrpochpoch

bjone a écrit a écrit :

quake3 gère le smp.... mais c'est pas du tout poussé....

sinon beaucoup de moteurs 3d pro (pour le militaire), essayent de tirer parti du parrallélisme multi-cpu, & gpu... (d'ailleurs le recouvrement cpu/gpu dans la 3d est un bonne idée d'optimisation), pendant qu'un cpu+gpu s'occupe du rendu, tu peux utiliser le deuxième cpu pour faire la physique+collision, ia... etc... etc...
enfin le problème c'est le partage des ressources (utilisation des données par un cpu, pendant que l'autre les modifies) et problème au niveau efficacité (cache cpu & verrouillage par sémaphore) et cohérence logique.

il est plus facile de faire du multi-threading en raytracing (3dsmax) qu'en 3d temps-réel...

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 ...

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

TNZ

Fodger a écrit a écrit :

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...

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

Nicool

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 ?

Shooter a écrit a écrit :

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.

fodger

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...

TNZ

nicool a écrit a écrit :

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

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

Shooter

nicool a écrit a écrit :

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

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.

bjone

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]

Nicool

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

bjone a écrit a écrit :

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 comment on peut ê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....

Shooter

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 ?

bjone

barbarella a écrit a écrit :

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.

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]

sheeva_23

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

tu parles d'un multitache

:lol:

Shooter

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. [:clarinette]

[:tnz]

Pareil, mais mieux dit (plus technique, quoi).

Au fait, que fait ce post ici, et pas dans Soft et réseau ?

Nicool

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:

Citation :

The ability to execute more than one task at the same time, a task being a program. The terms multitasking and multiprocessing are often used interchangeably, although multiprocessing sometimes implies that more than one CPU is involved.

In multitasking, only one CPU is involved, but it switches from one program to another so quickly that it gives the appearance of executing all of the programs at the same time.

There are two basic types of multitasking: preemptive and cooperative. In preemptive multitasking, the operating system parcels out CPU time slices to each program. In cooperative multitasking, each program can control the CPU for as long as it needs it. If a program is not using the CPU, however, it can allow another program to use it temporarily. OS/2, Windows 95, Windows NT, the Amiga operating system and UNIX use preemptive multitasking, whereas Microsoft Windows 3.x and the MultiFinder (for Macintosh computers) use cooperative multitasking.

TNZ

Tetedeiench a écrit a écrit :

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 ^^

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. [:clarinette]

[:tnz]

Shooter

Tetedeiench a écrit a écrit :

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 ^^

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...

bjone

nicool a écrit a écrit :

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

voilà, y'a plus qu'a lire ;)

fodger

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

Tetedeiench

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 :D

Shooter

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.

barbarella

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 :fou: :lol: ;)

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.

Marc	Je cherche toujours la ptite bete :)

Tetedeiench

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

Tetedeiench

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 ! :D

barbarella

Tetedeiench a écrit a écrit :

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 ^^

ç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 :D).

Tetedeiench

TNZ a écrit a écrit :

THREAD !!! :fou:

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 ^^

Tetedeiench

bjone a écrit a écrit :

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...

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 :fou: :lol: ;)

Vé le bannir tiens.

TNZ

Tetedeiench a écrit a écrit :

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 ^^

THREAD !!! :fou:

bjone

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 ! :jap:

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...

TNZ

[:rofl] MOUHAHAHAHAHA ........ j'en peux plus !!! [:rofl]

Question QUIZZ (Je connais les réponses ... ingé info industrielle [:clarinette] ) :

Quelle est la différence entre le parallélisme, le multi tache et le multi thread ??? :d:d: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 ?

bjone

Tetedeiench a écrit a écrit :

Donc ca reste bien un processus a la fois !

Il me semblait bien !

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...

popoles

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)

Tetedeiench

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 ^^

barbarella

Tetedeiench a écrit a écrit :

Donc ca reste bien un processus a la fois !

Il me semblait bien !

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 :)

Nicool

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

mrpochpoch

bjone a écrit a écrit :

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....

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

Tetedeiench

Donc ca reste bien un processus a la fois !

Il me semblait bien !

fodger

bjone

Tetedeiench a écrit a écrit :

Oui mais non j'y avais jamais trop pensé en fait...

Je m'étais laissé dans l'idée que les procos supercalaires faisaient pas deux calculs en meme temps mais plutot deux parties du meme calcul simultanéement, et pas deux calculs différents...

Donc j'avais, par extension, gardé dans l'idée que finalement y avait que ca revenaut au meme qu'une seule ALU mais version + rapide, mais a priori, je me suis foutu le doigt dans l'oeil...

Surtout que GT persuadé qu'il n'y avait qu'un seul bus interne !

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....

barbarella

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]

mrpochpoch

cycojesus a écrit a écrit :

De plus il ne me semble pas que tu puisse dédier un proc à une tâche (encodage) alors que l'autre fait autre chose (jeu)

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

Daryl

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

mrpochpoch

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 ...