#ifdef troll Soit dit en passant, le cl livré avec VS6 n'est même pas c++ ansi. Essaie donc de compiler ça : for (int i = 0 ; i < 3; i++) cout <<i; for (int i = 0 ; i < 3; i++) cout <<2*i; Il te dira que i est défini deux fois, et refusera de compiler. Alors que le c++ ansi dit clairement que sorti du for, i n'est plus définie #endif
pour GCC et VS : http://www.osnews.com/story.php?news_id=5602&page=3, première page sous google, mais si tu en trouves d'autres prouvant le contraire, je veux bien jeter un coup d'oeil - et n'oublions pas non plus les programmes que gcc ne compile pas... ou Code Warrior, ... -
spectras :
Je n'ai pas dit du mal du RISC. Je sais parfaitement que pour des applications temps réel type traitement de vidéos, les DSP sont incontournables, et que les x86 ne sont pas du tout faits pour ça.
Ce que je dis, c'est que les x86 ne s'orientent pas du tout vers une architecture RISC. Au contraire, on assiste à une démultiplication du nombre d'instructions, et des instructions de plus en plus complexes. Quand au pipeline, faut même pas espérer.
Franchement, quand tu regardes les nouvelles instructions, par exemple PMULUDQ tu vas pas me dire que on s'oriente vers justement cette orthogonalité caractéristique des RISC ?
croustx :
De la part de Mr Kofler, via mini-message :
pour GCC et VS : http://www.osnews.com/story.php?news_id=5602&page=3, première page sous google, mais si tu en trouves d'autres prouvant le contraire, je veux bien jeter un coup d'oeil - et n'oublions pas non plus les programmes que gcc ne compile pas... ou Code Warrior, ... -
Le bench est mauvais. Cf.:
http://gcc.gnu.org/ml/gcc/2004-02/msg00704.html
http://gcc.gnu.org/ml/gcc/2004-02/msg00706.html
http://gcc.gnu.org/ml/gcc/2004-02/msg00716.html
Il y a du pipeline, tu ne lis pas les news ? il y a 20 niveaux sur le P4, et s'il n'y avait pas de pipeline, ça serait trop trop lent..
Et le x86 se tourne vers le RISC, je suis désolé, c'est d'ailleurs logique, ça fait quand même 20 ans qu'on sait que c'est mieux que le CISC et que x86 était les derniers à être en RISC... Certaines instructions ne sont typiquement par RISC, je n'ai pas dit le contraire, mais seulement que la majorité des instructions utilisées actuellement font partie de l'ensemble optimisé genre RISC.
En même temps, on utilise des DSP pour des applis particulières tout en sachant que les PCs pourront le faire dans les années qui suivent - d'ailleurs, certains PCs arrivent à faire du traitement vidéo à la volée... -
Kevin: Sauf que si tu as un compilateur auto-vectorisant (branche de développement tree-ssa-lno de GCC, ou alors celui d'Intel), le compilateur utilise ces instructions tout seul.
spectras
:Il y a du pipeline, tu ne lis pas les news ? il y a 20 niveaux sur le P4, et s'il n'y avait pas de pipeline, ça serait trop trop lent..Euh, le pipeline dont tu parles est celui du fetching des instructions. Je parle du pipelining de l'exécution des instructions, qui permet aux RISC d'exécuter plusieurs instructions simultanément (mais pas en parrallèle, me faites pas dire ce que j'ai pas dit).
Et le x86 se tourne vers le RISC, je suis désolé, c'est d'ailleurs logique, ça fait quand même 20 ans qu'on sait que c'est mieux que le CISC et que x86 était les derniers à être en RISC... Certaines instructions ne sont typiquement par RISC, je n'ai pas dit le contraire, mais seulement que la majorité des instructions utilisées actuellement font partie de l'ensemble optimisé genre RISC.Ce n'est pas optimiser les instructions simples qui vont créer une architecture RISC. Les instructions simples tu en as forcément dans les CISC. On ne peut pas se passer de la la lecture mémoire. Le point important, c'est que même les instructions élémentaires du x86 sont déjà très complexes par rapport aux instructions RISC. Par exemple, les instructions comme add, sub, inc et même mov sont capable d'aller lire en mémoire et y écrire, dans le même instruction, ce qui est impensable pour une architecture RISC.
En même temps, on utilise des DSP pour des applis particulières tout en sachant que les PCs pourront le faire dans les années qui suivent - d'ailleurs, certains PCs arrivent à faire du traitement vidéo à la volée... -
Hum, sur des DSP cadencés à seulement quelqes centaines de MHz, on fait de la compression MPEG temps réel ou de la détection de contour, le tout en 25images/seconde sans problème. Le p4 n'en est pas encore là.
Les RISC exécutent une instruction en 4 temps en général, il n'y a pas de pipeline à ton sens du terme dans ces archi, on exécute l'instruction en même temps qu'on en fetch une autre, qu'on récupère des données en mémoire et qu'on sauvegarde les registres, ... Si l'ALU fait son calcul en 1 seul cycle, on ne peut pas "pipeliner" ça...
Ce n'est pas optimiser les instructions simples qui vont créer une architecture RISC. Les instructions simples tu en as forcément dans les CISC. On ne peut pas se passer de la la lecture mémoire. Le point important, c'est que même les instructions élémentaires du x86 sont déjà très complexes par rapport aux instructions RISC. Par exemple, les instructions comme add, sub, inc et même mov sont capable d'aller lire en mémoire et y écrire, dans le même instruction, ce qui est impensable pour une architecture RISC.
Jette un coup d'oeil à l'ARM11, et regarde la puissance d'une instruction. le Pentium ne fait parfois la même chose qu'en une centaine de cycles.
Faudra que je te présente à mon PC alors, et c'est pas un P4, mais la compression MPEG en temps réel, il connaît assez bien.
spectras
:Les RISC exécutent une instruction en 4 temps en général, il n'y a pas de pipeline à ton sens du terme dans ces archi, on exécute l'instruction en même temps qu'on en fetch une autre, qu'on récupère des données en mémoire et qu'on sauvegarde les registres, ... Si l'ALU fait son calcul en 1 seul cycle, on ne peut pas "pipeliner" ça...
pipeline d'exécution. Le truc qui fait qu'une instruction en est au fetch tandis qu'une autre en est au decode, la précédente au calcul, celle d'encore avant enregistre son résultat, et la plus vieille fait son writeback. => et ça, les x86 ne le font pas, parce que leur jeu d'instruction ne s'y prête pas et ne peut pas s'y prêter
Ce n'est pas optimiser les instructions simples qui vont créer une architecture RISC. Les instructions simples tu en as forcément dans les CISC. On ne peut pas se passer de la la lecture mémoire. Le point important, c'est que même les instructions élémentaires du x86 sont déjà très complexes par rapport aux instructions RISC. Par exemple, les instructions comme add, sub, inc et même mov sont capable d'aller lire en mémoire et y écrire, dans le même instruction, ce qui est impensable pour une architecture RISC.
Jette un coup d'oeil à l'ARM11, et regarde la puissance d'une instruction. le Pentium ne fait parfois la même chose qu'en une centaine de cycles.
Là je vois plus le rapport. Tu reviens sur "RISC est plus efficace", ce sur quoi je ne t'ai jamais contredit. Ce que je dis c'est que les x86 ne sont pas des RISC et ne sont pas près de le devenir.
Faudra que je te présente à mon PC alors, et c'est pas un P4, mais la compression MPEG en temps réel, il connaît assez bien.Tu sais très bien que pour faire du traitement du signal, rien ne vaut un bon DSP. Prends un DSP cadencé pareil que ton pc, je te garantis qu'il compressera plus vite. Ca marche aussi pour la détection de contours, le suivi d'objets, etc.
Nil :
Rahhh quel régal, je n'ai jamais vu autant de débats hautement Trollistiques depuis longtemps, ici...
LizDog
:Nil :Le pire c'est que je suis quasi certain que Miles a raison ^^
Rahhh quel régal, je n'ai jamais vu autant de débats hautement Trollistiques depuis longtemps, ici
A quoi ça sert de pipeliner les cycle fetch si tu ne peux rien accélérer derrière ?
, parce que c'est précisément là que se fait la différence entre l'optimisation d'une archi totalement pipelinée (à base de RISC) et une archi ou le "pipeline" ne sert qu'à préfetcher les instructions, comme pour les x86.
)
./68> l'x86 étant maintenant basé sur une architecture plus RISC que CISC
Si c'était aussi simple, on aurait des DSPs dans nos PCs, non ? Relis bien, j'ai dit que ce qu'un DSP pouvait faire maintenant, au pire un PC le fera dans qqs années - à la loi de Moore près, si elle marche encore -
L'incohérence à part,
Ximoon
: Tu peux faire ce que tu veux sur un DSP évidemment, mais bon à la base c'est quand même conçu pour faire du traitement du signal ...
Ximoon :
Qu'est-ce que j'en sais moi? J'suis pas un troll, je fais pas semblant de savoir
en fait, les dernières instructions rajoutées sur l'ISA x86 servent à quoi - SSE, 3DNow? - ?
L'intérêt du calcul //... A la base, il n'y a pas de calcul parallèle sur les DSP
Ah oui, un DSP ne sert pas qu'à faire du signal, il y a bien des OS qui tournent dessus, alors pourquoi pas le reste - ah oui, zut, c'est déjà possible... - C'est peut-être simplement trop cher pour le gain de performances recherché...
) , ou du traitement d'images, ou pour les effets spéciaux dans les films. C'est pas non plus un hasard si Mac est réputé pour être une bonne plateforme multimédia, utilisation et création.
spectras
:en fait, les dernières instructions rajoutées sur l'ISA x86 servent à quoi - SSE, 3DNow? - ?
Oui.
Cela dit, ces nouvelles instructions nous éloignent encore plus de la philosophie RISC, en introduisant des instructions SIMD loin d'être élémentaires.
Ximoon :
Moi je programme mon pti dsp TI, et ça m'suffit
spectras
:en fait, les dernières instructions rajoutées sur l'ISA x86 servent à quoi - SSE, 3DNow? - ?
Oui. Cela dit, ces nouvelles instructions nous éloignent encore plus de la philosophie RISC, en introduisant des instructions SIMD loin d'être élémentaires.
L'intérêt du calcul //... A la base, il n'y a pas de calcul parallèle sur les DSP
Hum, je relis mon propre post, dans le doute, et je lis : "Je parle du pipelining de l'exécution des instructions, qui permet aux RISC d'exécuter plusieurs instructions simultanément (mais pas en parrallèle, me faites pas dire ce que j'ai pas dit)."
'tention, pas calcul parallèle au sens où on l'entend d'habitude, ie "avoir deux lignes de traitement parallèles", mais simultané, au sens "pendant que l'ALU fait mon calcul, je vais prendre un peu d'avance". Je crois que le vrai terme pour ça est le recouvrement d'instructions. Et ça, dans les années 70 ça existait déjà. C'est inhérent à l'architecture même des RISC.
Ah oui, un DSP ne sert pas qu'à faire du signal, il y a bien des OS qui tournent dessus, alors pourquoi pas le reste - ah oui, zut, c'est déjà possible... - C'est peut-être simplement trop cher pour le gain de performances recherché...Tu reliras mon post précédent cette réplique, et tu pourras remarquer que je n'ai pas dit qu'il était impossible de faire tourner un OS et des applications telle que de la bureautique sur un DSP. Juste que ce n'était probablement pas un choix approprié.
J'ai pas dit que c'était pas possible. Les RISC sont des processeurs, après tout (et généralement bien conçus d'ailleurs). Le point important est que l'architecture RISC n'a rien à apporter à un OS ou à des applications comme la bureautique. Son domaine de prédilection est le calcul, le traitement du signal (donc video, son, image, etc...), ...
D'ailleurs, la majorité des endroits où les RISC sont employés aujourd'hui sont pour les DSP (évidemment), et pour les stations de travail (genre pour faire du modelsim sous HP-UX (le routage c'est bien) , ou du traitement d'images, ou pour les effets spéciaux dans les films. C'est pas non plus un hasard si Mac est réputé pour être une bonne plateforme multimédia, utilisation et création.
LizDog
:spectras
:en fait, les dernières instructions rajoutées sur l'ISA x86 servent à quoi - SSE, 3DNow? - ?
Oui.
Cela dit, ces nouvelles instructions nous éloignent encore plus de la philosophie RISC, en introduisant des instructions SIMD loin d'être élémentaires.
Tiens un truc etrange, pourquoi alors les PowerPC qui sotn des processeurs RISC on eu l'obligeance de voir un DSP integré ? (Altivec dans les G4)
etarnge non ?
Au passage les Macintosh ne sont pas réputé pour etre une bonne plateforme multimédia, mais réputé puor etre une bonne plateforme pour ce sui concerne l'edition
D'ailleur je vois pas le rapport entre le processeur et la facilité/faculté d'édition
...
