Intel ou AMD ?

à priori, il faut surtout que l'os soit prevu pour, c'est lui qui gère çà, comme Win2000 pro, win NT4, xp pro et familiale,beos, linux... c'est quasi-transparent pour les soft, sauf quelque-uns comme 3ds max, AE, bryce, j'en oublies beaucoup, avec ces soft, on peut activer l'option "multi-treading" (plusieurs VRAI processeurs ) mais avec l"hyper treading" il a quelques problèmes... puisque ces soft sont ralenti...
...l'utilisation la plus efficace de l'"hyper-treading" est la même que pour le multi-treading, c'est-à-dire l'utilisation de plusieurs soft en même temps, sinon, le gain est quasi nul...

 

il faut bien sur un OS capable de reconnaitre plusieurs CPU pour pouvoir activer le multi-threading mais il faut surtout des softs programmés pour et capable d'envoyer deux threads simultanément. et gare à celles et ceux qui voudraient utiliser plusieurs applications en même temps, c.a.d en tirer un max de son CPU: Intel a mis en garde contre le fait que "l'apport de cette technologie est d'autant plus faible que le taux d'utilisation processeur est grand". ils ont même indiqué que les perfs pouvaient chuter de 17%!!!!! no comment...
dans l'avenir espérons que les applications seront développées autour de threads et non plus autour de processus (qui sont composés de threads).

 

Encore un peu de vaseline

No more comment...

 

alors là, moi y'a pas comprendre! qu'est-ce qui t'empêche de lancer plusieurs soft en même temps ? même sur un pc equipé d'un seul processeur ?
c'est l'os qui gere la repartition de charge (plus ou moins bien). sur mon bi- pIII, tant que je lance pas une deuxieme application, le proc n°2 (le 1 en realité, le premier etant le "0") reste à 0 en activité, il ne s' agite que lorsque je lance un autre application ou une application seule, mais capable par elle-même d'envoyer plusieurs threads à la fois (AE, 3DS, vue d'esprit...). en fait, ces logiciels font croire à l'os qu'il y en a plusieurs en mulitipliant les threads, l'os les gère comme si il y avait plusieurs soft.
c'est pour ça que quand tu as un seul proc et que dans ces soft, tu actives le multi-threading, il ne se passe rien, L'os, qui est par defaut un multi-tâche "prehemptif" fait faire la queue à tous ces threads avec un systeme de priorité geré avec des "jetons", c'est ni plus rapide ni plus lent qu'en activant pas l'option multi-threading.
...sauf si tu as un proc avec l'HYper-threading, là c'est plus lent.. car la charge n'est pas optimisée.

par contre, fais attention de ne pas confondre threads, processus et handles, il n'y a que très peu de rapport entre les trois...

 

je n'ai jamais dit qu'on ne pouvait pas lancer plusieurs applis (processus) en même temps...Intel dit juste que dans le cas d'une surcharge du CPU un seul thread peut être traité à la fois. mais tu peux avoir autant de processus en attente que ton système peut en supporter.
le bi-cpu est fondamentalement différent de l'hyper-threading de par le fait que les données utilisent le même pipeline. et c'est le point noir des PIV...

l'hyper-threading marche bien dans le cas d'applis de synthèse d'image car ces applis, ou processus, sont parrallelisables. mais bon ça marcherait mieux si le soft interrogeait directement le CPU à l'aide de threads. là toutes les applis serait parrallelisable (avec un PIV hyper-threading bien sur!)

je sais que le thread est une séquence d'éxecution au sein d'un processus (par exemple le correcteur orhtographique au sein de word).

mais quid des handles? là il faut m'éclairer, je ne les ai pas retouvés dans mes cours d'IUT...

 

ben voilà une explication, j'éspère qu'elle est comprehensible..





Les "Handles" comme les "processus", sont vraiment spécifique à l'environnement windows, on retrouve ces termes sur d'autres OS, mais ils ont alors une signification bien différente, ce qui peut porter à confusion... Donc, dans mon explication, il ne faut pas perdre de vue qu'on suppose être sous environnement windows, sans extension possible à d'autres OS:

Pour le coup, l'explication est très simple, plus que pour les "thread" :
___________________________________________________
PROCESSUS
___________________________________________________

Un processus, c'est un générateur de "thread", ça peut être un programme simple, comme un programme complexe qui peut alors générer plusieurs processus. D'ailleurs, il y a fort à parier qu'un soft programmé en vue du MP ou du HP (multi/hyper threading) génère plusieurs processus...
Un bon exemple: les anti-virus et firewall genèrent un grand nombre de processus, qui sont d'ailleurs prompt à ralentir un système de façon mesurable.
Dans le cas d'un TSR (programme résident style "drivers" ou "gestionnaire d'interruption") le programme est terminé mais son ou ses processus restent actif aussi longtemps que le même programme ne vient pas les supprimer, seul windows peut les supprimer de lui-même en cas d'erreur ou de demande par l'utilisateur:

Programme
|
|
V
un ou plusieurs processus
|
|
V
un ou plusieurs thread

Pourquoi avoir intercalé des processus entre les programmes et les threads ? C'est une notion assez récente, qui n'existait pas sous environnement 13 bits, il y a quelques années. C'est ce qui a permis à windows de devenir multitâche "prehemptif" et limiter les crashs système à chaque erreur dûe à un programme.
C'est pour ça que c'est spécifique à windows, si vous entendez parlez de "processus" sous un autre OS, ça n'aura sûrement la même signification...
__________________________________________________
HANDLE:
__________________________________________________

Là aussi, spécifique à windows quoique existant sous d'autres OS utilisants les systèmes de fichiers FAT 16 / 32 / NTFS.
Le concept du "handle" est très simple, un programme se lance et a besoin pour ses fonctions de 2 ou 3 librairies de type ".Dll" et 2 ou 3 fichiers graphiques comme des ".bmp" ou des ".gif", le programme génère autant de handles que de fichiers nécessaires à son fonctionnement tout simplement parce-ce que deux programmes ne peuvent pas acceder à un fichier en même temps. C'est comme une "reservation", pour eviter que d'autres programmes accèdent par megarde à ces fichiers et génèrent un erreur dans le meilleurs, voir un crash dans le cas d'un fichier système.

Le fait que windows ne permette pas à deux programmes d'acceder à un même fichier simultanéement pose des gros problèmes de performance donc une parade a été trouvé par le devellopeurs windows, la création de fichiers "fantômes", c'est à dire la copie d'un fichier demandé dans la mémoire: un programme "demande" un handle sur 10 fichiers pour s'éxécuter, windows, si il le peut va générer 10 fichiers "fantôme" dans la RAM et générer de lui-même 10 nouveaux handles de telle manière qu'un autre programme pourra quand même utiliser ces même 10 fichiers sur le disque ou à nouveau dans la RAM sous forme de fantômes supplementaire (déjà 30 handles generés !).

Windows lui-même est un énorme générateur de handles car chaque icone (puisque c'est fichier) est également un handles, la barre des tâche, chaque fenêtre, chaque élément graphique de windows suceptible d'être modifiable est un handles et réside sur le disque ou dans la RAM du PC...

Autre sens du terme:
Un "handle" en terme de programmation bas niveau (asm / C++) est un mode d'adressage des fichiers au DOS ou à windows, elle co-existe avec une autre méthode appelé "FCB".


Trophy.

 

ça s'éclaircit du côté des handles. par contre la frontière entre programme et processus devient un peu floue.

pour moi : programme=processus=".exe"

 

Un programme peut engendrer plusieurs processus, je reprends mon exemple avec un anti-virus:

le programmes principal va sûrement generer un processus different pour chacune des tâche suivantes:

-affichage dans la barre des tâches d'un icone avec un menu en cas de clique souris

-surveillance des accès reseau aux fichiers.

- surveillance des peripheriques de stockages amovibles (zip, disquettes, cartes mémoire..)

-surveillance du fichier d'échange windows et des fichiers en mémoire (handles)

Afin d'être multi-tâche et utilisé en tant que tel par windows, le programme principal génère plusieurs processus independant les un des autres, l'activation du menu de l'anti-virus dans la barre des tâches ne suspends pas la surveillance des accès reseau ou des disques amovibles et réciproquement. C'est un peu le fondement des la stratégie de sécurité de windows, c'est également sa grande faiblesses. Un seul programme ou processus defaillant ne peut bloquer le système (en théorie), mais pour une personne très mal intentionée, les failles sont multiples (on atteint un autre domaine, je m'arrête là !).

Toutefois, un programme simple de quelques lignes en basic ne possède bien evidemment q'un seul processus sauf si ils font appel à une librairie exterieure pour être interprètable par windows (encore les fameuse .Dll).

Pour résumer l'ensemble les termes decrits (thread, processus, handles), lorsqu'on parle de programmation, un programmeur peut definir et programmer des processus à volonté au sein d'un programme, ça relève de son niveau, alors que les thread sont gérés par la machine (même pas par windows). Avec l'arrivé de la technologie hyper-threading, un jeu d'instruction nouveau (IA-32) permet au programmeur de definir lui-même ses thread, afin de permettre une imbrication maximum des instructions dans le processeur (instruction engine) et donc de permettre une acceleration maximum par cette technologie.

comme tu le dis toi-même certains logiciels de création graphique ou 3D s'y prêtent à merveille mais l'integration de telles instructions dans le coeur même d'un programme relève du travail de fourmi, c'est pour ça que les mise-à-jours et patches tardent à arriver, il est parfois nécessaire de repenser entièrement le code du logiciel...
... ce qui me laisse à penser que si les editeurs ne jouent pas le jeu, l'hyper-threading sera mort-né au profit du Dual-processing, gère plus coûteux...

 

pour comprendre,avec Win XP, appuyez sur Ctrl+Alt+Suppr et observez ceci en allant sur l'onglet performance:

(dans mon cas)

Handles: 7051
Threads: 338
Processus: 31 (visibles sur l'onglet "processus")

Et pourtant, seulement 3 applications qui tournent:

IE (cette reponse au forum que j'ecris !!!)
Outlook (réduit dans la barre de tâche)
et un logiciel lié à mon modem (sagem fast800 de chez free)

ces trois programmes ne sont pas seuls responsables des 31 processus et 7051 handles, Windows y est responsable à 90 %...

 

très instructif ce petit échange! ç'est plus clair et ça remet les choses à leur place.

en tout cas en attendant la mise en place de l'HP2 (prévu pour bientôt) on peut effectivement se poser la question de l'intérêt de l'HP1?!

un peu comme le SATA1 (150MB/s théorique) depuis que le JEDEC a enterriné les normes du SATA2 (SATA 300MB/s je crois)

 

Ditres donc les enfants ça va booster du 300 MB/s !

 

300MB/s (ou Mo/s c'est la même chose mais pas les Mb/s) ce n'est que de la théorie et c'est une bande passante max. quand on voit la norme IDE 133MB/s qui a du mal à assurer du 25Mo/s au mieux de bande passante moyenne on se dit qu'il ferait mieux d'améliorer l'existant puisque ce dernier est vraiment mal exploité!
et puis il va falloir qu'il nous invente un bus de données capable de transiter les données à cette vitesse. pour info (je persiste et signe) l'actuel SATA150 passe par le bus du PCI qui est limité à 133Mo/s. néanmoins les tests ont montré qu'avec des disques dur SATA150 en 5400tr/min on dépassait le taux de transfert des meilleurs disques durs IDE133...comme quoi quand ils veulent ils peuvent faire de bonnes choses mais pour en profiter il faut des ports SATA

businness quand tu nous tiens...

 

comme tu le dis, avec un ata 133 qui plafonne en réalité à 25-30 Mo/s, j'aimerais voir les disques qui vont pouvoir "cracher" du 150 ou 300 Mo/, pour moi, en plus, il n'y a aucun interêt, je bosse en DV soit 4Mo/s max...

Pearl propose les carte contrôleurs Serial ATA 150 ainsi que des Modules à mettre au cul d'un disque IDE pour le brancher en Seriel ATA, un peu comme les modules qui permettent de brancher n'importe quel disque IDE en Firewire...
...pour ceux que ça interresse, perso, je pense qu'il vaut bien mieux passer au RAID en mode stripping, c'est bien plus efficace et moins cher...

 

Peux-tu préciser Nico ?

GiLd

 

Le jour où nous serons à la norme HD, on sera bien content d'avoir de gros DD et des taux de transfert de données élevés. La HD prend du retard. Qu'est ce qu'ils attendent pour nous innonder. Le marché du camescope est pourtant saturé, non ? (tout au 2nd degré. On ne sait jamais) :lol:

Bob