Le 6 juin 2005, lors de la conférence mondiale des développeurs, Steve Jobs lançait une nouvelle grosse transition pour Apple en confirmant certaines rumeurs: fini le PowerPC, les futurs Macs embarqueront dorénavant des processeurs Intel. C'est chose fait depuis le début de l'année avec l'arrivée des nouveaux iMac, du MacBook Pro puis du renouvellement du Mac Mini. L'occasion pour chacun de s'adonner à toutes sortes de comparaisons entre les derniers G4 ou G5 et les nouveaux Core Duo d'Intel des nouvelles machines. Lequel est le plus puissant? Pourquoi nous avoir toujours dit que le PowerPC était le meilleur et passer aujourd'hui à "l'ennemi" Intel?
Mon but aujourd'hui n'est pas de répondre à ces questions, mais plutôt d'apporter les éléments nécessaires afin d'y parvenir. Je voudrais en effet vous parler de ce qu'est et de ce que fait un processeur. Il s'agit d'un article relativement technique et assez long, mais j'espère ne pas effrayer trop de monde! Je ne suis moi-même pas spécialiste dans le domaine, et je remercie grandement Eduardo Sanchez, professeur à l'EPFL et à la HEIG-VD, qui m'a permis de m'inspirer de ses cours pour rédiger cet article.
Architecture d'un processeur
Le processeur, ou CPU, pour Central Processing Unit signifiant en français unité centrale de traitement, réalise les opérations de traitement des données. Il est donc en quelque sorte le cerveau de la machine. Celui-ci communique avec la mémoire afin de traiter les données, ce transfert étant assuré par un ensemble de lignes d'interconnexion appelé bus.
Un bus est donc un ensemble de lignes physiques par lesquelles sont envoyées les données. Le nombre de ces lignes donne le volume d'informations transmises simultanément, appelé largeur du bus. Il faut savoir qu'une information est exprimée en bits, abréviation de binary digit en anglais, autrement dit des 0 ou des 1, traduits électroniquement par un voltage proche de zéro pour le 0 et une plage de voltage plus élevé pour le 1. Un ensemble de 32 fils permet ainsi de transmettre 32 bits en parallèle. La vitesse du bus est aussi définie par sa fréquence, c'est-à-dire le nombre de paquets de données envoyés ou reçus par seconde. Le débit maximal du bus sera donc donné en multipliant sa largeur par sa fréquence.
On rencontre généralement deux bus principaux sur un ordinateur:
- le bus système, par l'intermédiaire duquel le processeur est capable de lire ou d'écrire une donnée dans la mémoire, tâche essentielle comme nous le verrons par la suite
- le bus d'extension, qui permet aux divers composants de la carte mère de communiquer entre eux et qui nous intéresse donc moins ici
Regardons maintenant le processeur de plus près. Nous constatons que celui-ci peut être divisé en deux parties distinctes:
- l'unité de traitement, qui est un ensemble d'opérateurs arithmétiques et logiques groupés autour d'une ou plusieurs unités arithmétiques et logiques justement appelées ALU (Arithmetic and Logic Unit)
- l'unité de contrôle, qui coordonne les différentes activités du processeur
Nous avons vu que le processeur est capable de communiquer avec la mémoire, cependant le transfert n'est pas optimal du point de vue de la vitesse. La solution consiste donc à inclure à proximité du processeur un type de mémoire rapide appelé mémoire cache et d'y stocker temporairement les principales données devant être traitées par le processeur, ce qui permet de réduire les délais d'attente des informations stockées en mémoire vive. De plus, le processeur possède ses propres unités de stockage d'information appelées registres, moins nombreuses que la mémoire mais par contre beaucoup plus rapides.
Le processeur, avec ses deux unités séparées, relié par le bus à la mémoire principale.
Le langage machine
Généralement, les logiciels qu'emploie un utilisateur sont programmés en ce que l'on appelle des langages de haut niveau; vous avez peut-être entendu parler de C, C++ ou Java par exemple. Un langage de haut niveau est à mettre en opposition avec un langage de bas niveau, ou langage machine.
Voyons donc ce que tout cela signifie. Comme nous l'avons observé pour le bus, un processeur doit reconnaître des instructions codifiées sous la forme de bits, une instruction étant l'opération élémentaire que le processeur peut accomplir. L'ensemble de ces instructions, stockées dans la mémoire principale, et son système de codage forment justement le langage machine, ou assembleur. Vous imaginez bien qu'il n'est pas simple pour un développeur d'écrire un programme avec un tel langage, où le simple fait d'additionner deux nombres demande plusieurs instructions. C'est donc là qu'interviennent les langages de haut niveau, qui ont un niveau d'abstraction plus élevé que le langage machine dialoguant directement avec le processeur. Afin d'être compris et exécuté par le processeur, un programme écrit en langage de haut niveau est traduit en langage machine lors de la phase de compilation. Je n'irai pas plus loin dans les détails puisque ce n'est pas ce qui nous intéresse le plus ici.
Le processeur doit avoir un répertoire d'instructions, à savoir l'ensemble des instructions machine, qui lui permettent de réaliser n'importe quel traitement d'information. Autrement dit, le répertoire d'instructions d'un processeur doit être capable d'interpréter toute instruction d'un langage de haut niveau.
Les processeurs ne possèdent pas tous le même langage machine. Ainsi, on distingue plusieurs familles de processeurs possédant chacun un jeu d'instruction qui leur est propre:
- Motorola 68000
- PowerPC
- x86
- Sparc
- MIPS
- etc…
Apple utilisa pour le premier Mac 128K un processeur Motorola 68000. Le 68040 fut le dernier modèle de la lignée avant le passage en 1994 au PowerPC d'IBM et Motorola avant d'amorcer cette année la transition vers des processeurs x86 d'Intel. Pour les personnes qui se demandent ce que désigne exactement la famille x86, il s'agit en fait d'une famille de processeurs compatibles avec le jeu d'instructions du processeur 80086 d'Intel.
De même, on distingue plusieurs types de processeurs selon la complexité de leur langage machine, dont les deux plus courants sont:
- les processeurs CISC (Complex Instruction Set Computer), tel que le Pentium
- les processeurs RISC (Reduced Instruction Set Computer), comme le PowerPC ou le Sparc
Avec l'architecture CISC, les instructions sont très complexes et nombreuses dans le but d'effectuer une tâche avec le minimum d'instructions. Nous verrons plus tard que ces instructions nécessitent de nombreuses impulsions d'horloge pour être traitées. L'architecture RISC, plus récente, vise à simplifier grandement le décodage d’instructions et de traitement en réduisant le nombre d'instructions tout en optimisant leur décodage.
A l'origine de conception CISC, les nouvelles générations de processeurs ont été de plus en plus conçues comme des processeurs RISC. Il en ressort que cette distinction n'est pas toujours évidente et parfois quelque peu ambigüe. C'est le cas du Pentium 4, qui est perçu de l'extérieur comme un processeur CISC, mais qui fonctionne en fait intérieurement comme une architecture RISC.
L'exécution d'une tâche
L'exécution d'une tâche, aussi simple soit-elle, implique une série d'opérations réalisées dans l'unité de traitement et coordonnées par l'unité de contrôle, grâce à des transferts de données entre la mémoire et le processeur.
Pour une meilleure compréhension, prenons comme exemple l'addition de deux nombres (5+3=8), opération relativement simple. Celle-ci pourrait se faire en cinq étapes utilisant plusieurs instructions:
- chercher le premier nombre (5) dans la mémoire et le placer dans un registre du processeur
- chercher le deuxième nombre (3) dans la mémoire et le placer dans un autre registre
- activer l’additionneur (opération +) avec les deux registres précédents comme sources (5 et 3) puis stocker le résultat (8) dans un registre
- sauver ce résultat dans la mémoire
- arrêter
N'ayez crainte si cela vous paraît quelque peu compliqué, l'idée est de comprendre comment agit un processeur d'une manière générale. Celui-ci va chercher les éléments dont il a besoin dans la mémoire, les place dans des registres, plus rapides, puis il effectue le traitement de ces informations pour finalement renvoyer le résultat final dans la mémoire.
Pour exécuter un programme, l’unité de contrôle du processeur doit lire chaque instruction, la décoder puis finalement l’exécuter. Ce cycle exécuté en trois phases (appelées fetch-decode-execute en anglais) est réalisé continuellement par un processeur. En général, l’exécution de chaque phase de l’instruction demande au moins un cycle d’horloge. Cependant, la phase exécutée demande parfois plus d'un cycle suivant la complexité de l'instruction, comme pour une instruction de division par exemple, qui a besoin de plusieurs dizaines de cycles.
Le cycle d'horloge
Le processeur est cadencé au rythme d'une horloge interne grâce à un cristal de quartz. Un cycle pourrait être comparé à une impulsion, ou un "top" d'horloge, c'est-à-dire le laps de temps durant lequel une instruction subira une opération dans l'unité de calcul.
La vitesse d'un cycle d'horloge est une donnée que tout le monde connaît puisqu'il s'agit en fait de cela dont on parle lorsque l'on dit qu'un ordinateur tourne à 2 GigaHertz. Pour être exact, 2Ghz correspond en fait à la fréquence d'horloge, soit au nombre de cycles par seconde, qui est donc de 2 milliards dans ce cas.
Depuis de nombreuses années, le processeur est soumis à "la guerre du Ghz", une course à la puissance de calcul vue comme la voie principale permettant d'améliorer les performances et considérée comme l'argument commercial de choix. Celle-ci tend pourtant à disparaître, les constructeurs étant confrontés à des contraintes d'ordre physique au niveau des procédés de fabrication ainsi que d'une consommation de courant, et donc une dissipation thermique, toujours plus élevée. La diminution de consommation est en effet devenue cruciale quand on sait que, pour la première fois, le marché des portables a dépassé celui des ordinateurs de bureau aux Etats-Unis. C'est ainsi qu'est apparu le performance per Watt, le nouveau critère de mesure si cher à Steve Jobs, qui quantifie la puissance de calcul relative à la puissance électrique consommée.
Comparer différents processeurs
Il n'y a en fait pas vraiment de sens à comparer les performances de deux processeurs en prenant en compte seulement les vitesses. En effet, pour des familles de processeurs différentes, la quantité de travail effectuée en un cycle peut être très différente. Comme nous l'avons vu, effectuer peu d'instructions complexes requiert de nombreux cycles d'horloge, ce qui n'est pas le cas avec une jeu d'instructions plus simples et mieux optimisées.
C'est exactement l'exemple que nous avions lorsque l'on comparait nos processeurs Mac avec ceux des PC, à savoir des PowerPC face à des Pentium ou Celeron d'Intel et des Athlon d'AMD. Certes les G4 et G5 paraissaient bien lents par rapport au Pentium en terme de fréquence d'horloge, mais ces processeurs ne faisant pas partie de la même famille, il était totalement faux de les comparer sur ce seul critère. Apple s'est d'ailleurs toujours servie de cette différence d'architecture à titre commercial, fière de ne pas faire comme tout le monde. C'est entre autre pour cette même raison que certains spécialistes considèrent le PowerPC comme beaucoup plus "élégant" que le Pentium, processeur devenu de plus en plus complexe et ce même aux yeux d'Intel.
D'ailleurs, après plusieurs années de développement et plusieurs millions investis dans le développement du Pentium V, celui-ci fut abandonné à cause de la nouvelle complexité du circuit qui augmentait considérablement la consommation de puissance pour un gain négligeable en performance. Suite à cet échec, la marque a choisi de revoir complètement l'architecture de ses nouveaux processeurs pour repartir sur de bonnes bases en s'attaquant désormais au fameux performance per Watt. On remarque au passage que les processeurs Core Duo (nom de code Yonah) des nouvelles machines sont cadencés à une fréquence plus lente que les Pentium pour une vitesse d'exécution pourtant bien plus rapide.
Plutôt que de comparer la vitesse d'horloge, il est donc plus réaliste de mesurer la performance d'un processeur en comparant les temps d'exécution pour un même programme. Les programmes utilisés pour calculer ces mesures sont appelés benchmarks. Il en existe plusieurs, mais l'ensemble le plus utilisé commercialement est le SPEC (Standard Performance Evaluation Corporation). Afin de vous faire une petite idée des résultats que l'on peut trouver, voici une comparaison de différents processeurs effectuée sur des programmes séquentiels (qui ne tiennent pas compte du parallélisme, dont nous parlerons plus tard). Pour plus d'explications sur la signification de ces chiffres, je vous laisse consulter le site de SPEC.
Comparaison de différents processeurs d'après le SPEC.
Le temps d'exécution dépend de trois facteurs: le nombre d'instructions machines exécutées, le nombre moyen de cycles d'horloge par instruction machine et la fréquence d'horloge. Le calcul est donc le suivant:
Améliorer les performances d'un processeur
Pour une architecture donnée, il existe trois moyens différents pour améliorer la performance:
- augmenter la fréquence d’horloge
- améliorer l’organisation interne pour diminuer le nombre d'impulsions d'horloge par instruction
- améliorer le compilateur pour diminuer le nombre d'instructions ou pour augmenter le taux d’utilisation des instructions avec un nombre d'impulsions d'horloge par instruction moindre
Par l'équation précédente, nous constatons que les processeurs CISC augmentent leur puissance de calcul en minimisant le nombre d'instructions nécessaires à l'accomplissement d'une tâche alors que les processeurs RISC minimisent le nombre d'impulsions d'horloge requis pour chaque instruction.
Une des possibilités utilisée par l'architecture RISC est d’optimiser le traitement de chaque instruction et de s’assurer qu’une instruction soit terminée à chaque coup d’horloge grâce à l'utilisation d'un pipeline. Dans un processeur sans pipeline, l’exécution d’une instruction ne commence pas avant la fin d’exécution de l’instruction précédente, ce qui revient à dire que toutes les instructions sont mises à la suite l'une de l'autre.
Sans pipeline, une nouvelle instruction n'est exécutée qu'après la fin de l'instruction précédente.
Au contraire, l'utilisation d'un pipeline permet qu'à la fin de chaque phase (souvenez-vous du FEtch-DEcode-EXecute) l'exécution d'une nouvelle instruction démarre. Le gain de rapidité semble ici évident; à t+5, seules deux instructions ont été exécutées sans l'utilisation d'un pipeline alors que quatre l'ont été avec un pipeline.
En utilisant un pipeline, ne nouvelle instruction démarre dès la fin de la phase précédente.
Nous pourrions voir le pipeline comme un premier pas vers le parallélisme, même si ce n'est pas le cas. Le parallélisme, vu désormais comme la meilleure solution pour augmenter la performance, consiste à exécuter simultanément des instructions relatives à un même programme. Nous parvenons à obtenir un vrai parallélisme en utilisant plusieurs unités de traitement, avec des architectures multi-processeurs ou multi-coeurs ainsi qu'avec le hyper-threading.
Dans une architecture multi-processeurs, il s'agit de placer plusieurs processeurs indépendants fonctionnant en parallèle et permettant ainsi de partager les tâches. Apple le fait depuis plusieurs années maintenant avec ses machines bi-processeurs.
Si un ordinateur multi-processeurs contient plusieurs processeurs distincts, avec une architecture multi-coeurs nous avons un unique processeur, mais celui-ci contient finalement plusieurs processeurs, c'est-à-dire plusieurs unités de calcul. C'est le cas des processeurs Yonah Core Duo utilisés par Apple ou des derniers G5 embarqué dans le PowerMac G5 Quad, qui contient deux processeurs bi-cores, incluant donc les deux technologies.
Quant au hyper-threading, il permet au système de reconnaître plusieurs processeurs logiques au sein d'un unique processeur physique. Chaque unité virtuelle est dotée de ses propres registres de données et de contrôle, mais les unités logiques partagent les autres ressources du processeur (mémoires caches, unités de traitement et de contrôle, bus système). On parle de parallélisme interne au processeur dans le cas du multi-threading et de parallélisme externe avec les multi-coeurs.
Je ne vais pas expliquer toutes les possibilités d'améliorations possibles, l'article étant déjà assez long et compliqué comme ça, mais je voudrais vous parler rapidement encore de deux technologies vantées par Apple: Velocity Engine et le passage au 64 bits.
Sur les processeurs G4 et G5, Apple et IBM ont en effet ajouté une technologie nommée Altivec, appelée Velocity Engine par Apple en terme de marketing, qui constitue en un jeu d'instructions supplémentaires permettant d'accélérer les tâches graphiques et sonores ainsi que du système d'exploitation.
Quant au fait de passer d'un processeur 32 bits à 64 bits, Apple l'illustre par cette image: imaginez que le traitement 32 bits est un verre d'eau et le 64 bits les chutes du Niagara. Le G5, 64 bits, exécute alors des nombres beaucoup plus grands dans un même cycle d'horloge pour les effets vidéo, calculs scientifiques et 3D.
Si vous désirez en apprendre plus sur ces technologies et sur le PowerPC G5 utilisé par les derniers PowerMac, je vous invite à consulter ces explications d'Apple.
L'optimisation des logiciels
S'il est bien joli d'avoir plusieurs processeurs, encore faut-il qu'ils soient employés d'une manière efficace! Pour en profiter, il faudra tout d'abord que le système d'exploitation reconnaisse et gère correctement tous les processeurs et qu'un programme soit écrit de telle manière à les utiliser efficacement. Cela se traduit par le découpage d'un programme en plusieurs processus traités en parallèle afin de gagner en temps d'exécution.
Cette première constatations nous montre une première chose: le fait d'avoir deux processeurs sur une machine ne la rendra pas deux fois plus rapide pour autant. Pour avoir un réel gain, il faut optimiser la partie software. Certains logiciels ne valent pas la peine d'être optimisés, soit parce qu'ils n'utilisent de toute façon pas beaucoup le processeur, soit parce qu'ils ne s'y portent pas bien. Nous pourrions citer comme exemple Mail ou Safari. D'autres par contre ont un net avantage à être optimisés. C'est le cas par exemple de Photoshop ou Final Cut, des programmes qui demandent beaucoup de ressources processeur.
L'exemple de l'utilisation de multi-processeurs est un exemple flagrant d'optimisation logicielle à apporter, mais cela peut être généralisé pour beaucoup de technologies permettant d'augmenter la performance d'un processeur.
Conclusion
Il n'est pas si simple de comparer différents processeurs. D'une part la technologie avance très vite et les techniques changent. D'autre part, le simple fait d'avoir du matériel ultra-puissant ne fait pas tout, encore faut-il que la couche logicielle en profite et soit optimisée.
C'est sans doute sur ce point que le bât blesse, d'où de nombreuses comparaisons sur les différences d'exécution pour un même programme entre différentes machines. L'arrivée de Boot Camp ne fait qu'alimenter ces discussions, maintenant que la comparaison avec Windows est devenue possible sur une même machine.
Il faut également soulever le fait que certaines applications multi-plateformes sont développées à la base pour un système d'exploitation (souvent Windows en l'occurrence), puis traduites pour d'autres systèmes ensuite. Il n'est pas rare dans ce cas que l'application tourne mieux sur le système de base, car tout simplement mieux optimisée pour celui-ci.
Avant de croire sans broncher le langage marketing des patrons d'entreprise, il est important de prendre en compte l'ensemble des éléments pour se faire une idée réelle sur le sujet. J'espère vous en avoir donné les moyens en ce qui concerne les processeurs. Histoire de dissiper vos doutes…
, le 18.05.2006 à 01:57
Merci pour le raffraichissement des idées et l’efficacité de votre vulgarisation sur les processeurs. J’arrive presque à comprendre ce sujet si technique.
Une de mes nombreuses questions : faut – il une bonne machine bien conçue techniquement (processeur et cartes + design) ou une mauvaise machine, très mal conçue avec des programmes optimisés ?
Yves qui ne rate pas une journée de cuk.
, le 18.05.2006 à 05:57
Pour reprendre ta dernière ligne, pas sûr que cet excellent article (j’ai presque tout compris, c’est dire, même si je coince un peu dès autour de l’équation du milieu, mais bon, même là ça passe:-)) dissipe les doutes qui sont linkés!
Visiblement, les doutes d’ivmak ne sont pas tout à fait dissipés non plus:-)
Merci 6ix.
, le 18.05.2006 à 06:16
Remarquable article ! Moi qui suit « du batiment », je ne vois pas un mot à retrancher..
Citation de Ivmak :
faut – il une bonne machine bien conçue techniquement (processeur et cartes + design) ou une mauvaise machine, très mal conçue avec des programmes optimisés ?
Bonne question, qui, pour y apporter une réponse, soulève elle même d’autres questions. En effet, selon la nature du traitement attendu, la qualité du processeur est plus ou moins importante. 6ix en parle fort bien dans son article. Si un programme doit traiter les unes après les autres des données stockées dans un fichier sur disque (on parle alors de « batch » ou traitement par lots), il est clair que le temps de traitement sera grandement conditionné par la capacité du disque (je simplifie) à fournir suffisamment vite les données pour que le processeur n’attende pas. Donc, vaste question dont la réponse est grandement dépendante du type de traitement que le programme doit réaliser…
, le 18.05.2006 à 07:16
Moi je trouve cet article très bien. C’est insructif et tout et tout. Bravo
, le 18.05.2006 à 07:22
ben ça alors! Je crois que j’ai compris!!!!
merci 6ix pour cet article qui éclaire cette réalité compliquée que sont les processeurs.
, le 18.05.2006 à 08:56
ah oui, bravo ! ces notions qui trottaient dans mon esprit depuis quelques années se sont enfin arrangées d’une manière logique et cohérente dans mon esprit… merci encore !
, le 18.05.2006 à 09:12
Bel article !
Par contre, il y a un point qui mériterai d’être éclairci :
L’avantage du 64 bits, ce n’est pas d’améliorer les performances !
Le principal avantage, c’est que on peut utiliser beaucoup plus de mémoire : avec un proc 32 bits, on est limité à 4Go (avec quelques bidouilles, on peu délacer cette limite à 4Go par programme).
Avec du 64 bits … disons juste que la limite est très très loin (plusieurs milliers de To ..).
A part ça, ca permet aussi de gérer des nombres entiers très grands ou des nombres non-entiers très preçis.
Mais ça n’améliore pas les performance du processeur !
Au final, pour un particulier … l’interêt est limité. Ce n’est donc pas un grand drame si l’imac est repassé à 32 bits.
Mais bon, tout ça c’est du détail :-)
Merci 6ix
, le 18.05.2006 à 09:20
Merci à 6ix pour son article.
J’ai enfin compris la différence, et par là l’utilité, entre les processeurs CISC et RISC.
Une question me reste toutefois à l’esprit : Puisque la limite est parfois floue entre CISC et RISC, ne devrait-on pas pouvoir quantifier le nombre d’instructions et placer sur une échelle les processeurs afin de relativiser l’argument de vente GHz ?
(à moins que ça existe … je suis pas spécialiste)
Gaël
La planète est le bien le plus précieux que nous lèguons à nos enfants.
Gaël
, le 18.05.2006 à 09:20
Bel article ne présentant que peut d’erreurs (mais on est bien d’accord, c’est de la vulgarisation, hein). Je pense cependant qu’il aurait été utile de s’attarder un poil plus sur la question du bus. Le processeur ne voit en effet lui même qu’un seul des bus présentés dans l’article, le bus système, qui fait le lien entre le processeur et ce qu’on appelle le south bridge. C’est le south bridge qui ensuite accède aux composants.
Enfin, ne voit qu’un seul bus… En fait il en voit bien deux : un bus données (donc celui où les données circulent) et un bus adresse (qui permet au processeur d’indiquer au reste du système où chercher/enregistrer les données).
Quand on parle de processeur 32 ou 64 bits, on parle toujours de la largeur du bus adresse. Ça n’indique donc pas le nombre de données traitées en un temps donné, mais la capacité d’adressage du processeur. Un processeur 32 bits a donc une plage d’adresse de 4 Go (2^32 octets) alors qu’un processeur 64 bits permet d’atteindre 2^64 octets de mémoire adressable (soit très exactement 18 446 744 073 709 551 616 octets).
Ceci dit le bus données s’est aussi élargi, le PowerPC G3 avait déjà un bus données de 64 bits par exemple, j’ai pas regardé pour le G5 mais il doit faire au moins 128 bits, voire plus.
, le 18.05.2006 à 09:34
Un bel et bon article tout à l’honneur de Cuk.
Bravo !
^. .^ GerFaut
=U= Equinoxiale
GerFaut c’est frais, mais c’est pas grave.
, le 18.05.2006 à 09:44
Gael :
un tel chiffre n’apporterai pas grand chose.
En fait, n’importe quelle valeure prise seul ne signifie rien.
Donc, il faudrait une étiquette avec
– nb de coeurs du proc
– frequence des coeurs
– nombre de niveau du pipline
– quantité de mémoire cache niveau 1, 2 et eventuelement 3
– bande passante du bus système
– debit et temps d’accès de la mémoire
bref, une étiquette totalement indéchiffrable !
Ou alors, fournir les résultats SPEC du proc, en sachant qu’ils ne correspondent pas forcément à une utilisation réelle :-).
, le 18.05.2006 à 09:52
En ce qui concerne la performance d’une machine :
1) amélioration hardware
2) amélioration software
=> les deux !
Cependant avec des nuances. Une machine puissante est avant tout une machine homogène. Il ne faut pas oublier qu’en électronique (en simplifiant beaucoup) l’ensemble se calera sur l’élément le plus lent !! C’est pour cela que je râle constamment contre le marketing qui met en avant un prix et un processeur… et c’est tout ! Il ne sert à rien ou presque d’avoir le meilleur processeur du monde qui tue la mort qui arrache… si tout le reste est à la traîne : mémoire, bus mémoire, chipset, sous ensemble disque, etc.
Au niveau des softs, il faut avoir conscience qu’un programme peux toujours être optimisé. Enfin, la marge de manœuvre est d’autant plus faible que le langage utilisé est dit de « haut niveau ». Après, tout est une question de temps et donc de coût.
Au niveau professionnel je le vois bien. Lorsque la mémoire était rare et chère, les processeurs limités en puissance et bien le rôle du soft, son optimisation, était cruciale. Je pense que les vieux de la vieille me comprendront que je dis qu’on utilisait des mots mémoires de 16 bits pour stocker et traiter deux mots mémoires de 8 bits avec des masques binaires afin de gagner en place et en temps. Que la création et l’organisation des structures de données était mûrement réfléchie afin d’optimiser l’occupation mémoire. etc..
Ensuite la mémoire coula à flot, la puissance processeur explosa, ainsi que la concurrence ! Alors il fallait faire toujours plus vite, avoir les délais les plus courts pour remporter le marché. Conséquence : l’optimisation fut la première sacrifiée. Cela ne c’est pas trop fait sentir au début par l’augmentation de la puissance des machines, par l’augmentation de l’efficacité des compilateurs.
Pourquoi l’optimisation est devenu secondaire ? Simplement parce que les utilisateurs finaux sont toujours plus pressés. Ainsi, l’optimisation ne revient d’actualité que lorsque cela devient un élément critique de compétitivité, que lorsqu’elle redevient rentable.
D’un autre côté, je suis parfois effrayé lorsque j’encadre de jeunes stagiaires ingénieurs qui savent à peine comment fonctionne un ordinateur, comment est gérée la mémoire, etc. Comment espérer optimiser quand on ne sait même pas comment cela fonctionne ? Certes, le java et autres consorts sont d’excellents langages mais avec eux on ne fait d’effleurer la surface des choses, juste un peu de cambouis sur le bout des doigts. Je reste persuadé qu’on apprends mieux avec du cambouis jusqu’à l’épaule et pour cela l’assembleur ou le C sont très formateur. Et je peux vous garantir, qu’ensuite, cela se ressent jusque dans la structure des programmes écrits avec des langages de plus haut niveau.
Stilgar pourtant pas si vieux et qui parfois à l’impression d’être un dinosaure avec des « idées d’un autre temps ».
, le 18.05.2006 à 09:57
ah les cours de M. Sanchez, ce professeur est une légende vivante! Un enseignant qui mettait de la couleur avec son accent si particulier (n’oubliez pas de brancher l’entrée inébol), et qui savait transmettre un message…
pour ce qui est de fournir les résultats SPEC: pourquoi ceux-ci est pas d’autres? Un benchmark ne mesure nullement la performance d’un processeur, il mesure l’aptitude de ce processeur à passer rapidement ce benchmark précis. Résultat: des processeurs optimisés pour le benchmark en vogue du moment…
Pour moi le seul indicateur valable c’est ces tests dans les magazines faits pour chaque application. Le graphiste veut appliquer ses filtres dans photoshop plus vite, et l’ingénieur son veut que cubase aligne ses pistes le plus vite. Le client se fout royalement des performances générales, il veut le processeur le plus adapté à sa tâche bien spécifique à lui. Et tant pis si son application n’est pas optimisée et qu’elle pourrait gagner 80% de vitesse en la programmant mieux, ce n’est pas son problème à lui…
Mais en tous cas, merci 6ix pour cet intéressant article!
, le 18.05.2006 à 10:10
RBGreg :
Je suis entièrement d’accord avec toi : seul vaut le teste en utilisation réelle.
Mon baratin précedent était juste déstiné mettre en évidence que un ordinateur est actuellement bien trop complexe pour qu’on puisse quantifier sa puissance avec quelques chiffres, surtout si on s’adresse à un consommateur lambda.
, le 18.05.2006 à 10:41
Excellent article!
Par contre, je suis assez amusé par tout le marketing qui a pu être généré autour du 64-bits et par le fait que les processeurs Intel sont resté en 32-bits… Attendons la prochaine génération de stations de travail!
, le 18.05.2006 à 11:06
Merci pour cet excellent article très clair.
J’ai l’impression d’être moins idiot ce matin..
Vu la tendance actuelle des procs à être de plus en plus gourmands en énergie, et l’utilisation réelle de la puissance de ces processeurs dont j’ai besoin (principalement bureatique), je regarderai plus attentivement le facteur ‘performance per watt’, l’optimisation de mes principaux logiciels et la consommation globale des machines lors de mes prochains achats.
Je n’ai pas besoin d’un ordinateur qui soit capable de ma calculer quelle est la meilleure façon de contruire un rafale en 5 minutes….
, le 18.05.2006 à 11:06
J’aurai essayé! ;-)
Effectivement… Ce paragraphe n’est peut-être pas à sa meilleure place dans le chapitre sur l’amélioration des performances, mais je voulais en parler brièvrement tout de même vu qu’Apple s’en est vantée à l’arrivée du G5.
Complètement d’accord! :-)
Je ne dis pas qu’un benchmark mesure dans l’absolu la performance d’un processeur; c’est plutôt un moyen de comparaison. Mais comme tu le dis, l’important pour l’utilisateur est le temps d’exécution final, et dans ce cas, mieux vaut en effet réaliser des tests sur les programmes utilisés par celui-ci.
Pourquoi le SPEC, simplement car il est très utilisé commercialement et car je pouvais aussi présenter un tableau de comparaisons assez récent fourni par M.Sanchez.
, le 18.05.2006 à 11:20
en fait, ce n’est pas l’utilisation de SPEC dans l’article qui me dérangeait, c’était la proposition de Popey de l’utiliser sur des étiquettes…
le problème que l’on a c’est que l’utilisation commerciale ne répond pas forcément à une réalité d’ingénierie ;)
Qui plus est, multiplier les tests sur différents logiciels pourrait avoir un effet de3 bord intéressant. Supposons qu’Intel sorte un nouveau proc qui fasse gagner 50% sur la mesure de chaque logiciel sauf un. Les développeurs de ce dernier soft auraient une assez grosse pression puisqu’il serait démontré que leur application ne tire pas parti de l’architecture…
, le 18.05.2006 à 11:44
Peu d’erreurs, donc des erreurs. Lesquelles et où les vois-tu ?
Quoi qu’il en soit, à te lire, on se dit qu’il est heureux que tu n’aies pas écrit cet article sur le sujet car, toujours te lisant, on subodore l’absence de clarté qui, au contraire, donne toute sa valeur à celui de 6ix.
Une fois encore, Cuk.ch fait de la culture populaire et éclaire notre lanterne sur un domaine particulièrement complexe, envahi de surcroît par un « marketing » qui beurre à l’envi de ses mensonges (son arme de prédilection) les descriptifs les plus objectifs pour nous livrer un brouet aussi trompeur qu’approximatif et faire régner sur le domaine une confusion propice à l’exploitation d’un gros élevage de pigeons. L’honnêteté marque un point contre la société du mensonge.
Merci, 6ix, de procurer aux gens honnêtes ce texte de référence qui porte un éclairage suffisamment précis sur un sujet particulièrement abscons pour que chacun sache désormais de quoi il parle. On ne pouvait mieux faire.
Mais n’oublions pas que la plupart d’entre nous, quand ils achètent un ordinateur, achètent une machine surdimensionnée pour l’usage qu’ils en font, aussi, la course à celui qui a la plus grosse est parfaitement vaine. Cessons de croire que nous partageons avec les universitaires et autres ingénieurs et techniciens de haute volée le souci de disposer des processeurs les plus ceci ou les plus cela. Cette emphase est proprement ridicule.
Oui, un autre monde est possible.
, le 18.05.2006 à 11:54
Très bon article !
Personnellement étant un peu dans le domaine, j’aurais bien aimé un approfondissement sur les unités de traitement (entier, flotant, vectorielle) et en particulier une comparaison entre les différentes unités de traitement « multimédia », Altivec vs MMX, SSE.
, le 18.05.2006 à 12:05
@Okazou: je suis moi-même dans le domaine, et je peux donc avoir un avis relativement éclairé sur le sujet (bien que la conception de processeurs ne soit pas ma spécialité).
Il n’y a pas à proprement parler d’erreurs dans cet article. Certaines ommissions se trouvent toutefois à l’intérieur. Oui, il n’a pas parlé de la différence entre les bus, des unités à virgule flottante, il n’a pas précisé qu’il existe des architectures à pile, à registres ou que sais-je… et alors?
Le but n’est pas un cours d’ingénierie, le but ici est d’expliquer clairement les principes de fonctionnement d’un processeur. Et il me semble que l’article de 6ix mérite des éloges dans ce domaine, c’est une petite merveille de vulgarisation.
Je te rejoins donc Okazou! Chacun peut prendre le contenu de cet article comme culture personnelle et « briller en société » fort de ces informations :P (bon c’est pas terrible pour draguer les nanas, mais sait-on jamais)
, le 18.05.2006 à 12:28
C’est peut être à cause des donneurs de leçons « qui savent mieux » que beaucoup n’interviennent pas dans les commentaires… eh François?
Cela étant, excellent article, merci
elektrikpepper
, le 18.05.2006 à 12:33
Cela va mieux après les commentaires rajoutés par 6ix et les autres. Il faut l’avouer que c’est assez difficile à comprendre.
Finalement si je résume, avec une brouette de 1999, on pourrait bien faire tourner des applications taillées sur mesure (optimisées) avec des fonctionalités d’aujourd’hui sans changer donc de machine.
Cela m’explique que la vieille machine NeXT Station (Motorola 68040 33Mhz RAM 80Mo) qui trône ici permette de faire des documents magnifiques avec ses propres applis dont teTeX et que les nouvelles applications sur ma — un peu moins vieille — PowerBook Titanium (PowerPC 400 MHz – RAM 768Mo) se mette à traîner les pieds un peu devant chaque nouvelle mise à jour d’application (Suite Adobe impossible dans la configuration sus-citée).
L’optimisation est finalement la clef de nos problèmes : les industriels souhaitent nous faire changer de bécane tous les 2 ans. Ils sortent l’OS plus gourmands, puis les softs plus « pachydermiques » suivent et nous, pour quelques menues améliorations, on change le hard.
Remarquez qu’ils font les efforts quand ils le veulent bien. Apple dans sa version MacOSX première mouture était plus lent que dans 10.1 qui était plus lent que dans 10.2 qui était plus lent que dans 10.3 avec la même machine : performance croissante par l’optimisation du soft.
Ne peut-il pas se former un groupe d’optimiseur de soft pour nos machines? On y gagnerait beaucoup en energy, en recyclage, en écologie mondiale plutôt que de changer de hard tous les 2 ans si on suivait les Capitaines d’industrie. Excusez cette disgression.
Merci 6ix pour ton article. Les processeurs restent quand même un peu (CISC ;-)) complexes pour moi.
Yves l’utopiste.
, le 18.05.2006 à 12:50
Ah nom de dzou le choc!:-)
6ix, je ne sais pas si tu te rends compte de ce que tu es arrivé à faire là…:-)
, le 18.05.2006 à 13:08
Etant également dans le domaine, je trouve cette article génial, super bien vulgarisé pour des non spécialistes. Je l’ai même fait lire a des étudiants.
, le 18.05.2006 à 13:30
Pas vraiment… mais si tu le dis! :-)
De rien pour tous les merci!
, le 18.05.2006 à 14:33
(màj: rajouté les liens pour réf.)
J’ai bien peur que tu parles là de l’hyper-threading, nom commercial donné par Intel au Simultaneous multithreading (SMT).
Le multi-threading est une notion logicielle: la capacité d’un système d’exploitation à exécuter simultanément plusieurs processus simples (threads, qui signifie fils) pouvant appartenir ou pas au même programme. Ce qui conditionne son utilisation, ce n’est donc pas les caractéristiques du processeur, mais le fait qu’un programme ait été écrit sous la forme de plusieurs sous-processus simultanés et que l’OS le permette, ce qui est un avantage pour l’organisation des programmes mais pas a priori pour l’exploitation des ressources matérielles.
Quand la partie logicielle est multi-thread, il est possible d’améliorer le rendement avec un processeur optimisé pour ça (multithreaded processor) par une technique appelée superthreading ou time-slice multithreading, qui consiste en gros à permettre à l’OS de demander au processeur d’exécuter lui-même plusieurs threads simultanés (alors que sans ça, le multi-threading consiste pour l’OS à découper l’exécution de chaque thread dans le temps avant de les transmettre au processeur et leur exécution n’a donc que l’apparence de simultanéité).
Le superthreading présentant encore des limitations techniques, en gros de ne pouvoir exécuter simultanément que plusieurs threads d’un même programme, l’amélioration suivante est le simultaneous multithreading , appelé hyper-threading par Intel et qui correspond à ta description: un processeur non seulement capable de gérer lui-même des threads, mais se présentant de plus au système comme plus d’unités de traitement qu’il n’en comporte physiquement, ce qui permet à l’OS de gérer plus librement et plus simplement ses threads et laisse le processeur optimiser ses propres ressources.
Ces optimisations successives ont donc consisté à faire « descendre » dans le matériel de plus en plus des fonctionnalités nécessaires à l’exécution simultanée de plusieurs processus. Ceci améliore l’exploitation du matériel et simplifie le travail du logiciel, mais le multi-threading reste une fonctionnalité logicielle: un OS ou programme non multi-thread n’en profitera pas et inversement un OS ou programme multi-thread fonctionnera aussi sur un processeur non optimisé pour ça (du moins tant que l’OS prendra la peine de prévoir ce cas, qui se raréfie).
Trop de détails en Anglais: Introduction to Multithreading, Superthreading and Hyperthreading
Ou beaucoup plus synthétique dans ce lexique d’un homologue anglophone de notre 6ix : The Computer Processor
, le 18.05.2006 à 15:34
J’ai rien compris sur le coup des pipelines, en particulier cette phrase:
Pourtant, en regardant le schema, on dirait que le processeur est capable de faire plusieurs choses a la fois, non?
A part ca, je suis d’accord avec le commentaire 22 de elektrikpepper: le commentaire d’Okazou est un peu violent.
, le 18.05.2006 à 15:53
Le parallélisme, c’est le traitement simultané de plusieurs machins. Par exemple une force d’Altivec est de pouvoir appliquer simultanément une même instruction à plusieurs données, qui entrent en même temps et sortent en même temps: elles auront été traitées en parallèle (on parle dans ce cas de traitement vectoriel car d’un point de vue géométrique elles se seront déplacées selon un même vecteur).
Le pipeline c’est ne pas laisser le reste d’un processeur se tourner les pouces pendant qu’une instruction qui nécessite plusieurs cycles passe d’une partie du processeur à une autre. Par exemple pendant que la zone dédiée à l’arithmétique fait une addition, rien n’empêche la zone chargée de lire l’instruction suivante de le faire, donc on organise le proc pour ça, ce qui a des avantages (pour des raisons techniques, plus le pipeline est long plus on peut augmenter la cadence du processeur) et des inconvénients (plus le pipeline est long, plus on risque de devoir attendre longtemps lorsque l’instruction suivante dépend du résultat d’une précédente).
En gros les architectures CISC (instructions nécessitant beaucoup de cycles) tendent vers de longs pipelines et fréquences élevées et les architectures RISC (instructions nécessitant peu de cycles ou un seul) vers des des pipelines courts et fréquences moins élevées.
, le 18.05.2006 à 15:59
je vais faire une analogie:
imagine une machine qui doit emballer des glaces.
Première étape: placer un pot sur la chaîne
seconde étape: verser la glace dans le pot
troisième étape: placer un couvercle
On peut imaginer deux approches:
1. on attend que tout soit finit pour passer à la glace suivante
2. On place un nouveau pot sur la chaîne alors que le premier pot est en train de se remplir de glace.
le second comportement utilise un pipeline, alors que le premier comportement, très bête, n’en utilise pas
, le 18.05.2006 à 16:12
Et dans cette analogie, le parallélisme consiste à entraîner plus d’un tapis roulant ou multiplier le nombre de machines.
Note bien que si c’était moi, je m’allongerais directement sur le tapis en ouvrant la bouche.
, le 18.05.2006 à 17:30
Merci pour vos explication, VRicet RBGReg! La solution de VRic me semble la meilleure. S’agit-il de multitache cooperatif (tant que je suis sur le tapis, personne d’autre peut en profiter)?
Je me mangerais bien une glace, moi, tout a coup.
, le 18.05.2006 à 17:47
Bravo pour ce bel article, 6ix!
Mais, pour moi qui ne suis strictement qu’un utilisateur, il y a des mystères qui restent entiers.
On nous dit que l’information passe par ici, qu’elle revient par là… Ça, à la limite, je comprends. Mais ce qui me dépasse, c’est la miniaturisation d’un processeur: comment mettre autant d’informations et de fonctions dans un si petit espace?
C’est la même chose avec la mémoire vive (flash): comment arrive-t-on à mettre et à enlever des informations dans un bout de machin qui a l’air tout à fait inerte?
Quelqu’un pourra-t-il un jour me l’expliquer?
, le 18.05.2006 à 18:57
L’impression de me faire baiser comme Van Ruymbeke (toutes proportions gardées, bien sûr…)
« M’sieu, M’sieu ! Y’a Okazou qui empêche les autres d’écrire ce qu’ils veulent. M’sieur ! »
Et voilà ta contribution réelle à l’article essentiel de 6ix.
Je suis peut-être moins poli qu’un autre mais lorsqu’un 6ix se donne la peine de nous offrir un article fondamental sur un sujet aussi casse-gueule et qu’il y parvient avec une maestria qui mérite notre respect on ne la ramène pas avec prétention en commençant par jeter un : « Bel article ne présentant que peut d’erreurs » qui casse d’entrée et sans raison l’auteur sans d’ailleurs apporter le moindre éclairage sur les erreurs en question.
D’autant qu’en guise d’erreur, VRic lui-même (VRic en personne !) n’y relève que l’emploi imprécis d’un terme.
Un condensé pareil, il fallait l’écrire : que dire pour éclairer, que taire pour rester clair ? Et le tout sans frimer, si on voit ce que je veux dire…
Alors, elektrikpepper, si chaque fois que je prends la défense d’un auteur sur un article irréprochable, tu choisi de défendre ceux qui l’attaquent injustement, on n’ira nulle part, c’est sûr.
—
Oui, un autre monde est possible.
, le 18.05.2006 à 19:27
nos solutions ne sont pas différentes, Vric y a ajouté le parallèlisme, j’y reviens après.
Maintenant le multi-tâche: ça ce n’est plus du hardware mais du software. Le multi-tâche c’est la capacité de MacOS par exemple de laisser plusieurs applications tourner en même temps.
Dans notre analogie, ce serait de réussir à faire de la glace à la fraise en même temps que de la glace vanille.
Il existe deux types de multi-tâche: coopératif (OS9, windows 3.11) et préemptif (OSX, linux, windows 2000).
Dans le multi-tâche coopératif, c’est l’application qui signale qu’elle n’a plus besoin du processeur, alors que dans le préemptif c’est le système qui partage équitablement le temps de travail.
Le gros défaut du multi-tâche coopératif est que si un processus plante, il entraîne tous les autres psuiqu’ils ne peuvent recevoir de signal du premier.
On reprend l’analogie des glaces, je l’aime bien:
On est sur un système non parallèle. Deux applications se partagent le temps: glace à la vanille et glace à la fraise.
En coopératif: on charge les pots pour la vanille, et on commence. Lorsque l’injecteur signale qu’il n’y a plus de vanille, on arrête l’insertion des pots, on change la matière première, on place une réserve de pots de fraises et ça repart.
En multi-tâche préemptif: le système choisit de placer un pot de fraise, suivi d’un pot de vanille (l’opérateur pourrait choisir de mettre des priorités, soit deux vanille, suivi de deux fraise => priorités). L’injecteur est double et place de la vanille ou de la fraise à chaque fois qu’il est nécessaire.
Sans multi-tâche: il est impossible de commencer une journée en fraise et de la finir en vanille. (y a des syndicats pénibles, j’vous dis pas)
Donc si on récapitule:
– le pipeline, c’est le fait de ne pas attendre qu’une opération soit complètement terminée (l’emballage complet d’une glace) avant de commencer la suivante. C’est du hardware.
– le parallèlisme c’est de mettre deux chaînes d’emballage complètes qui tournent l’une à côté de l’autre. C’est du hardware
– le multi-tâche: c’est le fait de pouvoir faire tourner plusieurs applications en même temps (2 ou plus types de glace exploitant la même chaîne de production). C’est du software.
Dans le cas des glaces, on peut constater que si on fait une belle architecture parallèle, en plaçant la vanille sur l’un des engins de production et la fraise sur l’autre, on y gagne beaucoup.
, le 18.05.2006 à 19:44
Bonjour,
Tout à fait d’accord avec toi Okazou : m’a aussi fait bondir le monsieur ctr_alt_supr avec sa remarque pontifiante. Il me fait penser à un de mes profs qui me disait un jour : « Excellent travail mais deux fautes d’orthographe ont gâché le plaisir que j’aurais eu de pouvoir enfin noter une dissertation 8/10 voire plus. Finalement vous avez 6,5. »
Merci 6ix.
, le 18.05.2006 à 19:50
Pas mal, l’exemple des pots de glace.. Pour être tout à fait complet, on pourrait ajouter un cas de figure fréquent : le système voudrait bien remplir de la vanille, parce que c’est son tour, mais il n’y a plus de pots. Donc on remplit à nouveau de la fraise le temps que les pots vides arrivent. C’est ce qui arrive lorsqu’un programme attend une entrée sortie(une lecture disque, par exemple).
, le 18.05.2006 à 20:51
Je réagis aux commentaires (rien à dire sur l’article)
La signature d’Okazou est systématiquement tronquée et il a la grâce de ne pas se plaindre, en effet il manque la fin : « il suffit de supprimer l’humain »
, le 18.05.2006 à 22:25
Non, c’est du multi-tâches préemptif : les autres en profitent – seulement – dans le bref intervalle où tu reprends ta respiration.
Et pour filer la comparaison, le multi-tâches préemptif avait un corollaire sous Mac OS 9 : la mémoire non protégée. Ainsi à chaque fois que tu vomissais parce que la cadence était infernale, tu éclaboussais les pots des autres.
Avec Mac OS X, tu n’éclabousses que toi.
, le 18.05.2006 à 22:43
Très intéressant ! Merci beaucoup !!!
, le 18.05.2006 à 22:57
Si, car ce qu’il évoque là c’est allongé sur le tapis avec la bouche ouverte, que tu avais négligé:-)
Solution forcément multi-taches sauf à porter un imper en plastique, préemptive car pendant que tu y es plus personne ne peut se servir (en s’y prenant bien il est même possible d’obtenir qu’ils n’aient plus envie de se servir), et écologique car il faut combattre les emballages excessifs.
Et ça marche aussi avec la bière!
Remplir avant que les pots vides arrivent, c’est un exemple de bug: la fraise est sur le tapis, manque de pot ;-)
Un programme oui, s’il est multi-thread, mais dans le processeur une attente se traduirait par des noop (no-operation, instruction vide, aussi utilisée pour l’empêcher de chauffer), ce qui correspond à ne rien remplir du tout. Si on a autre chose à faire au niveau logiciel c’est le moment d’en profiter et c’est du ressort du multi-tâche ou du multi-thread, en l’occurence effectivement la décision de ne pas laisser le processeur à un processus qui n’a rien à faire.
Mais on n’a pas forcément un autre processus qui attend, auquel cas c’est le processeur qui attend en faisant « rien » très très vite et c’est ça qui est le plus fréquent: le processeur n’a généralement rien à faire. Les procs actuels en profitent pour faire des siestes super-rapides ou baisser leur fréquence histoire d’exécuter « rien » moins de fois et économiser du courant.
Tout ça se mélange un peu quand le processeur décharge le logiciel d’une partie de la gestion du multi-thread. Allez, voyons si quelqu’un peut étendre l’exemple glacial à la virtualisation, considérant que les processeurs actuels intègrent aussi des fonctionnalités à cet effet. Pour ceux qui hésitent sur leur prochain bouzin, c’est l’une des différences entre le bas et le haut de gamme Intel: les « gros » procs intègrent des fonctionnalités dédiées à la virtualisation et les « petits » non, laissant supposer que les Macs pro seront meilleurs que les mini pour des trucs comme Parallels Workstation.
, le 18.05.2006 à 22:58
J’apporte une contribution majeure : j’aime bien les glaces vanille-fraise !
Blague à part : chapeau 6ix ! La vulgarisation est un domaine « casse-g… » et tu t’en es sorti magistralement !
, le 19.05.2006 à 01:10
Bonjour,
Pour ceux qui n’ont pas compris le principe des pipelines, ces deux images aideront peut-être à clarifier les choses:
la lessive sans pipeline:
la lessive avec pipeline:
Et sinon pour monsieur Okazou, je trouve aussi que tu es assez agressif. Je n’ai pas l’impression que ctrl_alt_suppr attaque injustement l’article, ne commence-t-il pas son commentaire par « Bel article »? Je trouve au contraire qu’il apporte des précisions intéressantes, et que son intervention est bien plus constructive que la tienne, où tu essaies de dissimuler ton ignorance en la matière avec des tournures de phrases qui se veulent érudites… Enfin c’est mon point de vue.
, le 19.05.2006 à 03:54
Citation de Vric
« Remplir avant que les pots vides arrivent, c’est un exemple de bug: la fraise est sur le tapis, manque de pot ;-) »
Tu as raison, j’aurais dû préciser que les pots de vanille et les pots de fraise n’étaient pas les mêmes. Parce que si on met de la vanille dans un pot estampillé fraise, ça s’appelle une tromperie sur la marchandise :-)
, le 19.05.2006 à 07:52
@Ozakou : désolé si ma réaction a pu en choquer certains. Il m’a juste semblé que l’article pouvait laisser croire qu’un processeur serait plus rapide parce qu’il est 64 bits au lieu de 32 (ce qui est à mon sens une erreur), et j’ai donc essayé d’apporter une précision.
Mon but n’était absolument pas de dénigrer l’article de 6ix qui est remarquable. Toutes mes excuses si j’ai blessé quelqu’un.
, le 19.05.2006 à 13:15
Nan ! ‘tain ! Nan !
La glace au chocolat ! je vous dit ! et après faites la lessive comme vous le voulez…
ça va, ça va, je vais sortir…
Moi je suis comme Caplan, ce qui se pase sous le capot est grand mystère, je n’en suis que plus reconnaissant envers ceux qui tentent de me faire comprendre l’avantage du RISC sur le CISC…
Je n’ai néanmoins toujours pas compris, même si cela m’est totalement indiférent, pourquoi Apple a soudainement changé de mécanique… nous vantant aujourd’hui le plus naturellement du monde ce qui était hier montré du doigt…
Mais c’est une autre histoire !
Alexis… zamé contan !
, le 19.05.2006 à 13:48
Dont acte, ctrl_alt_suppr, et toutes mes excuses également.
—
Oui, un autre monde est possible.
, le 20.05.2006 à 23:28
Le dernier 680×0 était le 68060, mais Apple ne l’a jamais utilisé alors qu’il était plus puissant que le ppc 601.
Mais bon c’est de l’histoire ancienne :-)
Chouette article.
Je verrais bien le tout approfondis avec plusieurs chapitres, genre tous les mardi… Ah j’en demande trop… :-)