Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Oui mais, le mec qui se sert de son PC 10 minutes pas jour pour surfer sur internet qu'est ce qu'il en a à faire que son processeur soit duo ou solo?
Alors attention, je vais peut être dire une grosse connerie, mais(je ne sais pas du tout) il n'y a pas une histoire de processus pouvant tourner en même temps avec les duo
salut,
tu parle de la notion multi-tâche, c'est autre chose. c'est pas vraiment le procsseur qui précise le fonctionnement mono ou multi tache, c'est plutot l'algorithme au noyau de l'OS.Envoyé par augustus
linux est multitache, et pas le cas de windows (à vérifier)
l'avantage de core duo est le largeur de bus de donnée qu'il peut manipuler. au lieux de 32bits au max sur un solo, tu peux travailler avec 64bits de largeur de bus avec un duo, à la fois. donc ya un gain de temps qui n'est pas lié à la fréquence ! c'est plutot à la capacité "volumique"
A+
Windows est bien sûr multitache. Multitâche veut juste dire qu'il peut faire plusieurs choses en même temps. Donc rien que le fait d'écouter de la musique en surfant sur internet, c'est du multitâche. Pas besoin de plusieurs processeurs pour cela. Bon en fait, c'est vrai que ce n'est pas fait en même temps mais de manière séquentielle, mais ca va tellement vite que c'est transparent pour l'utilisateur
Pour la petite histoire, le premier ordinateur multitache date de 1958, c'est tout dire
La question est plutôt de savoir comment est-ce que les systèmes d'exploitation gèrent le multi-tâche avec plusieurs processeurs. C'est à dire est-ce qu'il dispatche les différents threads sur différents processeurs ou pas. Pour ce qui est de Windows XP, je crois qu'il peut gérer 2 processeurs et les versions serveurs peuvent en gérer beaucoup plus.
Unix est monotache ?
@Blue_Strike
ben je pense que c'est cela juste ce que vous venez de dire .
Effectivement, deux cores = deux CPU = possibilité de faire réellement deux trucs complétement différents en même temps, comme faire un divx sur l'un et jouer à WoW sur l'autre. Le tout étant que l'OS le gère, évidemment.Alors attention, je vais peut être dire une grosse connerie, mais(je ne sais pas du tout) il n'y a pas une histoire de processus pouvant tourner en même temps avec les duo
N''importe quoitu parle de la notion multi-tâche, c'est autre chose. c'est pas vraiment le procsseur qui précise le fonctionnement mono ou multi tache, c'est plutot l'algorithme au noyau de l'OS.
linux est multitache, et pas le cas de windows (à vérifier)
l'avantage de core duo est le largeur de bus de donnée qu'il peut manipuler. au lieux de 32bits au max sur un solo, tu peux travailler avec 64bits de largeur de bus avec un duo, à la fois. donc ya un gain de temps qui n'est pas lié à la fréquence ! c'est plutot à la capacité "volumique"
A+. Mais alors totalement.
Comme dit, déjà, Windows ET Linux ET MacOS X ET n'importe quel autre OS moderne sont multitâches et peuvent donc faire tourner plusieurs programmes à la fois. Comme le CPU lui ne peut fair qu'une seule chose à la fois, le grand but de l'OS est d'allouer du temps CPU de la façon la plus optimale possible à chaque processus. L'intérêt premier du dual core est donc soit de faire en sorte que l'OS puisse allouer du temps CPU pour les deux cores et donc pour deux processus en même temps, soit que l'OS alloue du temps CPU des deux cores à la fois à un même processus qui lui, tirera parti du dual core en interne. C'est plutôt cette dernière voie qui est privilégiée.
Le fait d'être dual core est totalement indépendant de la taille de la représentation interne des entiers dans le CPU. 16, 32, 64 bits, c'est juste pour dire que dans le CPU, un entier sera représenté sur cette taille là en bits. Point. Derrière, on peut représenter des flottants avec des tailles différentes ou que sais-je encore, mais 64 bits indique juste que pour le CPU, un entier sera représenté sur ces 64 bits. Rien à voir, mais alors rien à voir avec la largeur du bus. D'ailleurs de quel bus ? Du FSB entre le processeur et le chipset ? Du bus entre le ou les coeurs et le cache ? Du bus entre le chipset et la carte graphique ?
Comme dit, dual core et 32 ou 64 bits n'ont aucun rapport. Sinon, les Athlon 64 seraient dual core depuis 2003. Il me semble que ce n'est le cas que depuis 18 mois environ. Même chose pour les Core 2 Duo, mais c'est un peu l'inverse, Intel a commencé par sortir les Core Duo dual core et 32 bits puis la nouvelle architecture Core 2 Duo s'est trouvée avec un jeu d'instruction EM64T rendant ces processeurs compatibles 64 bits. Et ô compatibilité, il se trouve que ça revient au même que le 64 bits d'AMD.
La notion de système d'exploitation "multitâche" est un peu dévoyée. En fait, on appelle multitâche un OS qui ne l'est pas forcément, puisque ce n'est qu'apparent. On a l'impression, du fait du time-slicing, que le système d'exploitation fait plusieurs choses en même temps, alors qu'il ne fait qu'alterner les processus.
Petite précision, je ne parle pas de multi taches mais bien de dual core, donc deux unités de calcul.
Pour le multi tache, le processeur va pouvoir faire des calculs pour des applications lancéesen meme temps, en passant sur chacune d'elle à tour de role. Windows possède ce genre d'outil sinon ca ferait longtemps que tout le monde serait sous Linux. Je pense que tu voulais dire que Windows ne pouvait pas gerer les deux coeurs ce qui est vrai pour les versions 95, 98 et Me. XP le fait parfaitement.
Pour le dual-core c'est différent on possède deux unités de calcul, donc peut faire tourner deux applications en meme temps, une unité de calcul pour une application et une unité pour l'autre. Le probleme je suis d'accord est que peu de logiciel permette de prendre les deux à la fois donc faire des calculs en paralleles. En bref ca tournera pas plus vite pour la plupart des applications mais ca ralentira moins quand une autre appli sera lancée. C'est pourquoi je te disais que pour moi le seul avantage du dual core était de pouvoir faire tourner deux applications en meme temps sans perte de vitesse...
a+
encore une petite chose,
La différences entre un bi-processeur et un dual core est l'acces mémoire. Sur un dual core il n'y a qu'un seul acces memoire partagé aux deux coeurs à l'inverse des multi-processeurs qui possède un acces memoire par processeur. C'est ce qui en fait leur limite et c'est pourquoi on ne peut pas dire qu'un dual core 1.4GHz équivaut à un monoprocesseur 2.8GHz.
Il y a aussi le fait que si un programme ou un OS n'est pas fait pour tirer partie du multicore, il ne fonctionnera que sur un seul core et donc verra ses performances égales à celles de l'architecture en question à la fréquence donnée pour un seul et unique core. D'où ralentissement.
Le multi tâche est gérer par tous les OS récents, est avec un processeur simple, le fait de gérer plusieurs choses à la fois n'est qu'une impression, l'OS accord 1/10 de secondes à un programme puis à un autre, etc... Ce qui donne l'impression de faire plusieurs choses en même temps.
Mais pour le dual, on peut faire deux choses VRAIMENT en même temps.
ce que je définissais comme time-slicing.
à condition que le système d'exploitation le gère...Mais pour le dual, on peut faire deux choses VRAIMENT en même temps
au final, je me demande quel système d'exploitation gère les duo ?
salut,
oki, reston sur l'exmeple d'un entier. Pour un Core Duo, un entier est répresenté sur 8 octets (64bits). si par exmple je réalise un petit programme (en C par exemple) qui additionne deux entiers A et B, ces deux valeurs lues au claviers arrivent au coeur depuis quel bus ?
en plus, si le resultat est calculé, il sera envoyé sur quel bus ?
si je possède une CG qui accèpte la configuration 64 bits dans ses paramètre, alors on parle de quel bus ?
donc tout l'environnement doit être bien adapté à la nouvelle configuration du 64bits, sinon comment va-t-on l'exploiter ???
(ne me dis pas qu'il calcule sous 64bits et envoie ses résultats sous 32bits !)
La notion de multitache est bien ancienne que le core duo et tout cette nouvelle technologie, déjà elle existe depuis longtemps avec des solo.. donc d'après toi, c'est quoi l'avantage principale du core duo sinon ?
Côté vitesse, le Duo est bien plus rapide q'un solo, ça n'accepete meme pas la discussion
A+
La logique veut qu'un duo soit plus rapide qu'un Solo....
A mon avis c'est une technologie qui vient juste de fleurir, il faut lui laisser le temps de s'épanouir et aussi le temps aux OS récents de gérer le multi coeurs pour en profiter plainement
vive le progès, vive la technologie
Tout ceux qui gèrent plusieurs CPU peuvent le faire. Donc les Windows NT et tous les Unix majeurs soit environ 98 % des OS utilisés. Après, on peut ergoter sur les OS embarqués genre VxWorks ou les trucs qu'on a dans les téléphones portables, mais c'est pas comme si c'était crucial de faire du parallèle sur ce genre d'équipement.
Sur un Core 2 Duo ou un Athlon 64, un entier n'est représenté sur 64 bits que si l'OS et les programmes qui tournent sont programmés et compilés pour tourner en 64 bits. Sinon, ça reste une architecture x86 standard donc en 32 bits. La notion de bus central et de communication peut être indépendante, la preuve, le bus HyperTransport des AMD 64 fonctionne en deux canaux de 32 bits montants et descendants. L'essentiel est après tout que le CPU et les autres composants retrouvent leurs petit une fois les données transférées.oki, reston sur l'exmeple d'un entier. Pour un Core Duo, un entier est répresenté sur 8 octets (64bits). si par exmple je réalise un petit programme (en C par exemple) qui additionne deux entiers A et B, ces deux valeurs lues au claviers arrivent au coeur depuis quel bus ?
en plus, si le resultat est calculé, il sera envoyé sur quel bus ?
si je possède une CG qui accèpte la configuration 64 bits dans ses paramètre, alors on parle de quel bus ?
donc tout l'environnement doit être bien adapté à la nouvelle configuration du 64bits, sinon comment va-t-on l'exploiter ???
(ne me dis pas qu'il calcule sous 64bits et envoie ses résultats sous 32bits !
La notion de multitache est bien ancienne que le core duo et tout cette nouvelle technologie, déjà elle existe depuis longtemps avec des solo.. donc d'après toi, c'est quoi l'avantage principale du core duo sinon ?
Côté vitesse, le Duo est bien plus rapide q'un solo, ça n'accepete meme pas la discussion
Le principal avantage de l'architecture Core 2 Duo, ce sont bien les modifications internes de l'architecture pour augmenter son efficacité et l'adapter au multicore en partageant le cache et le bus central. Mais c'est autant le fait d'être dual ou quad core que Intel se soit arrangé pour améliorer drastiquement son architecture qui fait la force. Je ne vois pas comment un Core 2 Duo à 2 GHz pourrait être plus rapide qu'un modèle mono Core ayant la même architecture à 2,4 GHz dans une application strictement monotâche et n'utilisant strictement qu'un seul core.
Je viens de lire un truc assez intéressant sur le sujet dans decision informatique de cette semaine. Il parle de parallèlisme implicite que détecte le compilateur. Ca permet de tirer deux threads du programme, qui seront executés sur deux cores. Il reste bien sur à améliorer les outils de compilations et aussi aux développeur de penser parallèlisme en écrivant mais le parallèlisme implicite pour un dual core est suffisant pour tirer profit des deux coeurs mais pas complètement optimisé. Bien sur la seule solution pour des quad core et plus est que le developpeur fasse le découpage lui même.
Pourquoi ? Le compilateur pourrait bien être parfaitement capable de détecter 4 coeurs d'exécution et les possibilités de parallélisme implicite pour adapter le programme aux 4 coeurs, non ?
et bien pas forcement, il donne un exemple je te le donne :
ca c'est le code non optimisé pour le parallèlisme. Ton compilateur va détécté le parallèlisme implicite. Il n'en tirera que deux threads
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9#INCLUDE<IOSTREAM> USING NAMESPACE STD; INT MAIN() { COUT<<"MIKE IS DEAD"<<ENDL; RETURN 0; }
ici c'est le code optimisé avec OpenMP. En ayant explicité son parallèlisme, il a déclaré quelle partie de son code étaient indépendantes. Le compilateurs va ensuite trouvé du parallèlisme implicite. Le parallèlisme explicite vient s'ajouter au parallèlisme implicite pour donner 4 threads pour que les 4 coeurs soient exploité.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18#INCLUDE<OMP.H> #INCLUDE<STDIO.H> INT MAIN(INT ARGC, CHAR *ARGV[]){ INT ID, NTHREADS; #PRAGMA OMP PARALLEL PRIVATE(ID) { ID = OMP_GET_THREAD_NUM(); PRINTF("MIKE IS DEAD FROM THREAD %D\N,ID); #PRAGMA OMP BARRIER IF(ID==0){ NTHREADS = OMP_GET_NUM_THREADS(); PRINTF("THERE ARE %D THREADS\N", NTHREADS); } } RETURN 0; }
Apres j'imagine que pour des applications plus complexe il peut renvoyer beaucoup plus de threads mais le probleme restera le meme il y aura à un moment donné des coeurs non exploité par le programme alors qu'ils pourraient l'etre. Les développeurs de demain seront donc amenés à programmer en pensant au parallèlisme.
Ha ok, je pensais à l'optimisation faite par le compilateur, sinon, je suis d'accord, les développeurs vont devoir penser en paralléle. Et on va bien s'amuser d'ailleurs, avec toutes ces histoires de synchronisation et tout des données pour débugguer...
Moui, ça va être marrant
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager