Reprise du message précédent :

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

le p4 en hyper-threading "entrelace" dans ses unités les instructions de 2 threads.... je pense que tu peux avoir deux instructions de chaque thread qui s'éxécutent dans le même cycle d'horloge....

 
c'est peut-etre parceque le spool a une priorité très élevée, alors qu'un jeu a une priorité normale ...
 
Donc au lieu d'avoir une execution équitable de chaque process par cycle d'horloge cpu, on a 10 cycles d'horloges cpu alloués au spool, et un seul alloué au jeu ...
 
CQFD.

Ben dans Win:vomi: les priorités sont trop basiques ... (soupir de nostalgie) AHHHHHHHHH les 32 niveaux de priorité (16 time sharing & 16 real time) des OpenVMS !!!

 
Ca c'est le discours d'intel , mais si tu penses en terme de pipeline, certaines parties sont dupliquées d'autres non. Ensuite tu peux répartir les taches pour optimiser, mais ceci n'est pas une fonctionnalité propre de l'hyperpipeline, C'est une amélioration indirecte de la gestion non-ordonnée des instructions. Je crois que j'avais un graphique la-dessus, faut que je le retrouve, mais pour l'instant je suis en train de me battre avec mes écrans dès que le fight est fini je regarde ou il est ...

 
Ha....
Les 255 niveaux de priorités de pSOS....
Vive les noyaux temps-réels !!!

mrpochpoch » Ah toi aussi VMS Addicted ??? d

Et pis merde j'arrive pu à me souvenir combien y'en avait dans iRMX !!!  
 
Mé dans VAX/ELN ... CT 32 en pur real time, mé du vrai de vrai, ca pouvait interrompre des écritures sur les terminaux ... du velu koi !!! d

TNZ a écrit a écrit : mrpochpoch » Ah toi aussi VMS Addicted ??? d

 
non ... mais ça à l'air bien !!  

Moua j'abandonne ^^

slyde a écrit a écrit :     Ca c'est vite dit

 
il n'y a rien de tel que les systemes centraux, avec accès par terminaux !! ( Gecos, ...)  
 
D'ailleurs, on y revient avec CITRIX !

c'est pas ça, mais certains périphériques concus comme des merdes, ou datant des années 80 sont pensés pour du mono-tâche, avec le polling comme résultante...
 
si un driver doit passer son temps à scruter (=polling) l'état du périphérique qu'il dirige, les performances globales s'écroulent, et du rendement est perdu....
 
un lecteur de disquette, ça fonctionne quasiment que par polling, ce qui fait qu'un lecteur de disquette prends plus de temps cpu que n'importe quel autre périphérique (:D).....
 
idem, les ports joysticks à l'ancienne mode (avant le directinput par exemple, qui permet une implémentation souple du port joystick pour le fabricant), peuvent entrainer un blocage cpu dû au polling du driver....
 
que ce soit un driver sous windows ou sous unix/linux, la scrutation est la pire chose qui puisse arriver au multi-tâche, une perte de rendement monumentale....
 
(d'ailleurs l'écran bleu "INFINITE LOOP" sous 2K/Xp, est la marque d'une scrutation qui est parti en vrille)
 
vive les IRQs, vive l'i/o apic, vive les mecs qui savent faire des drivers....
 
heureusement, les périphériques et leur drivers sont actuellement pensé avec le multi-tâche en tête, et un fonctionnement bloquant le cpu un minimum....

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

mrpochpoch a écrit a écrit : non ... mais ça à l'air bien !!

Poses la question à des vieux de l'info qui ont connu ce genre de bécane ... CT le pied à gérer. Tous dans les outils, un vrai éditeur de fichier (type emacs) ... un reboot tous les 6 à 9 mois pour s'assurer que les procs de boot fonctionnent encore ... le rêve koi.
 
Coté programmation, CT pareil ... les appels système pouvait être snchronisés ou pas (autant en écriture qu'en lecture sur les périphériques) ... et ce n'est que quelques exemples, sinon j'fais 15 pages d

C'est excellent CITRIX!  
les besoins en bande passante sont impressionants!
 

 
impressionnants ?
 
pour accéder à des bases de données distantes avec Business Objects par exemple, vaut mieux passer par Citrix ! En terme de bande passante, y a pas photos !!

Par impressionant je voulais dire que ct vraiment peu gourmand!
 

mrpochpoch a écrit a écrit :     impressionnants ?   pour accéder à des bases de données distantes avec Business Objects par exemple, vaut mieux passer par Citrix ! En terme de bande passante, y a pas photos !!

barbarella a écrit a écrit :     Ca c'est le discours d'intel , mais si tu penses en terme de pipeline, certaines parties sont dupliquées d'autres non. Ensuite tu peux répartir les taches pour optimiser, mais ceci n'est pas une fonctionnalité propre de l'hyperpipeline, C'est une amélioration indirecte de la gestion non-ordonnée des instructions. Je crois que j'avais un graphique la-dessus, faut que je le retrouve, mais pour l'instant je suis en train de me battre avec mes écrans dès que le fight est fini je regarde ou il est ...

 
le rapid execution engine mes couilles, et l'hyperpipeline mon cul ( ) n'ont rien à voir avec l'hyper-threading !!!!!
 
c'est des noms donnés à leur implémentation des pipelines du p4.
c'est purement marketing.
 
l'hyper-threading (même si le nom est marketting) n'a rien à voir avec l'architecture du "hyper" p4, ça pourrait être appliqué à l'athlon ou au ppro/p2/p3....
 
je pense que l'hyper-threading consiste surtout au niveau de l'unité d'éclatement/répartion des instructions + de l'unité de réorganisation des résultats propres aux architectures out-of-order, à une prise en considération de 2 contextes....

bjone a écrit a écrit :     le rapid execution engine mes couilles, et l'hyperpipeline mon cul ( ) n'ont rien à voir avec l'hyper-threading !!!!!   c'est des noms donnés à leur implémentation des pipelines du p4. c'est purement marketing.   l'hyper-threading (même si le nom est marketting) n'a rien à voir avec l'architecture du "hyper" p4, ça pourrait être appliqué à l'athlon ou au ppro/p2/p3....   je pense que l'hyper-threading consiste surtout au niveau de l'unité d'éclatement/répartion des instructions + de l'unité de réorganisation des résultats propres aux architectures out-of-order, à une prise en considération de 2 contextes....

 
Bon, les gars, vous savez quoi ? vous m'avez convaincu.
 
 
 
 
 
 
 
 
 
 
 
 
Je vais m'acheter un dico
 
nan sérieux, je capte, mais bordel, parlez francois de temps en temps !

C'est toi qui a commencé
 
 

Tetedeiench a écrit a écrit :     Bon, les gars, vous savez quoi ? vous m'avez convaincu.                         Je vais m'acheter un dico   nan sérieux, je capte, mais bordel, parlez francois de temps en temps !

 
Ak ... ok !    
 
Effectivement, il faut à peu près 12Kb/s de bande passante par connexion ! c'est à dire qu'on peut utiliser un modem 14.4 sur un 386, et travailler sur du Office2000, ou faire des requetes B.O sur des bases de données de plusieurs Giga ...
 
Par contre, il faut des put... de machines comme serveurs Citrix pour accépter toutes les connexions ( plusieurs CPU par serveur, beaucoup de Ram ... 15Mo par connexion supplémentaire, ...)  

nicool a écrit a écrit : C'est toi qui a commencé

 
Cai vrai et je vais me flageller a coup d'orties trempés dans de la glue, mélangée avec du goudron, des clous rouillés et des pointes...²

TNZ a écrit a écrit : 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 ?

Ya personne ki a osé répondre aux questions !!!

Quelle est la différence entre le parallélisme, le multi tache et le multi thread ???  
Faut que je réflechisse
 
Comment s'appelle le parallélisme sur un monoproc ?
Superscaling?
 
Quelle est la différence entre le préemptif et le non-préemptif ?
Preemtif: L'OS distribue des parts de temps cpu aux différents programmes.
Non preemptif (cooperatif ?): Le programme qui tourne au premier plan contrôle le cpu aussi longtemps qu'il en a besoin.  
 
Les OS multi proc, gérent ils des process ou des threads ?
Des threads ?
 
 
J'ai tout faux ? Je veux le corrigé !

[jfdsdjhfuetppo]--Message édité par nicool le 24-04-2002 à 15:57:36--[/jfdsdjhfuetppo]

bjone a écrit a écrit :     le rapid execution engine mes couilles, et l'hyperpipeline mon cul ( ) n'ont rien à voir avec l'hyper-threading !!!!!   c'est des noms donnés à leur implémentation des pipelines du p4. c'est purement marketing.   l'hyper-threading (même si le nom est marketting) n'a rien à voir avec l'architecture du "hyper" p4, ça pourrait être appliqué à l'athlon ou au ppro/p2/p3....   je pense que l'hyper-threading consiste surtout au niveau de l'unité d'éclatement/répartion des instructions + de l'unité de réorganisation des résultats propres aux architectures out-of-order, à une prise en considération de 2 contextes....

 
ouais, je me suis planté en ce moment a chaque fois que je veux écrire hyperthreating j'écris hyper-pipeline, j'sais pas pourquoi.  
 
c'est hyperthreating que je veux dire. Corrige en conséquence
 
PS : j'avais encore confondu hyper-p et hyper-t en écrivant ça, décidement ...

Quelle est la différence entre le parallélisme, le multi tache et le multi thread ???  
Faut que je réflechisse
Je te laisse réfléchir paskeu la réponse est longue d:d
 
Comment s'appelle le parallélisme sur un monoproc ?
Superscaling?
Semi-parallélisme (tétra-capiloculture)
 
Quelle est la différence entre le préemptif et le non-préemptif ?
Preemtif: L'OS distribue des parts de temps cpu aux différents programmes.
Non preemptif (cooperatif ?): Le programme qui tourne au premier plan contrôle le cpu aussi longtemps qu'il en a besoin.  
Bien
 
Les OS multi proc, gérent ils des process ou des threads ?
Des threads ?
Bien
 
 
J'ai tout faux ? Je veux le corrigé !

 
C'est simplement parce que le port parallèle possède un IRQ matériel (le 7), au même titre de que la carte graphique (souvent 10), et donc il interpelle le proc dès que néccessaire et va dialoguer à tour de rôle avec les périphériques actifs...

hébé y en a eu des bêtises écrites !
 
je vais donner mon avis sur tout ca :
 
* préemptif : le noyau de l'OS est le seul maitre à bord et c'est lui qui attribue le proco à une tache pendant un court délai, chacun son tour
 
* coopératif (windows 3.11) : plusieurs tâches en mémoire, mais chacune prend le controle et le rend quand bon lui semble
 
* processus : programme chargé en mémoire en 2 parties : zone instruction (que le pointeur d'exécution parcourt, zone données : l'OS garantit que seul ce processus aura accès à cette zone mémoire) => processus isolés les uns des autres
 
* thread : même chose que processus sauf que : 1 processus = 1 ou plusieurs thread : ces threads "frères" partagent le même espace mémoire aux yeux de l'OS) => threads "frères" peuvent plus facilement communiquer
 
 
 
Techniquement, on dit qu'un système est multi-tâche à partir du moment où à un instant donné, plusieurs tâches sont lancées ( comprendre par : en mémoire, en cours d'éxécution, ...) mais cela ne signifie pas que chaque tâche a une unité de calcul dédiée !
 
Hyperthreading : à ce que je sais, c'est simplement faire voir à l'OS votre processeur comme 2 processeurs : apparemment cela augmente les performances quand l'OS croit k'il y a 2 procos plutot que de lui meme assurer la répartition de la charge.

TNZ a écrit a écrit : Ya personne ki a osé répondre aux questions !!!

 
j'avais po vu.... (j'ai vu les têtes qui roulaient)
 
bin le "parallélisme" tout court, c'est trop vague, le multi-tâche c'est comme l'a dit tetede, faire du basculement de tâche (process/thread), le multi-thread c'est quand l'ordonnanceur du noyau préemptif se base sur le thread comme unité de contexte...
 
je dirais que par définition (et comprendre la différence process/thread) un process c'est une entité qui englobe un ou plusieurs threads dans le même espace mémoire...
 
un process inclus de manière sous-entendue un thread pour l'ordonnanceur d'un point de vue phylosophie... (mais l'ordonnanceur s'occupant du basculement de contexte le fera plus rapidement pour un thread qu'un process)
 
chaque thread a son propre contexte (registres+pile), mais tous les threads du même process partagent le même espace mêmoire, et l'espace mémoire de chaque process sont isolés à l'aide du mmu (qui sert à d'autres choses en passant).
 
le parallelisme sur un mono-proc, plus précis pliz (niveau os, ou niveau isntruction ?)
 
le multi-tâche préemptif c'est quand c'est le noyau qui bascule les tâches (thread/process), le coopératif (celui de windows 3 et des vieux macos) c'est les applications (je dit même pas process) qui décrétent quand est-ce qu'elle peuvent rendre la main aux autres apps.
 
les os multi-cpu gérent les deux.... (je pense)
 
enfin je sais pas si c'est ce qu'il attendait...

bon bin, la boucle est bouclée mr l'ingé info-indus

d
 
Au moins les choses sont claires now et pis comme ça on évitera les questions dûes aux mis-understanding des lectures diagonales des curieux de passages désirant s'informer.
 
Et pis si ca peut servir de lexique ........ d

vous me dites ce que vous en pensez, mais ce serai bien de faire une extension aux calculs parrallèles, non pas sur une même machine, qu'elle soit mono ou multi-processeurs, mais au contraire sur de multiples machines, au travers d'un réseau ... comme peut l'être le SETI ou le Décrypthon ...
 
 
Qui connait exactement comment ça fonctionne ?  

mrpochpoch a écrit a écrit : vous me dites ce que vous en pensez, mais ce serai bien de faire une extension aux calculs parrallèles, non pas sur une même machine, qu'elle soit mono ou multi-processeurs, mais au contraire sur de multiples machines, au travers d'un réseau ... comme peut l'être le SETI ou le Décrypthon ...     Qui connait exactement comment ça fonctionne ?

 
Clustering !
On pouvait déjà le faire avec 3DS Max sous Win 95.

jme couchere moins con ce soir  

par contre pour éclaircir l'hyper-threading, un chti lien:
 
http://developer.intel.com/technol [...] _modes.htm
 
en fait y'aura 2 modes lorsque l'hypertreading sera activé...
le MT: les deux cpu logiques (lire contextes) se partagent les ressources cpu, mode hyper-threading par défaut.
le ST0/ST1: un seul des cpu logiques reprends tout les ressources (ça reviens à avoir l'hyper-threading désactivé)
 
Tu peux donc avoir une applis spécialement optimisée P4, qui a été compilée en vue de profiter des ressources du cpu, et de contourner ses défauts, qui fonctionne donc en mode ST, pleine ressource.
Et pour des applis plus "standard" qui n'ont pas spécialement leur flux d'instruction ciblée pour le p4, tu seras en mode MT (ou deux threads vont s'entrelaçer dans les pipelines )

[jfdsdjhfuetppo]--Message édité par bjone le 24-04-2002 à 16:31:06--[/jfdsdjhfuetppo]

c'est normal qu'apres avoir Lu tout le topic j'ai une multi-migraine ?  
 
Ou alors j'ai pas tout compris et c'est un Hyper -mal de crane...  

bjone a écrit a écrit : par contre pour éclaircir l'hyper-threading, un chti lien:   http://developer.intel.com/technol [...] _modes.htm   en fait y'aura 2 modes lorsque l'hypertreading sera activé... le MT: les deux cpu logiques (lire contextes) se partagent les ressources cpu, mode hyper-threading par défaut. le ST0/ST1: un seul des cpu logiques reprends tout les ressources (ça reviens à avoir l'hyper-threading désactivé)   tu peux donc avoir une applis spécialement optimisée P4, qui a été compilée en vue de profiter des ressources du cpu, et des contourner ces défauts, qui fonctionne en mode ST, pleine ressource, et pour des applis plus "standard" qui n'ont pas spécialement leur flux d'instruction ciblée pour le p4, tu seras en mode MT (ou deux threads vont s'entrelaçer dans les pipelines )

 
Un truc qui était vraiment sympa, c'était que le 486 DX était déjà un proc avec pipeline (1 seul pour les virgules fixes, je crois). Et que donc il profitait déjà des améliorations des compilos prévus pour les PPro et Pentium.

tout ça c'est de la saloperie.com  

entier, ou virgule flottante...
 
De la virgule fixe c'est une considération spéciale des calculs en entier oû on considère qu'il existe une partie fractionnaire....

sebast62 a écrit a écrit : tout ça c'est de la saloperie.com

 
est ce que le SCHMILBLICK ... fait du multithreading ???

http://developer.intel.com/technol [...] ecture.htm
 
j'avais même po vu, les cpu logiques ont leur propre APIC (virtuel ?)....
forcément fo que l'os croie être en smp....