Il y a une constante qui est sur et certaine. J'ai déjà du le dire. Cette affirmation sera vrai à tout jamais, car elle définie le 1 en C++ (et peut-être même en C)Envoyé par BainE
sizeof(char) vaudra toujours 1.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Il y a une constante qui est sur et certaine. J'ai déjà du le dire. Cette affirmation sera vrai à tout jamais, car elle définie le 1 en C++ (et peut-être même en C)
sizeof(char) vaudra toujours 1.
Il existe d'autres mondes que celui du x86 ...Je me trompe peut être, mais cela fait bien longtemps que les bus de données et tailles des registres correspondant sont en 64bits (cf premier pentium).
Lorsque l'on parle en ce moment de processeurs et d'os 64 bits on parle du bus d'adresses uniquement donc la seul chose qui va changer sera la taille des pointeurs et donc les accès mémoires.
Les perfs de calculs et la gestion des types de bases n'en seront pas changés pour autant. La seul chose qui peut éventuellement changer c les performances des accès mémoires et le cast de pointeur en entier 32bits qui ne marcheras plus !
Mais comme je dis je peux me tromper
Parmis ceux-ci certains sont déjà en 64 bits depuis des années...
Noooon 8)
exemples ?
Sinon, dans le cas spécifique du x86 quelqu'un a t il l'info sur la dimension des différents registres en bus en fonction du processeur (Pentium et athlon toutes versions) ?
Je ne saurais mettre de dates, mais le passage au 64 bits pour les Alpha, Mips, Sparc, POWER c'est les annees 90. (l'ordre est celui dans lequel je pense le 64 bits a ete disponible).exemples ?
J'ai une sparc 64 bits sur mon bureau depuis pas mal de temps. Suffisamment longtemps pour que je ne puisse pas mettre de date.
Pour faire du mauvais esprit je dirais que les x86 sont dans les derniers à virer au 64bits.
http://www.intel.com/ et http://www.amd.com/us-en/Sinon, dans le cas spécifique du x86 quelqu'un a t il l'info sur la dimension des différents registres en bus en fonction du processeur (Pentium et athlon toutes versions) ?
En ce qui concerne les performances je n'ai que des liens qui datent. Par exemple :
http://www.x86-secret.com/popups/art...dow.php?id=118
Personellement je retiens surtout le gain non négligeable sur Povray
C'est domage de ne rien avoir de plus récent mais la situation n'a peut-être pas trop évolué depuis (Windows 64bits n'est pas vraiment denenu la norme).
Il faudra que je me décide à installer un Linux 64bits pour voir.
D'un autre coté on en avait pas vraiment besoin avant vu que ce n'est que récement que l'on peut acheter plus de 4Go de mémoire pour un prix raisonnable.
Le gros problème étant évidement de passer windows en 64 bits, ca va merder de partout
L'utilisation du 64 bits n'est pas particulierement du cote des particuliers -- ou la je ne vois gere que le montage video comme application ayant besoin de tant de memoire.
Et cela fait un certain temps deja qu'on peut acheter des systemes a base de x86 avec plus de 4GiB de memoire meme si les processus sont limites a 4GiB architecturellement et souvent moins car les OS generalement en utilisent une partie.
--
Jean-Marc
Oui on pouvait rajouter plus de 4Go, mais c'est quand même une grosse limitation de ne pas pouvoir avoir un processus qui en utilise plus. Cela obligerai d'introduire des processus pour une raison qui me parait artificielle (si on a besoin de + de 4Go pour ses données).
Je suis aussi très dubitatif sur l'intéret du 64bits, d'un autre coté l'évolution technique des x86 n'a jamais été raisonnaible ... mais plus marketing. Et si on me dit que je peut acheter un 64 pour le prix d'un 32. Pourquoi pas ?
D'accord, mais je repondais a l'affirmationcela fait longtemps qu'il y a des machines avec plus de 4 GiB de memoire physique. Depuis l'invention de la memoire virtuelle, jouer sur la difference entre memoire physique et memoire mappee a toujours ete le moyen de s'en sortir tant qu'on ne voulait/pouvait pas augmenter l'espace d'adressage et qu'on avait besoin de plus de memoire physique.ce n'est que récement que l'on peut acheter plus de 4Go de mémoire pour un prix raisonnable
On peut aussi jouer avec le mapping (mapper des fichiers en memoire et les demapper en esperant -- en demandant si possible -- que l'OS ne fasse pas de transfert vers les disques, c'est apres tout ce qu'on fait deja -- mais l'OS s'occupe de tout -- avec la memoire virtuelle).Cela obligerai d'introduire des processus pour une raison qui me parait artificielle (si on a besoin de + de 4Go pour ses données).
Pour qui? Nos clients sont bien heureux de pouvoir lancer des versions 64 bits de nos outils, meme s'ils preferent les versions 32 bits car plus rapides (ce qui nous pousse a gerer la memoire d'une maniere impossible avec un GC d'ailleurs -- je suis pour l'introduction d'un GC optionnel en C++, mais je m'opposerais a ce qu'on le rende obligatoire, mais bon personne n'y pense -- pour augmenter la taille traitable en 32 bits).Je suis aussi très dubitatif sur l'intéret du 64bits,
Mon prochain ordi perso (date d'achat vraissemblable: vers Noel cette annee ou l'anne prochaine) sera 64 bits pour la raison que ce ne vaudra pas la peine de chercher a rester en 32 bits. Mais il est vraissemblable aussi que le fait que ce soit du 64 bits ne me servira que pour verifier que mes programmes perso ne dependent pas de cela... pas important du tout.d'un autre coté l'évolution technique des x86 n'a jamais été raisonnaible ... mais plus marketing. Et si on me dit que je peut acheter un 64 pour le prix d'un 32. Pourquoi pas?
C'est vrai je parlais surtout d'un point de vue personnel j'aurais du le préciser. D'un autre coté il existe déjà des 64bits et souvent avec une conception du processeur plus intéressante. Mais maintenant que le rouleau compresseur du marché x86 est en marche vers le 64bits, je ne donne pas cher des familles alternatives de processeurs en 64bits. Qui étaient déjà pas mal moribond il est vrai.
C'est vrai que c'est sympa. Mais tant que l'os et les drivers ne supporte pas a fond les novueau proc ca risque pas d'aller bcp plus vite.
Le 64 bits ne permet pas d'aller plus vite, generalement c'est plus lent ne fut-ce que parce que ca eleve la pression sur les caches.
pourquoi ca eleverait la pression sur les caches, sauf si mots de la cache sont en 64 bits , la oui, sinon ca serait plus rapide, et meme si ce n'est pas le cas, le goulet d'etranglement entre la processeur et la RAM c'est le Bus
donc ca permettra de prendre avantage de la vitesse du processeur qui est etait toujours reduire par la vitesse du Bus, car on pourra transferer le double ( si les mots sont en 32 bits dans la cache)
et meme au niveau du codage des instruction, meme si on ajoute pas dans la longueur des instruction on peut prendra avanta a coder deux instruction dans le meme
je ne connais pas en detail leur architecture complete car dire 64Bit , c'est pourquoi en fin ?
Bus, registres, caches, instruction?
Dans un programme compile en 64 bits, un certain nombre de types ont besoin de plus de memoire (en particulier les pointeurs qui font maintenant 64 bits, traditionnellement les long aussi, mais MS a decide de ne pas suivre cette tradition). Donc pour representer la meme quantite de donnees, soit tu utilises une version speciale avec des structures plus compliquees, soit tu as besoin de plus de memoire.
Je ne comprends pas grand chose a ce que tu as ecrit ci-dessus.sauf si mots de la cache sont en 64 bits , la oui, sinon ca serait plus rapide, et meme si ce n'est pas le cas, le goulet d'etranglement entre la processeur et la RAM c'est le Bus donc ca permettra de prendre avantage de la vitesse du processeur qui est etait toujours reduire par la vitesse du Bus, car on pourra transferer le double ( si les mots sont en 32 bits dans la cache)
et meme au niveau du codage des instruction, meme si on ajoute pas dans la longueur des instruction on peut prendra avanta a coder deux instruction dans le meme
Les caches ne sont pas divises en mots mais en ligne qui font plus que 32 ou 64 bits.
Quand tu parles "du" bus, je me demande de quel bus il s'agit.
La taille du bus sur lequel s'effectue des transferts entre les caches et la memoire n'a pas de rapport avec le nombre de bits du processeurs (pour preuve, cette taille ne change pas que les processeurs soient utilises en mode 32 ou 64 bits).
Classiquement en architecture des ordinateurs il s'agit de la taille des registres a usage general. Ca devient plus confu dans les architectures ou il n'y a pas des registres a usage general (adresse, index, donnee entiere, donnee flotante) de longueurs differentes ou alors on a tendance a considerer les registres de donnees entieres. Certains ont utilises des considerations de micro-architectures (genre taille du bus interne) mais c'est loin d'etre la norme et ce n'est guere utile car ce n'est pas observable par le programmeur.je ne connais pas en detail leur architecture complete car dire 64Bit , c'est pourquoi en fin ?
Bus, registres, caches, instruction?
mais en general la taille des lignes de la cache est egales au registres generaux
je voulais dire que le Bus de transfert entre le processeur et la RAM qui est toujours a 500 ou 433 Mhz represente le goulet d'etranglement pour le processeur, car meme a 4 GHZ et le bus qui travaille a 433Mhz le processeur sera toujours penalise par cela
Les caches ne sont pas divises en mots mais en ligne qui font plus que 32 ou 64 bits.
Quand tu parles "du" bus, je me demande de quel bus il s'agit.
je ne parle pas de taille mais de vitesse
je crois que l'architecture ne changera pas grand chose du point de vue software (developemment) mais permettra d'ameliorer les architectures hard et ainsi rendre l'execution plus rapide, je ne crois pas qu'on puisse voir cela a haut niveau, c'est comme les pipelines, dans nos programmes on ne specifie pas que ca doit tourner sur une architecture a pipeline ou pas, mais c'est plustot un truc d'optimisation hardware
Attention, même si le bus est à 400MHz, ça ne veut pas dire qu'il n'y a que 400 bits/sec qui sont transférés
Par exemple chez Intel, c'est un FSB à 200MHz QuadPumped, ce qui veut dire qu'il est équivalent à un bus de même taille à une fréquence de 800MHz qui ne fonctionne que sur front montant. Donc avec une largeur de bus de 32bits, on fait du 3.2Go/s, c'est lent, OK, mais c'est pas mal.
Chez AMD, c'est du même tonneau entre la mémoire et le CPU, c'est plus lent entre processeurs sur des puces différentes - opteron bi-processeurs par ex - car le bus Hyper-Transport à 1GHz est en 16bits, donc ça ne fait que 2Go/s. Mais bon, le goulot est avant
Donc on garde le même débit avec des données 2 fois plus longues. On a des risques de baisse de perf, c'est clair.
Dans les caches que j'ai regardes que les lignes sont de 64 ou 128 octets. Pour une taille (en octets) de cache fixee, avoir des lignes plus courte est meilleur d'un point de vue frequence avec lequel les donnees se trouvent dans le cache, mais malheureusement il y a deux effets qui contrebalance cet avantage: il faut des memoires associatives avec plus de cles (donc des delais plus interessant), on profite moins des transferts en blocs (donc on pert de la bande passante avec le niveau de cache superieur, ou avec la memoire).
Le processeur sera toujours ralenti quand il veut des donnees hors cache (ou meme dans le cache de niveau 2). On ne sait simplement pas faire des memoires de grande taille fonctionnant a cette vitesse, quelque soit le prix qu'on soit pret a mettre. On peut faire des memoires plus rapides que celles qu'on utilise, mais le prix est prohibitif.je voulais dire que le Bus de transfert entre le processeur et la RAM qui est toujours a 500 ou 433 Mhz represente le goulet d'etranglement pour le processeur, car meme a 4 GHZ et le bus qui travaille a 433Mhz le processeur sera toujours penalise par cela
Je ne comprends a nouveau pas ce que tu veux dire.je crois que l'architecture ne changera pas grand chose du point de vue software (developemment) mais permettra d'ameliorer les architectures hard et ainsi rendre l'execution plus rapide, je ne crois pas qu'on puisse voir cela a haut niveau, c'est comme les pipelines, dans nos programmes on ne specifie pas que ca doit tourner sur une architecture a pipeline ou pas, mais c'est plustot un truc d'optimisation hardware
L'architecture, c'est en premiere approximation ce que voit le programmeur en assembleur (on ne tient pas compte de l'aspect temporel d'une part, de la configuration -- quantite de memoire installee, peripheriques presents, ...).
Les progres en possibilite d'integration d'une part, en techniques de micro-architecture (autrement dit, ce que voit le concepteur du processeur) d'autre part font que l'avantage architectural des RISC sur les CISC a quasiment disparu (en gros les CISC sont devenus des RISC qui interpretent le jeu d'instruction CISC avec un interpreteur hard, le cout de cet interpreteur est devenu negligeable; enfin, c'est vrai pour le x86; il y a des CISC -- le VAX par exemple -- ou les techniques connues ne suffiraient pas).
La largeur de l'architecture n'a quasiment aucun rapport avec la largeur du bus de donnee vers la memoire externe; particulierement en presence d'un cache. On a vu toute les configurations possibles.
Répondre avec citation
Partager