Beaucoup de firmes font leurs annonces de produits futurs lors de ce salon et évoquent également les progrès technologiques envisageables à court terme.
Cette année IBM dévoile son Power6, Sun présente son Niagara 2, AMD annonce son futur processeur quad-core Barcelona, PA Semi, un nouvel entrant sur le marché, lance le PA6T. Intel de son coté propose un aperçu des futurs processeurs massivement multicores avec son démonstrateur 80 coeurs. Sur le haut de gamme IBM a toujours été un des leaders du marché et c'est pour conserver cette avance que Big Blue présente lors de cette édition de l'ISSCC son nouveau monstre, le Power6, déjà évoqué dans ce journal.
Celui-ci est un gros CPU de près de 800 millions de transistors avec gravure en 65 nanomètre. L'architecture est dual-core (avec en plus deux threads par coeur), 128 Ko de mémoire cache de niveau 1 et 4 Mo de niveau 2 par coeur. Il est possible d'adjoindre 32 Mo de L3 partagée.
La grande surprise de ce processeur est sa fréquence de fonctionnement qui sera aux alentours de 5 GHz. C'est la reprise de la course à la fréquence qu'avait abandonnée Intel il y a quelques années.
IBM a optimisé tous les recoins du circuit et a veillé à ce que l'enveloppe thermique reste raisonnable (100 Watts) en fractionnant son CPU en une multitude de zones pouvant travailler à des fréquences différentes.
Le site ArsTechnica présente brièvement ce CPU et le site RealWorld Techno analyse plus en profondeur l'architecture d'IBM.
Sun ayant fait sa révolution il y a deux ans avec sa puce Niagara, il était logique que la firme poursuive sur sa lancée et annonce son Niagara 2. Gravé en 65 nanomètre ses huit coeurs accueillent maintenant huit threads chacun ce qui fait qu'un seul processeur peut gérer 64 threads simultanés !
L'unité cryptographique est toujours présente (elle gère les RC4, AES, DES, 3DES, SHA-1 et le SHA-256) et il y a maintenant une unité à virgule flottante par coeur (alors que dans la génération précédente, il n'y en avait qu'une seule qui était partagée entre les 8 coeurs).
Ce processeur est extrêmement intégré (SiC ou System-on-Chip) puisqu'il comprend 4 contrôleurs mémoire (dual-channel FBDIMM), deux ports ethernet 10 gigabits et 8 ports PCIe sur la surface du CPU.
Encore une fois on peut lire une présentation simplifiée sur Arstechnica et une présentation détaillée sur RealWorld Techno.
AMD a été secoué par les performances du Core 2 Duo d'Intel et l'entreprise de Sunnyvale est bien décidée à reprendre le leadership avec l'architecture K8L. Son futur champion est connu sous le nom de code de Barcelona et sera un quad-core natif en 65 nanomètres avec, pour la première fois dans la gamme Opteron, un troisième niveau de cache mémoire. Sa grande force sera sa capacité de calcul en virgule flottante qui sera très fortement augmentée et sa capacité à s'intégrer dans des machine octo-processeurs en dialoguant par le bus Hypertransport (machines glueless).
Une analyse de l'architecture K8L est disponible ici.
Fondé par des anciens ingénieurs de Digital ayant travaillé sur les processeurs Alpha, la firme PA Semi a choisi de se consacrer au marché de l'embarqué avec des processeurs très puissants utilisant l'ISA PowerC. Leur premier produit, le PA6T, est assez surprenant puisqu'il propose un processeur double-coeur 64 bits cadencé à 2 GHz avec contrôleur mémoire intégré dans une enveloppe thermique de seulement 25 Watts (13 Watts en moyenne).
Ce nouveau CPU est assez innovant par son utilisation massive (plus de 25 000) des clock gates qui servent à réduire dynamiquement la fréquence de certaines parties du coeur et par son unité d'entrées/sorties entièrement reconfigurable.
Un long article est disponible ici sur le PA6T.
Enfin Intel, le géant du processeur, n'ayant pas de produit vraiment nouveau à annoncer lors de cette édition de ISSCC, a choisi de présenter un démonstrateur technologique de CPU 80 coeurs.
La problématique des processeurs multicoeurs du futur se situe dans l'accès à la mémoire. En effet, quand il y a plusieurs dizaines de coeurs qui réclament simultanément des nouvelles données, comment permettre des transferts ayant un débit suffisant ?
Intel a opté pour une solution radicale : superposer une puce multicoeurs et une puce mémoire pour fabriquer un microprocesseur intégré. Ainsi, il n'y aura plus besoin de bus mémoire (FSB) et les accès pourront se faire avec un débit et une vitesse maximum.
Pour expérimenter ce concept Intel a produit un CPU 80 coeurs capable de fournir une puissance de plus d'un teraflop. L'ISA x86 est provisoirement mise de côté pour ce démonstrateur qui utilise une architecture VLIW (comme l'Itanium) afin de minimiser le coût en transistor.
Aller plus loin
- La conférence ISSCC (1 clic)
- Le Power6 (1 clic)
- Le Niagara 2 (1 clic)
- Le Barcelona (2 clics)
- Le PA6T (1 clic)
- Le prototype Intel 80 coeurs (11 clics)
# Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Merci
Posté par Joël . Évalué à 7.
[^] # Re: Merci
Posté par Brice2Nice . Évalué à -10.
# VLIW
Posté par Neo_13 . Évalué à 1.
Je veux dire un compatible EPIC, ou une nouvelle architecture de développement ?
[^] # Re: VLIW
Posté par patrick_g (site web personnel) . Évalué à 6.
[^] # Re: VLIW
Posté par BAud (site web personnel) . Évalué à 2.
et en français^W anglais, sinon http://en.wikipedia.org/wiki/Very_long_instruction_word
et http://en.wikipedia.org/wiki/Explicitly_Parallel_Instruction(...) (ah si yen a un en français : http://fr.wikipedia.org/wiki/EPIC_%28informatique%29 )
# Bel article
Posté par farib . Évalué à 10.
Un volontaire qui s'y connait en processeurs pour ouvrir les hostilités et faire l'oracle, et nous dire lequel fera un Flop sans le Tera, lequel fera grille-pain, et lequel raflera le gros lot ?
[^] # Re: Bel article
Posté par CyrrusSmith (site web personnel) . Évalué à 5.
Et les DRM?
Il me semble que ce doit être un critère de choix. Il y a des fonction DRM das les puces intel, AMD, et IBM, et normalement pas dans les puces SUN.
La machine du vrai geek ne doit elle pas être avec un ou des processeurs sans DRM?
Et le projet de processeur libre dans tout ça?
[^] # Re: Bel article
Posté par B16F4RV4RD1N . Évalué à 6.
Et le reste (s'il en reste), pour démarrer un navigateur internet (comptez-en au moins 2 pour firefox 3) et aller se plaindre sur linuxfr :)
Sinon merci pour l'article bien détaillé (même si je n'ai pas tout compris), cela donne le tournis tout cela, à noter que le Niagara 1 est celui qui est passé en opensource il me semble :
http://en.wikipedia.org/wiki/OpenSPARC
Continuront-ils dans cette voie avec les nouveaux processeurs ? Est-ce que c'est "utile" pour le moment, et que cela a donné des choses intéressantes dans la voie de la conception de machines entièrement libres ?
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Bel article
Posté par reno . Évalué à 3.
A part pour ceux qui étudie le CPU, non: les chipset eux ne sont pas libres.
>et que cela a donné des choses intéressantes dans la voie de la conception de machines entièrement libres ?
Même réponse qu'au dessus.
[^] # Re: Bel article
Posté par B16F4RV4RD1N . Évalué à 3.
http://www.presence-pc.com/tests/Le-Hardware-Open-Source-112(...)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Bel article
Posté par Zenitram (site web personnel) . Évalué à 6.
Vais essayer de tuer le troll : c'est pas parce que la fonctionnalité est la qu'elle doit etre obligatoirement utilisée.
C'est comme les gens qui fustigent le HDMI et disent "pas de DRM chez moi", le HDMI permet de faire passer un flux crypté, cool, mais si tu n'a pas de flux crypté le HDMI marche aussi!
Bref, l'objet des dRM c'est plus le coté logiciel et contenu, pas CPU ;-)
[^] # Re: Bel article
Posté par hervé Couvelard . Évalué à 2.
je trouve qu'un char de l'armée dans mon jardin serait vachement cool comme terrain de jeux pour les enfants (oui je pars avec les clés la journée).
C'est parce qu'un ancien pédophile a été comdamné qu'il va récidiver. Une fois a dette payée, il n'y a pas de raison que tu ne puisse pas être instit.
ok, ok
[^] # Re: Bel article
Posté par reno . Évalué à 5.
-la capacité flottante amélioré des K8L (traitement des instructions SSE en 1 cycle) ne fait que rattraper ce qu'Intel a fait sur les processeurs Core il me semble, donc pas vraiment de quoi s'extasier.
-Le terme de 'coeur' pour le démonstrateur Intel avec ses 80 coeurs me parait potentiellement trompeur: ce n'est pas vraiment un CPU complet: il n'y a même pas d'unité pour faire des calculs entiers..
Bon il y a de la mémoire locale, des registres, mais c'est très différent d'un 'coeur' x86 normal.. Il faut trouver un meilleur terme: 'coeur simplifié dédié aux calculs flottant', c'est un peu long..
[^] # Re: Bel article
Posté par lasher . Évalué à 6.
[^] # Re: Bel article
Posté par Pol' uX (site web personnel) . Évalué à 5.
Les théories utilisées pour le développement d'applications de calcul distribuées sont adaptées à ce genre d'architecture.
Moralité, on n'optimise pas un programme pour ce truc, on le conçoit aux petits oignons ... c'est pour ça que tu n'est pas près d'en avoir un chez toi !
Adhérer à l'April, ça vous tente ?
[^] # Re: Bel article
Posté par lasher . Évalué à 4.
Alors, déjà, je suppose que tu voulais parler de grappes ( « clusters » ), parce que les grilles, c'est autre chose. Ensuite, je sais très bien à quoi sert une machine massivement parallèle, et comment on programme pour elle. Quant aux théories pour développer du calcul parallèle ou distribué sur ce genre de machines, je n'y crois pas un instant. Il existe des tas d'algorithme théoriquement géniaux, mais qui supposent qu'on peut avoir accès à tout un tas de mécanismes non moins géniaux (par exemple, lorsque tu effectues un calcul et que tu le parallélise, si tu as besoin de synchroniser une partie de tes calculs à chaque étape de l'algorithme, tu te retrouves avec un GROS goulot d'étranglement.)
De plus, le problème de la localité (utilisation des caches) et de la bande-passante mémoire devient critique dans ce genre d'architectures, et je me répète, très peu de personnes sont capables d'optimiser un programme pour ce genre d'architecture (et c'est aussi valable pour les gros clusters qui existent de ci de là).
Maintenant, si tu reprends ce que je dis, je faisais remarquer que même pour un 2 x 2 coeurs, c'était loin d'être évident.
[^] # Re: Bel article
Posté par Vincent Danjean . Évalué à 3.
Ça dépend de quoi tu parles. Si c'est du programme applicatif, celui qui fait les calculs (calculs d'écoulement de fluides autour d'une voiture ou d'un avion, calculs de propagation d'ondes, ...), alors généralement non. Le but de ces programmes (écrits par les grosses entreprises) est d'avoir un code qui tournera pendant 20 ans. Donc on ne l'optimise pas pour une architecture particulière. Mais on l'écrira de manière à ce qu'il puisse être parallélisé facilement/efficacement.
On l'écrira donc en utilisant des couches de portabilité sur des environnements plus ou moins standards et/ou libres comme MPI ou PM2 ( http://runtime.futurs.inria.fr/pm2/ ). Et ces environnement là seront effectivement optimisés pour l'architecture ciblée.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Bel article
Posté par reno . Évalué à 3.
Bin pour un serveur avec plein de clients, ce n'est pas compliqué..
Et ces processeurs 2*2 sont plutot prévus pour des serveurs.
Maintenant, paralleliser des jeux oui c'est tres compliqué, d'ailleurs tout ceux qui sont vendus a l'heure actuelle n'exploite pas du tout le parallélisme.
[^] # Re: Bel article
Posté par lasher . Évalué à 9.
Et ces processeurs 2*2 sont plutot prévus pour des serveurs. »
Euh, non. Des stations de travail avec deux processeurs comportant chacun deux coeurs, ça existe déjà, et ne sont clairement pas destinées à faire office de serveurs.
Le côté « serveur » de la chose existe à cause du prix qu'on constate maintenant, mais d'ici un an, lorsqu'Intel et AMD auront sorti leurs octo-coeurs, Apple et Dell proposeront très certainement dans leur catalogue des machines avec 4 coeurs (en fait, Dell en propose déjà).
Concernant les jeux vidéo, ça fait un bail que les programmeurs se posent la question de l'optimisation. Mais si pour un serveur, se contenter du fait que chaque coeur peut faire tourner un ensemble de threads indépendants est suffisant (et encore, ça dépend de l'application), pour les applications de tous les jours, c'est moins évident. Désormais, il va falloir apprendre à programmer correctement avec les threads, et franchement, il y a pas mal de gens dans l'industrie qui ne savent pas le faire efficacement (je ne parle même pas d'optimisation à ce stade).
Donc oui, la question de « comment va-t-on programmer efficacement sur ce genre d'architecture » me semble plutôt pertinente. Surtout si tu prends en compte certains effets « rigolos » qui peuvent se produire si on se retrouve avec une éviction des lignes de cache successives, due à une mauvaise exploitation de la localité dans les threads. Le système pourrait s'en trouver ralenti au lieu d'accéléré.
Bref. Je radote, j'arrête. :-)
[^] # Re: Bel article
Posté par Ontologia (site web personnel) . Évalué à 4.
Il faut trouver un modèle moins problématique que les thread.
Les thread c'est trop compliqué, c'est trop bas niveau, et faut pas rêver on aura jamais une majorité de programmeurs qui sauront maîtriser cette technique à la perfection ou tout au moins à bon niveau.
Comme c'est trop compliqué il faut proposer une couche d'abstraction, et refiler la difficulté au compilateur.
On a différent modèle pour cela, et un des plus intéressant est sans doute SCOOP(Simple Concurent Object Oriented Programming), qui est surement un bon départ à améliorer.
La meilleur description que j'en connais est une thèse de 100 pages, mais le principe général est expliqué au début :
http://cs.anu.edu.au/people/Richard.Walker/eiffel/scoop/mc-t(...)
En gros l'idée, c'est d'ajouter un mot clé au langage objet, en Eiffel, B. Meyer a choisi separate. Un objet separate voit son exécution parallélisé si son appel est non bloquant(ie pas de valeur de retour).
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Bel article
Posté par Vador Dark (site web personnel) . Évalué à 4.
Serait-il complexe de gérer la dépendance des instructions les unes aux autres?
Un simple arbre de dépendance du code ne permettrait-il pas au compillo de créer des genres de threads pour répartir le contenu d'une fonction ou d'un programme dans sa globalité entre plusieurs coeurs, en recherchant à avoir un minimum d'échange entre eux?
[^] # Re: Bel article
Posté par Joris Dedieu (site web personnel) . Évalué à 5.
Peut-on surtout imaginer qu'il en soit autrement ? Franchement, si l'utilisation correcte de la machine (je parle pas de trucs supers, juste le fait qu'il y ait plusieurs coeurs et qu'on les utilises), dépend des qualitées du programmeur, il risque d'y avoir des transitors qui choment.
Le problème étant bien sur d'avoir un nouveau modèle de programmation, compatible avec l'existant (la révolution c'est bien mais s'il faut tout réécrire personne ne changera sa façon de travailler) et qui soit intelligible par le programmeur de base.
[^] # Re: Bel article
Posté par Bruno Muller . Évalué à 1.
C'est pas encore complètement transparent, mais ça aide déjà beaucoup :)
[^] # Re: Bel article
Posté par lasher . Évalué à 3.
Les implémentations actuelles d'OpenMP sont relativement décevantes, notamment parce que pour des raisons « pratiques », plusieurs synchronisations sont effectuées même lorsqu'on pourrait s'en passer (sauf qu'il faut être humain pour le savoir :-) ).
Donc la parallélisation automatique, sauf dans des cas très précis, je n'y crois pas trop dans un avenir immédiat. Par contre, ajouter à des langages des primitives permettant de gérer correctement les threads serait clairement un plus.
[^] # Re: Bel article
Posté par Julien . Évalué à 1.
http://research.sun.com/projects/plrg/faq/index.html
http://en.wikipedia.org/wiki/Fortress_programming_language
[^] # Re: Bel article
Posté par Ontologia (site web personnel) . Évalué à 2.
Il faut expliquer très clairement au compilateur que là, le calcul est indépendant, mais que par contre 300 lignes plus loin, il faudrai attendre que ce soit fini, etc...
Soit tu prend un parti pris comme SCOOP ou en gros tu dis, si valeur de retour => bloquant et paralèlle sinon, ou sois tu crée toute une sémantique pour décrire avec précision ce que tu veux.
J'y pense, peut-être des pistes du côté d'Erlang ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Bel article
Posté par abramov_MS . Évalué à 2.
http://hpff.rice.edu/index.htm
Il me semblait que c'etait un peu fait pour et puis le fortran a beaucoup de defaut mais bon il a ete prevu pour faire du calcul a la base
[^] # Re: Bel article
Posté par Julien . Évalué à 1.
En fait, ils permettent surtout d'exploiter le parallélisme des boucles (au moins pour les 2 premiers très proches dans l'idée)
Parmis les 3 plus récent, j'aime beaucoup l'idée de Fortress : écrire un programme en langage mathématique ou presque et en extraire le parallélisme ensuite.
[^] # Re: Bel article
Posté par abramov_MS . Évalué à 2.
Ca fait pas un peu double emploie avec fortran + HPF?
[^] # Re: Bel article
Posté par Vincent Danjean . Évalué à 7.
La réponse est non si on veut que la parallélisation soit efficace.
Il y a eu beaucoup (BEAUCOUP) de travaux de recherche sur ce thème. Je ne connais pas une seule équipe qui soutient encore que la parallélisation peut être faite entièrement automatiquement.
Par contre, il est certain que le compilateur et/ou le runtime peuvent aider grandement le programmeur en lui fournissant des outils ou des analyses partielles. La plupart des travaux de recherche sur le parallélisme que je connais vont dans cette direction.
Un programmeur a trop l'habitude d'une exécution séquentielle et d'une mémoire partagée pour qu'un outil puisse extraire automatiquement une version parallèle efficace de son programme en respectant exactement la sémantique du code séquentiel. Dès que le programmeur commence à mettre des annotations (ie dans cette fonction, je ne touche pas à l'état globale, je me contente de lire sans écrire ces variables, ...), une parallélisation automatique devient beaucoup plus envisageable.
Le compilo restera très utile pour détecter le parallélisme au niveau instruction (et remplir correctement les différentes unités de calcul du processeur ciblé). Mais il ne sera pas capable de paralléliser efficacement sans aide un programme 'classique'.
[^] # Re: Bel article
Posté par Raphaël G. (site web personnel) . Évalué à 3.
- Y a-t-il des des documents concrets sur comment faire en C/C++ ce genre de chose ?
Je connais pas trop mal le système de thread (pthread), mais j'aimerais me perfectionner sur comment améliorer l'architecturage d'un programme, les choses a penser, les erreurs a éviter, etc...
[^] # Re: Bel article
Posté par M . Évalué à 2.
Il y a par exemple Athapascan (http://www-id.imag.fr/Logiciels/ath1/).
Bon courage :)
[^] # Re: Bel article
Posté par Vincent Danjean . Évalué à 2.
La référence officielle est désormais cette page :
http://kaapi.gforge.inria.fr/
[la page du site d'www-id sera bientôt une redirection là bas]
Une nouvelle release de kaapi devrait être faite d'ici quelques semaines.
L'idée de kaapi/athapascan est que le programmeur décrit les dépendances entre les fonctions/modules de son programme. Le runtime kaapi s'occupe ensuite tout seul de l'exécuter en parallèle sur la ou les machines à sa disposition. Évidemment, c'est destiner à paralléliser des programmes de calcul. Si on veut des affichages graphiques (ou tout autre E/S sur une machine particulière), ça marchera moins bien (kaapi ne pourra pas déporter ces parties du calcul). Et bien sûr, kaapi ne trouvera pas de parallélisme s'il n'y en a pas dans le programme (ie dans la description des dépendances entre tâches).
[^] # Re: Bel article
Posté par lasher . Évalué à 5.
Pour ce qui est d'architecturer une application multi-thread, je ne suis pas certain que tu aies besoin de bouquins si différents de ceux qui traitent d'algorithmique parallèle en règle générale, et des threads POSIX en particulier. Après, tout est histoire d'implémentation, et le fait est qu'entre celle de Sun et celle de Linux, il y a un monde. Donc même avec un programme portable (car utilisant les pthreads), les performances risquent de beaucoup varier (par exemple, sous Linux, un thread et un processus ne sont pas fondamentalement différents, alors que sous Solaris, qui implémente une bibliothèque hybride, si).
[^] # Re: Bel article
Posté par M . Évalué à 3.
Et ces processeurs 2*2 sont plutot prévus pour des serveurs.
C'est pas si evident que ca : il peut y avoir un goulet du niveau des IO. Par exemple 4 coeurs qui font des io que un meme disque...
[^] # Re: Bel article
Posté par Laurent GUERBY (site web personnel) . Évalué à 1.
Donc si si, ça peut servir :).
# Une petite faute de rien du tout dans l'article
Posté par pleiades . Évalué à 2.
# A quand une course à la puissance...
Posté par Drakho . Évalué à 7.
De mon côté, je me demande quand commencera la course à la puissance électrique, quand commenceront nous à ne plus courrir après les 10^n flops pour courrir après les composant les plus économiques sur le plan de l'énergie.
Nos ordinateur (je parle surtout des machines perso, mais c'est surement valable aussi au niveau des serveurs) consomment toujours plus, demandent toujours plus d'énergie.
L'énergie, c'est précieux, il me semble qu'il serait bon de l'économiser au mieux, en oriantant les recherche sur un nouvel axe...
Mais bon... c'est peut-être un peu utopique de ma part...
[^] # Re: A quand une course à la puissance...
Posté par Zenitram (site web personnel) . Évalué à 7.
Ca existe, donc tu peux choisir.
maintenant, faut que la population accepte la perte de performance, et ca c'est pas gagné...
(mon "serveur" a la maison est a base de Via C7, ca marche nickel. Mon serveur sur Internet est aussi avec du C7, ca permet a mon hebergeur de baisser les couts electriques, donc mes couts!)
[^] # Re: A quand une course à la puissance...
Posté par Drakho . Évalué à 6.
mais c'est rarement indiqué de façon claire sur le produit, c'est pas forcement facilement accessible (VIA uniquement accessible / commandable via le net, chez moi...)
Mais entre trois pékins qui consomment moins et toute une industrie qui change d'axe, il y a une différence...
Et, selon moi, la population accepte ce qu'on lui propose, ce qu'on lui avance, ce pour quoi on fait de la pub.
Si les commerciaux mettent la puissance de calcul en avant (il n'y a qu'a voir le parallel avec les appareils photos et le nombre de pixels), les consomateur suivront cette course avec la frénésie qu'on leur connait
Que l'axe de communication des équipes commerciales changent et le comportement des consomateurs changera lui aussi.
[^] # Re: A quand une course à la puissance...
Posté par lasher . Évalué à 3.
[^] # Re: A quand une course à la puissance...
Posté par blackshack . Évalué à 4.
[^] # Re: A quand une course à la puissance...
Posté par pasBill pasGates . Évalué à 3.
# Merci pour l'article et petite question ...
Posté par Émilien Kia (site web personnel) . Évalué à 3.
Juste une petite question pour un programmeur qui n'y connait rien sur le fonctionnement réel des procs : tout le monde dit que pour tirer avantage des procs multicoeurs il faut paralléliser le code, est-ce que ca veut dire qu'un proc double coeur ne peut exécuter qu'un programme à la fois (ce programme ayant 2 threads ?) ou est-ce qu'il peut exécuter plusieurs programmes différents en parallèle ?
Car si on peut exécuter plusieurs programmes en parallèles, je ne vois pas où est la polémique "paralléliser/pas paralléliser" car on a tous plusieurs dixaines de programmes qui tournent sur une machine donc un proc multi-coeurs va - de toute façon - accélérer le tout.
Un jour libre ?
[^] # Re: Merci pour l'article et petite question ...
Posté par Vincent Danjean . Évalué à 10.
Regarde bien l'occupation de ton processeur (il y a plein d'applets pour ça). Tu verras qu'il passe une très grande partie de son temps à ne rien faire. Tu as beau avoir plein de processus 'qui tournent', ces processus sont généralement en attente d'événements (clic, touche clavier, timer, ...) et ils n'ont alors pas besoin du processeur.
Et quand ton processeur est vraiment occupé, il n'y a généralement alors qu'un seul programme qui en a besoin à ce moment (par exemple gcc peut facilement occuper 100% du CPU). Et pour accélérer ce programme (et te faire l'impression que ta machine va plus vite), alors il faut que ce programme utilise des threads. Il y a rarement plusieurs programmes qui tournent (au sens utilisent vraiment le CPU) systématiquement en même temps.
L'exception la plus classique est le serveur X qui doit répondre en même temps que tes applications quand ces dernières ont des choses à faire. Dans ce cas, avoir deux CPU permet effectivement au noyau de répartir ces deux tâches (l'application et le serveur X). On aura alors l'impression d'une amélioration beaucoup plus grande entre le passage de 1 à 2 CPU que de 2 à 4.
Avoir des CPU supplémentaires peut aussi être utile si tu as des programmes en tâche de fond qui consomment vraiment du CPU (lecteur mp3/divx, encodage mp3/divx, indexation automatique des documents de ta machine, ...)
[^] # Re: Merci pour l'article et petite question ...
Posté par Émilien Kia (site web personnel) . Évalué à 1.
Un jour libre ?
[^] # Re: Merci pour l'article et petite question ...
Posté par Julien . Évalué à 4.
Tu as effectivement en général entre 50 et 100 processus qui tournent sur un PC de base (au bas mot).
Seulement ces processus n'utilisent pas, ou presque, le processeur. Par exemple crond qui est compté parmis ces processus passe son temps dans des sleep() il n'est donc schedulé au pire qu'une fois par minutes pour quelques millisecondes d'utilisation processeur.
Tu n'as en fait qu'un ou deux processus qui utilisent vraiment le processeur (cherche dans un top le nombre de processus qui dépassent les 1% d'utilisation processeur ...)
La question de la parallélisation se pose donc bien !
[^] # Re: Merci pour l'article et petite question ...
Posté par Thomas Pornin . Évalué à 4.
- "fil d'exécution" : c'est la suite d'instructions que le processeur parcourt et exécute en séquence.
- "espace d'adressage" : c'est la vision de la mémoire d'un processus.
Les espaces d'adressage des processus sont distincts, et chaque processus ne peut taper que dans le sien (sinon c'est segfault). On appelle "MMU" le morceau du processeur qui gère l'espace d'adressage (localisation en mémoire -- ou pas, en cas de swap ; droits d'accès ; etc). Il peut y avoir des morceaux de RAM communs entre plusieurs espaces d'adressage (mémoire partagée, comme on dit) mais la règle commune reste la séparation des espaces.
Un processus, c'est un espace d'adressage, et un certain nombre de fils d'exécution qui travaillent dans cet espace. Ces fils d'exécution, quand ils sont au moins deux, on les appelle des threads.
Dans un processeur multi-coeurs, chaque coeur peut gérer un espace d'adressage à la fois. Donc deux processus distincts peuvent tourner en parallèle, un sur chaque coeur. Chaque coeur peut en outre gérer plusieurs fils d'exécution plus ou moins en même temps (ce qu'Intel appelle "hyper-threading"), mais là c'est forcément dans le même espace d'adressage (la MMU de chaque coeur ne peut prendre en compte qu'un seul espace d'adressage à la fois), donc ces fils d'exécution ne peuvent être que des threads du même processus.
En bref, le multi-coeurs, on peut en profiter pour des processus distincts, mais pour l'hyper-threading, il faut des threads au sein d'un même processus. Les deux mécanismes sont proposés par les processeurs récents. Pour profiter à fond de ces processeurs, il faut avoir plusieurs threads, mais le multi-coeur aide déjà quand on a plusieurs processus indépendants.
[^] # Re: Merci pour l'article et petite question ...
Posté par lasher . Évalué à 3.
# Utile ? OUI!
Posté par ʭ ☯ . Évalué à 1.
Moi je suis béat devant mplayer qui me lit des DivX sur Pentium 133, mais ce n'est pas l'utilisation quotidienne réèele de l'informatique, sinon MS n'existerait pas.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Utile ? OUI!
Posté par lasher . Évalué à 3.
Et puis lorsqu'on parle d'optimisation, le « beau code » n'existe pas, justement parce qu'on optimise. Comme quoi hein.
[^] # Re: Utile ? OUI!
Posté par pasBill pasGates . Évalué à 4.
Ben justement si, t'aurais senti a peu pres exactement la meme chose, voire meme pire, parce que l'indexeur il bouffe principalement des I/O pas du CPU. Avec du multi-core si ca se trouve il aurait eu plus de temps CPU, donc plus de chances d'effectuer des I/O, augmentant la charge sur le HD, et tu te serais retrouve avec une machine qui semble plus lente.
[^] # Re: Utile ? OUI!
Posté par _alex . Évalué à 1.
[^] # Re: Utile ? OUI!
Posté par pasBill pasGates . Évalué à 2.
[^] # Re: Utile ? OUI!
Posté par Ph Husson (site web personnel) . Évalué à 1.
En mono processeur, mono coeur j'ai aucun problème quand un processus bouffe 100% du cpu....
À la limite quand ils commencent à être beaucoup à faire ca, ca bloque
Non moi ce qui me bloque vraiment c'est les E/S, et ionice est très efficace pour ca (mise à jour de ma distribution sans perturber le moins du monde amarok.) !
[^] # Re: Utile ? OUI!
Posté par darkleon (site web personnel) . Évalué à 2.
Je suis assez surpriss, parce que même avec le meilleur programmeur au monde, pour certaines tâches on a besoin d'une puissance CPU minimum pour fonctionner en temps réel.
Il me semblait qu'il fallait au moins ~400mhz sur un x86 (en puissance brute) pour décompresser du mpeg4 sans perte d'images en résolution DVD (~700x500). D'ailleurs c'est généralement le test qui est fait sur les CM VIA EPIA et elles ont du mal dans les plus basses fréquences.
De même que décompresser un mp3 en temps réel était impossible en dessous de ~60mhz lors de l'arrivé des premiers programmes (Il y a peut être des demos maker qui l'on fait à la mimine en ASM, mais bon).
Sur mon P233MMX, j'utilisais gogonacoda pour encoder les mp3 car c'est le seul qui marchait en "temps réel" (1h de musique->1h de compression). Et il était 3 à 10 fois plus rapide que les progs concurents sur la même machine.
On le voit bien au niveau des algo 3D, ce qui mettait plusieurs heures de calculs pour une image en gouraud ou phong sur mon amiga 500, maintenant je peux le voir en temps réel a plusieurs centaines de FPS sur une carte GFX de base.
[^] # Re: Utile ? OUI!
Posté par ʭ ☯ . Évalué à 1.
Bref, le multi-core sera très bien pour faire le DJ avec 32 lecteurs de musique simultanés. En fait, c'est peut-être le client léger X (ou FreeNX) qui va retrouver de l'intérêt pour un usage privé : une seule machine, utilisée en local pour les jeux, et à distance pour tout le reste.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.