[Espace mémoire] - pointeurs sur 4 octets

Salut à tous,

En C ou en C++, si on prend un pointeur (sur n'importe quel type) et qu'on détecte sa taille, par exemple:

int* ptr=0;
cout << sizeof(ptr) << endl;

On obtient 4, donc 4 octets de mémoire. J'en déduis qu'un pointeur est un peu comme un unsigned int, pointant sur le premier octet de la mémoire s'il est égal à 1, sur le 2ème octet de la mémoire s'il est égal à 2, et ainsi de suite.

Le problème, c'est qu'un int ne peut pas contenir une valeur déterminée infiniment grande. Admettons que j'aie 5 Go de mémoire vive ou plus, je ne pourrai alors plus coder toutes mes adresses sur un petit pointeur de 4 octets.

Celà signifie-t-il qu'on est limité à 4 Go de mémoire, ou que j'ai loupé un truc au sujet des pointeurs ?

Merci d'avance

Lionel

[QUOTE=L. Sierra]Salut à tous,

En C ou en C++, si on prend un pointeur (sur n'importe quel type) et qu'on détecte sa taille, par exemple:

int* ptr=0;
cout << sizeof(ptr) << endl;

On obtient 4, donc 4 octets de mémoire.[quote]

Jusque là tout va bien.

Citation:

---

Envoyé par L. Sierra

J'en déduis qu'un pointeur est un peu comme un unsigned int, pointant sur le premier octet de la mémoire s'il est égal à 1, sur le 2ème octet de la mémoire s'il est égal à 2, et ainsi de suite.

---

Fais gaffe tout de même aux raccourcis un peu rapide. Les 2 exemples suivants ne sont pas du tout identiques :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

//Code 1 int tab[200]; int *ptr; ptr = tab; for (int i = 0; i < 200; i++) printf("value n°%d = %d\n", i, *ptr++); // Code 2 int tab[200]; unsigned char *ptr; ptr = (unsigned char*) tab; for (int i = 0; i < 200; i++) printf("value n°%d = %d\n", i, *((int*)(ptr++)));

---

Le code 2 fait décaler ptr de 1 octet alors que le code 1 de 4 octets. Tout dépend en fait de sizeof(*ptr).

Citation:

---

Envoyé par L. Sierra

Le problème, c'est qu'un int ne peut pas contenir une valeur déterminée infiniment grande. Admettons que j'aie 5 Go de mémoire vive ou plus, je ne pourrai alors plus coder toutes mes adresses sur un petit pointeur de 4 octets.

Celà signifie-t-il qu'on est limité à 4 Go de mémoire, ou que j'ai loupé un truc au sujet des pointeurs ?

---

Et oui sur archi 32 bits, on est limité à 4 Go de mémoire.
Donc à moins de passer par un hack du type espace d'adressage virtuel (genre on utilise 2 pointeurs 32 bits au lieu de 1 pour addresser au dessus de 4Go).

Maintenant avec les nouvelles archi 64 bits, ben on à encore largement le temps de devenir sexagénaires (je crois que la limite c'est 8 To !!!).

Citation:

---

Celà signifie-t-il qu'on est limité à 4 Go de mémoire, ou que j'ai loupé un truc au sujet des pointeurs ?

---

Attention, il y a une différence entre la mémoire physique et la mémoire que dispose un processus (appelé mémoire virtuel).

Pour faire "simple", chaque processus dispose d'un espace mémoire qui lui est propre et il ne lui est pas possible d'aller fouiner ailleurs grâce au MMU. Ca permet évidement d'éviter les plantages conséquents et ça permet d'éviter d'aller là ou on ne devrait pas (c'est lui qui est responsable de l'envoi l'interruption SIGSEGV en cas d'accès illégal à un segment de mémoire (Segmentation Fault))

Donc, pour continuer, tu peux avoir 16 mo de RAM, mais un espace virtuel de 4go (la plupart des données seront swapés et ton ordinateur risque de mettre 3 plombes à répondre).

Enfin, pour dire que ce n'est pas un problème relatif au fait d'avoir plus de 4 go de RAM physique, mais c'est un problème même présent avoir 512 mo de RAM (à cause de l'adressage virtuel)

Salut,

Juste une petite intervention pour rappeler qu'il est quand meme tres rare d'être obligé, à un moment T donné, de maintenir 4Gb de données (et d'instructions) en mémoire...

A titre de comparaison, cela revient à vouloir maintenir en mémoire presque la totalité du contenu d'un DVD simple couche :P...

Meme dans le cadre de (tres) grosses bases de données, il reste rare qu'une seule table prenne autant de place en mémoire ;)... Je ne dis pas que cela n'arrive jamais, et, si cela arrive, il y a peut etre intéret à la gérer de manière morcelée, mais que "cela n'arrive pas tous les jours" ;)

Ok, merci pour ces réponses.

C'est vrai que stocker 4 Go de données peut paraître exagéré, mais je travaille avec des logiciels d'ingénierie et de calcul scientifique, et parfois certains programmes utilisent une quantité de mémoire assez énorme.

Donc je commence à comprendre pourquoi tout le monde parle de 64 bits: on est obligé d'y passer pour dépasser les 4 Go de RAM.

Citation:

---

Envoyé par L. Sierra

Ok, merci pour ces réponses.

C'est vrai que stocker 4 Go de données peut paraître exagéré, mais je travaille avec des logiciels d'ingénierie et de calcul scientifique, et parfois certains programmes utilisent une quantité de mémoire assez énorme.

Donc je commence à comprendre pourquoi tout le monde parle de 64 bits: on est obligé d'y passer pour dépasser les 4 Go de RAM.

---

Il y a de cela, mais il ne faut pas oublier que la limite d'une chaine n'est, en tout état de cause que celle de son maillon le plus faible...

Ce n'est, par exemple, pas par hasard si un film sur un DVD est divisé en fichiers de 1Gb maxi, et le fait d'avoir un matériel "capable" de trouver des adresses allant bien au delà des 4Gb ne signifie pas *forcement* que tu pourras envisager de maintenir plus de 4Gb de données en mémoire au meme moment...

Outre le matériel, il y a les limites du système d'exploitation, du système de fichiers utilisé, de l'espace disponible sur le disque dur, et de plein d'autres choses, qui, entrant dans la "chaine d'utilisation du matériel" sont de nature à en abaisser les limites ;)

Le tout, sans oublier le fait qu'au niveau du processeur, il n'y a rien de plus proche d'une donnée... qu'un instruction, ni celui des autres applications qui fonctionnent en meme temps qu'une application précise, ou celui que la mémoire utile à une application est divisée en trois partie distinctes: lecture seule, tas et pile...

En dehors meme de toute considération concernant les performances "brutes" (le temps mis pour fournir un résultat selon une configuration donnée), tous ces facteurs sont de nature à placer une limite supplémentaire à ce que tu peux faire :P

Pour poursuivre ce que dit koala :

- passer à 64 bits veut dire "maintenant j'ai la possibilité" d'adresser 4Go dans un même processus
- avoir du hardware performant veut dire "je n'auais pas à attendre 15 minutes" avant que mes données / programme ne démarrent

Pour le coup, si tu as des applications gourmandes en donnés (j'ai le même cas que toi, je travaille en client/serveur sur des DBs > 1To) les goulôts d'étranglement seront :

- un OS pur 64 bits
- des applications compilées et optimisées pour le 64 bits
- la qualité de ta RAM
- la quantité de RAM (compter "taille mémoire des données" x 2)
- la vitesse de ta RAM
- la vitesse du CPU
- la vitesse du Front BUS
- la vitesse de tes HDs
- le protocole de tes HDs (IDE / SATA / SCSII / Firewire ...)
- un disque dédié pour le SWAP (ultra rapide : genre 10 000 T/min)

Tout le reste n'est que gadget, et peut trés bien avoir des performances excécrables.