Non tu perds globalement des perfs sur ton système. Un process qui ne prends que 40 % de cpu se fout du temp passé dans la lecture du disque pour tenir ses deadlines. Dans les 60% non utilisé est compté le temps passé à attendre les io.
Tu ne peux que gaspiller de la puissance dans la gestion des thread et le traching de mémoire cache en faisant plus compliqué.
Tu aura peut-être plus de puissance pour tenir des deadline à 500 images/s mais ce n'est pas ça que l'on demande au codec.
Ce que tu décris s'appelle les acces asynchrones ou non bloquant (asyncIO). Il me semble que la glibc sait faire ça depuis longtemps elle même et que linux 2.4 le prends en charge maintenant commeun grand.
Il est donc parfaitement inutile de programmer un thread pour ça.
De plus, lors d'acces io, si le temps est trop long, le scheduler peut décider de donner la main à un autre process (cela se voit facilement avec l'utilisation d'un lentissime printf). Tu ne perds donc aucun cycle.
Si ta machine ne fait qu'une seule tache, un monothread sans io non bloquante étant bloqué à chaque io, tu perds des perf sur ce process-là uniquement. Mais globalement, ta machine peut faire d'autres trucs. Il n'y a pas de gaspillage.
Si tu veux augmenter les perf c'est-à-dire parraléliser acces disque et calcul, et bien, les io asynchrones ou non bloquantes sont faites pour ça !
Tu m'épates là ! Tes arguments sont complétements à inverser.
1/ Pour faire, la même tâche si tu utilises 2 threads au lieu d'un seul tu perds des cycles à passer de l'un à l'autre. Si TUX (serveur http noyau) déchire, c'est parce qu'il fait de la zero copie et qu'il n'a PAS un thread par utilisateur. Sur un monoprocesseur, à cause des changement de tâche, tu perds du temps. Si quelqu'un lance un gros boulot, le scheduler doit juste scheduler un thread de plus. Cela ne lui fait que perdre du temps.
Sur un bi-pro (ou SMT), tu repartis la charge, genre 2% sur chaque cpu. Or les partages de mémoire font que les caches sont sous utilisé (en SMP) mais pas en SMT. Or en SMT, si des optimisations typé SMP sont utilisé (grosse séparation des flux mémoire pour éviter de trasher les caches) la pression sur les caches devient énorme (les caches miss s'envole aussi). Les optimisations SMT/SMP sont antagonistes sur la gestion des caches.
2/ Vu que l'ordonanceur à un process/thread de plus à traiter, tu le ralentie. Si tu est sur un bi-pro, dans le cas monothread, un cpu est libre donc le temps de réponse est minimal à un événement extérieur. Ce n'est absoluement pas le cas en multi-thread.
3/ Tu tire mieux parti d'un bi-pro certe mais au détriment du temps de réponse. Tu ne fais que perdre du temps sur un monoprocesseur. Le design est bien plus complexe à maintenir. Cela semble sans doute plus propre pour un serveur mais du point de vue performance c'est pas terrible du tout.
Parce qu'il faut bien se souvenir que les x% de cycles CPU utilises par mplayer pendant un moment donne(et qui auraient pu etre utilise avant quand il n'y avait pas urgence) sont x% de cycles que les autres softs ne peuvent pas utiliser, et peut-etre qu'ils en auraient besoin eux.
A tache égal, un multithread prendra toujours plus de cycle globalement qu'un monothread. Donc, je ne comprends pas ce que tu veux dire.
T'es vache.
Les techno SMT sont beaucoup plus finaudes que ça.
En fait, les process sont également utilisé pour combler les bulles dans chacun des 5 pipelines d'execution. C'est pour cela que le gain de vitesse max , se fait avec un process utilisant le nombre flottant et l'autre les nombres entiers.
Le problème est toujours d'augmenter l'ipc à même fréquence (pour le P4, ils ont choisi de pousser le SSE que d'augmenter l'IPC mais bon). Mais comment faire avec des ISA pas conçu du tout pour ça. Bah, avec des coeurs out-of-order bien complexe.
Augmenter la fréquence pose parfois des problèmes, car elle nécessite des outils de gravure de plus en plus affinés, qui ne sont pas forcément disponibles.
Euh, pour une techno donné le temps de parcoure d'une porte est fixe. Tu peux mettre plein de portes en parrallèle (ipc monte), moins de porte entre 2 registres (pipeline, frequence monte), ou refaire le routage (moins de temps perdu dans les fils, la fréquence monte).
Ou changer de techno. Il n'y a pas de problème d'outils, c'est bettement physique (la NAND elle a besoin de 15 ps, il ira pas plus vite en changeant d'outils).
Et le but originel de faire un ISA simplifié n'était-il pas de faire une microarchitecture plus légère ?
si. L'utilisation de décodage puis de micro instruction, aussi. Mais il ne s'agit pas de mettre un risc derrière le décodeur (cela plutot ressembler à un vliw d'ailleurs).
>(un code ARM thumb est bien plus gros que du code "normal" x86)
J'ai vu ça dans un comparatif de compilation de différent fichier .c, puis gzipper comparant ARM (compilo arm et gcc), x86, Sparc (Leon).
Je dis "normal" pour le x86, car il utilisait -02 au lieu de -0s comme switch pour gcc. Et la différence était assez importante.
Car linux ne se compile QUE avec gcc et gcc ne se compile qu'avec gcc (il me semble) et c'est le seul programme qui ne compile qu'avec -02 -g que j'ai vu.
D'ailleurs le bench peut être : compile de linux 2.4.18 avec tel .config avec gcc 3.2.0.
Pour participer à un projet tu n'as besoin de personne. Tu récupères le CVS, tu fais tourner le bidule, tu corriges 3 bugs et tu envoies le patch aux mainteneurs.
Merci ne pas me considérer comme un raté. :-)
Si cela te touche, c'est bien le problème, non ?
Il est vrai que beaucoup de commentaires ont peu d'intérêt mais est-ce que parce l'on a rien a dire, il se taire ? Ca fait aussi parti de l'ambiance du site.
C'est l'unique interret des votes : faire un trie !!!
Si tu veux lire rapidement la news, tu ne peux pas toujours lire les 200 commentaires qui suivent.
C'est un très bon bench !
Sauf qu'il est dédié à la plateforme x86. Il faudrait un gros programme qui n'a pas de #define en fonction de sa plateforme pour en faire un vrai bench.
L'exécution d'instructions dans le désordre a été introduite par le Pentium Pro dans le monde CISC, tandis qu'elle n'est apparue dans le monde RISC que bien plus tard, par exemple avec l'Alpha 21264 ou l'UltraSparc III.
Yep parce que les processeurs RISC n'ayant pas encore les poids des années et de la compatibilité n'en avait pas (encore) besoin.
Lorsque l'alpha à eu un core OO, il a pris 45 millions de transistors en +...
Il faut aussi préciser que, au delà des jeux d'instructions proprement dits, les processeurs actuels du monde x86 sont des RISCs qui se cachent : en effet, tous incorporent en réalité une étape de décodage des instructions x86 en micro-instructions de type RISC, plus faciles à éxécuter dans le désordre.
microinstruction, microcode, s'est pareil ! je persiste à insister : RISC/CISC qualifie le jeu d'instruction pas leur implémentation !
Cet discussion CISC contre RISC n'a plus aucun sens de nos jours. Elle n'incorpore même pas les jeux d'instruction VLIW qui commencent à apparaitre avec les processeurs de Transmeta ou l'Itanium d'Intel.
Et elle a une signification très claire pour une même architecture:
Pas forcément, car le bus mémoire ne change pas de vitesse (en général). Les P4 1,5 Ghz ou 3,06Ghz utilisent tous de base la RDRAM 800. Cela m'étonnerait que le 3,06 soit 2x plus rapide que le 1,5Ghz (sans tenir compte de l'hyperthreading évidement).
les processeurs x86 ont un coeur RISC et un front-end pour les instructions CISC x86
ça c'est du buz word. C'est l'ISA qui est CISC pas le processeur ! Car dans ce cas des processeurs RISC ont des coeurs CISC (cf DLX) !
des améliorations "CISC" comme la mémoire cache ou la prédiction de branches pour gagner en performances.
gni ? le rapport avec la choucroute ? RISC/CISC qualifie l'ISA pas la microarchitecture !
(la réalité est d'ailleurs que le SIMD vient du monde des DSP).
Perdu ! Cela vient des supercalculateurs "vectoriels" comme les Cray.
La distinction RISC/CISC se trouve encore dans le petit "embarqué". Les RISC se prêtent bien au "pipelining" des instructions contrairement au CISC.
C'est vrai.
On gagne donc en nombre d'instructions par cycle tout en gardant la même fréquence (5 - 30 Mhz) et presque la même consommation électrique (et c'est très IMPORTANT dans l'enfoui).
La phrase est ambigüe. Disons qu'à complexité égal, un processeurs RISC monte à plus haute fréquence (souvenez vous des premiers alpha).
Pour la consomation élèctrique, il y a d'autres facteurs qui rentre en jeu.
Le nombre élevé de registres dans le RISC est un plus dans la course au performance puisque on limite les accès mémoires dans des boucles de calculs.
C'est la conséquence du gain de place que l'on a en virant l'inutile. Mais ce n'est pas réservé au RISC. Il suffit de voir les nouveaux DSP texas qui ont des instructions, 16 32 48 bits... pour gagner en taille de code (un code ARM thumb est bien plus gros que du code "normal" x86).
Pourtant, les chips CISCs ne sont plus nécessairement les plus rapides !
Les CISC sont à prioris plus lent car il consacre + de silicium à des trucs pas vraiment utile contrairement au RISC (nue règle de 80-20, vaux mieux optimiser à fond 80% des instructions les plus utiliser que ce faire chier avec les 20% restant complexe et qui ralentissent tout)
M'enfin, les x86 déchirent tous en ce moment. Les Power 4 trichent au specint (durant les tâches mono-proc, les processeurs idle faisait des prefetch pour le caches L3 !), les SPARC64 ne sont toujours pas disponibles.
Un CPU CISC aura besoin d'une seule instruction (donc d'un cycle) pour effectuer une divison tandis que le RISC aura besoin de 50
RISC:
- On veut un cycle par instruction.
Mouais, sauf quand c'est pas le cas : genre les instructions fpu sparc qui prenne 3 cycles par instructions.
Il reste juste 2 choses : mots d'instructions de taille fixe (pour simplifer le decode et le fetch), nombre de cycles par instructions de durés fixes (évite des microcodes à la mord moi le noeud)
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 2.
Tu ne peux que gaspiller de la puissance dans la gestion des thread et le traching de mémoire cache en faisant plus compliqué.
Tu aura peut-être plus de puissance pour tenir des deadline à 500 images/s mais ce n'est pas ça que l'on demande au codec.
"La première sécurité est la liberté"
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 3.
Il est donc parfaitement inutile de programmer un thread pour ça.
De plus, lors d'acces io, si le temps est trop long, le scheduler peut décider de donner la main à un autre process (cela se voit facilement avec l'utilisation d'un lentissime printf). Tu ne perds donc aucun cycle.
Si ta machine ne fait qu'une seule tache, un monothread sans io non bloquante étant bloqué à chaque io, tu perds des perf sur ce process-là uniquement. Mais globalement, ta machine peut faire d'autres trucs. Il n'y a pas de gaspillage.
Si tu veux augmenter les perf c'est-à-dire parraléliser acces disque et calcul, et bien, les io asynchrones ou non bloquantes sont faites pour ça !
"La première sécurité est la liberté"
[^] # Re: Juste une question ...
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 0.
1/ Pour faire, la même tâche si tu utilises 2 threads au lieu d'un seul tu perds des cycles à passer de l'un à l'autre. Si TUX (serveur http noyau) déchire, c'est parce qu'il fait de la zero copie et qu'il n'a PAS un thread par utilisateur. Sur un monoprocesseur, à cause des changement de tâche, tu perds du temps. Si quelqu'un lance un gros boulot, le scheduler doit juste scheduler un thread de plus. Cela ne lui fait que perdre du temps.
Sur un bi-pro (ou SMT), tu repartis la charge, genre 2% sur chaque cpu. Or les partages de mémoire font que les caches sont sous utilisé (en SMP) mais pas en SMT. Or en SMT, si des optimisations typé SMP sont utilisé (grosse séparation des flux mémoire pour éviter de trasher les caches) la pression sur les caches devient énorme (les caches miss s'envole aussi). Les optimisations SMT/SMP sont antagonistes sur la gestion des caches.
2/ Vu que l'ordonanceur à un process/thread de plus à traiter, tu le ralentie. Si tu est sur un bi-pro, dans le cas monothread, un cpu est libre donc le temps de réponse est minimal à un événement extérieur. Ce n'est absoluement pas le cas en multi-thread.
3/ Tu tire mieux parti d'un bi-pro certe mais au détriment du temps de réponse. Tu ne fais que perdre du temps sur un monoprocesseur. Le design est bien plus complexe à maintenir. Cela semble sans doute plus propre pour un serveur mais du point de vue performance c'est pas terrible du tout.
Parce qu'il faut bien se souvenir que les x% de cycles CPU utilises par mplayer pendant un moment donne(et qui auraient pu etre utilise avant quand il n'y avait pas urgence) sont x% de cycles que les autres softs ne peuvent pas utiliser, et peut-etre qu'ils en auraient besoin eux.
A tache égal, un multithread prendra toujours plus de cycle globalement qu'un monothread. Donc, je ne comprends pas ce que tu veux dire.
"La première sécurité est la liberté"
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 2.
En général cela tourne autour du nombre de bits même en entier.
"La première sécurité est la liberté"
[^] # Re: L'intérêt de la fréquence
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 1.
Les techno SMT sont beaucoup plus finaudes que ça.
En fait, les process sont également utilisé pour combler les bulles dans chacun des 5 pipelines d'execution. C'est pour cela que le gain de vitesse max , se fait avec un process utilisant le nombre flottant et l'autre les nombres entiers.
"La première sécurité est la liberté"
[^] # Re: N'importe quoi
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 1.
C'est cette expression qui m'a enduit d'erreur. Je croyais que tu parlais d'outils informatique.
On parle de finesse de gravure, de largeur de grille mais pas de finesse des outils de gravures (il n'utilisent pas des burrins de 0.09µm...). :)
"La première sécurité est la liberté"
[^] # Re: N'importe quoi
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 1.
Augmenter la fréquence pose parfois des problèmes, car elle nécessite des outils de gravure de plus en plus affinés, qui ne sont pas forcément disponibles.
Euh, pour une techno donné le temps de parcoure d'une porte est fixe. Tu peux mettre plein de portes en parrallèle (ipc monte), moins de porte entre 2 registres (pipeline, frequence monte), ou refaire le routage (moins de temps perdu dans les fils, la fréquence monte).
Ou changer de techno. Il n'y a pas de problème d'outils, c'est bettement physique (la NAND elle a besoin de 15 ps, il ira pas plus vite en changeant d'outils).
"La première sécurité est la liberté"
[^] # Re: N'importe quoi
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 1.
si. L'utilisation de décodage puis de micro instruction, aussi. Mais il ne s'agit pas de mettre un risc derrière le décodeur (cela plutot ressembler à un vliw d'ailleurs).
>(un code ARM thumb est bien plus gros que du code "normal" x86)
J'ai vu ça dans un comparatif de compilation de différent fichier .c, puis gzipper comparant ARM (compilo arm et gcc), x86, Sparc (Leon).
Je dis "normal" pour le x86, car il utilisait -02 au lieu de -0s comme switch pour gcc. Et la différence était assez importante.
"La première sécurité est la liberté"
[^] # Re: Une nouvelle mesure: MLCPS
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 1.
Car linux ne se compile QUE avec gcc et gcc ne se compile qu'avec gcc (il me semble) et c'est le seul programme qui ne compile qu'avec -02 -g que j'ai vu.
D'ailleurs le bench peut être : compile de linux 2.4.18 avec tel .config avec gcc 3.2.0.
"La première sécurité est la liberté"
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Parce que velu ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi tant de haine.. Évalué à 0.
Vala, tu as participé à un projet.
"La première sécurité est la liberté"
[^] # Parce queeeeeeeeeeeeeee
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi tant de haine.. Évalué à 1.
C'est le seul site de ll en français où y'a du monde ?
Y'a linux dans le titre : " Et Linux : c'est bien".
Les connaissances, c'est comme la confiture,... on aime bien l'étaler (ça m'arrange mieux cette version).
Sinon...
"La première sécurité est la liberté"
[^] # Et hop ! Le gros troll récurent ....
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Gnu/Linux Magazine n° 46 est paru. Évalué à 2.
C'est pas possible de satisfaire tout le monde ! Moi, non plus je ne lis pas la partie blender, et alors ?
Je comprends que cela peut interresser du monde !
"La première sécurité est la liberté"
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 2.
Mais tu as mal lu, il est question de latence de pipeline !!!! L'addition se fera toujours en un cycle.
"La première sécurité est la liberté"
[^] # Re: Pourquoi tant de haine.
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi tant de haine.. Évalué à 1.
Si cela te touche, c'est bien le problème, non ?
Il est vrai que beaucoup de commentaires ont peu d'intérêt mais est-ce que parce l'on a rien a dire, il se taire ? Ca fait aussi parti de l'ambiance du site.
C'est l'unique interret des votes : faire un trie !!!
Si tu veux lire rapidement la news, tu ne peux pas toujours lire les 200 commentaires qui suivent.
"La première sécurité est la liberté"
[^] # Re: Une nouvelle mesure: MLCPS
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 2.
Sauf qu'il est dédié à la plateforme x86. Il faudrait un gros programme qui n'a pas de #define en fonction de sa plateforme pour en faire un vrai bench.
"La première sécurité est la liberté"
[^] # Re: N'importe quoi
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 1.
Yep parce que les processeurs RISC n'ayant pas encore les poids des années et de la compatibilité n'en avait pas (encore) besoin.
Lorsque l'alpha à eu un core OO, il a pris 45 millions de transistors en +...
Il faut aussi préciser que, au delà des jeux d'instructions proprement dits, les processeurs actuels du monde x86 sont des RISCs qui se cachent : en effet, tous incorporent en réalité une étape de décodage des instructions x86 en micro-instructions de type RISC, plus faciles à éxécuter dans le désordre.
microinstruction, microcode, s'est pareil ! je persiste à insister : RISC/CISC qualifie le jeu d'instruction pas leur implémentation !
Cet discussion CISC contre RISC n'a plus aucun sens de nos jours. Elle n'incorpore même pas les jeux d'instruction VLIW qui commencent à apparaitre avec les processeurs de Transmeta ou l'Itanium d'Intel.
Yep ! Les dsp TI aussi (vliw 8 voix)
"La première sécurité est la liberté"
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 0.
Tu parles de quoi là, CISC ou RISC ?
C'est généralement vrai en RISC. C'est plus rarement vrai en CISC.
Un instruction peut prendre 30, 40, 50 cycles si elle est complexe.
Div flottant ou sin qui n'existe pas en RISC en général.
De plus, les opérations de base prenne presque toujours plus d'un cycle d'horloge.
Heureusement que non !
"La première sécurité est la liberté"
[^] # Re: L'intérêt de la fréquence
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 1.
Pas forcément, car le bus mémoire ne change pas de vitesse (en général). Les P4 1,5 Ghz ou 3,06Ghz utilisent tous de base la RDRAM 800. Cela m'étonnerait que le 3,06 soit 2x plus rapide que le 1,5Ghz (sans tenir compte de l'hyperthreading évidement).
"La première sécurité est la liberté"
[^] # Re: N'importe quoi
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 1.
Je considérais que 20% des instructions prennait 80% des ressources hardware comme dans l'exemple
ADD [r1 +r2 +8] [r2+r3 +4]
M'enfin, c'est l'idée.
"La première sécurité est la liberté"
[^] # Re: N'importe quoi
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 4.
ça c'est du buz word. C'est l'ISA qui est CISC pas le processeur ! Car dans ce cas des processeurs RISC ont des coeurs CISC (cf DLX) !
des améliorations "CISC" comme la mémoire cache ou la prédiction de branches pour gagner en performances.
gni ? le rapport avec la choucroute ? RISC/CISC qualifie l'ISA pas la microarchitecture !
(la réalité est d'ailleurs que le SIMD vient du monde des DSP).
Perdu ! Cela vient des supercalculateurs "vectoriels" comme les Cray.
La distinction RISC/CISC se trouve encore dans le petit "embarqué". Les RISC se prêtent bien au "pipelining" des instructions contrairement au CISC.
C'est vrai.
On gagne donc en nombre d'instructions par cycle tout en gardant la même fréquence (5 - 30 Mhz) et presque la même consommation électrique (et c'est très IMPORTANT dans l'enfoui).
La phrase est ambigüe. Disons qu'à complexité égal, un processeurs RISC monte à plus haute fréquence (souvenez vous des premiers alpha).
Pour la consomation élèctrique, il y a d'autres facteurs qui rentre en jeu.
Le nombre élevé de registres dans le RISC est un plus dans la course au performance puisque on limite les accès mémoires dans des boucles de calculs.
C'est la conséquence du gain de place que l'on a en virant l'inutile. Mais ce n'est pas réservé au RISC. Il suffit de voir les nouveaux DSP texas qui ont des instructions, 16 32 48 bits... pour gagner en taille de code (un code ARM thumb est bien plus gros que du code "normal" x86).
"La première sécurité est la liberté"
# Re: Pourquoi tant de haine.
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi tant de haine.. Évalué à 2.
Tu t'es planté, ton commentaire ne vaut en effet rien. Mais il n'est question que du commentaire.
"La première sécurité est la liberté"
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 7.
"La première sécurité est la liberté"
[^] # Re: N'importe quoi
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 10.
Les CISC sont à prioris plus lent car il consacre + de silicium à des trucs pas vraiment utile contrairement au RISC (nue règle de 80-20, vaux mieux optimiser à fond 80% des instructions les plus utiliser que ce faire chier avec les 20% restant complexe et qui ralentissent tout)
M'enfin, les x86 déchirent tous en ce moment. Les Power 4 trichent au specint (durant les tâches mono-proc, les processeurs idle faisait des prefetch pour le caches L3 !), les SPARC64 ne sont toujours pas disponibles.
Un CPU CISC aura besoin d'une seule instruction (donc d'un cycle) pour effectuer une divison tandis que le RISC aura besoin de 50
L'exemple est mal choisi mais c'est l'idée.
En CISC tu peux faire:
ADD [R1 + R2 + 8] [R2 + R3 + 4] (opération mémoire mémoire)
En RISC, tu auras :
ADD R1 R2 R4
ADD R4 #8 R4
ADD R2 R3 R5
ADD R5 #4 R6
LOAD [R5] R7
LOAD [R6] R8
ADD R7 R8 R9
STORE R9 [R6]
Mais personne n'utilise ses adressages complexes.
RISC:
- On veut un cycle par instruction.
Mouais, sauf quand c'est pas le cas : genre les instructions fpu sparc qui prenne 3 cycles par instructions.
Il reste juste 2 choses : mots d'instructions de taille fixe (pour simplifer le decode et le fetch), nombre de cycles par instructions de durés fixes (évite des microcodes à la mord moi le noeud)
nicO, f-cpuer
"La première sécurité est la liberté"