Bonjour,
 
Je suis dans le flou concernant l'allocation de larges plages de mémoire.
 
L'allocation (dynamique) de mémoire est limitée à 4Go, dans la théorie, puisque le paramètre de l'opérateur new est de type size_t donc lui-même 32 bits. Sur un système 32 bits, ça parait logique puisque la RAM est de toute façon limitée à 4Go. Ma question est : qu'en est-il sur un système 64 bits par exemple ?  
 
Est-il possible dans un programme en C ou C++ d'allouer dynamiquement un volume de 16 Go par exemple (en supposant qu'on dispose de suffisamment de RAM) ?  
Est-ce totalement suicidaire de toute façon du point de vue performance ?
 
Dernier point : j'utilise new (nothrow) pour vérifier l'allocation mémoire, mais j'obtiens malgré tout une erreur de type invalid allocation size si la taille est trop importante (idem avec un try/catch). Je suis obligée de faire un test auparavant, avec une valeur assez... arbitraire dont je ne suis pas du tout sûre...

un size_t doit faire au moins 64 bits sur un os 64 bits. Je ne vois pas pourquoi interdire d'allouer 16Go d'un coup si la machine est capable de le supporter ... Après, ca peut être rejeté pour diverses raisons, dépendant, par exemple, de ton OS
 
edit : typo (bis)

La RAM n'est pas limitée à 32bits. Voir PAE, etc.

Ca fonctionne très bien.
Pour vraiment optimiser, il faut avoir un OS (Solaris, Linux) qui gère les hugepages (genre 4MB) pour éviter un massacre au niveau du TLB. Compte combien ça fait 16Go en pages de 4K/8K ...

theshockwave: les allocations paressesseuses, ça existe. Sur ton OS 64bits, tu peux à l'aise allouer plusieurs To alors que t'as qu'une poignée de Go de RAM.

 
Je me doute que ce n'est pas limité à la RAM (au moins pour une question de swap) ... mais, dans le cas hypothétique où on aurait été autorisé à allouer plus de mémoire que disponible (ram + swap), il se passerait quoi, si on venait à écrire partout sur la mémoire "allouée" ?

deux cas de figures:
- ton OS a une heuristique, pour te laisser plus ou moins te gaver virtuellement (overcommit) (solaris par défaut, linux avec un vm.overcommit_memory=2)
- son heuristique est tellement simple (linux vm.overcommit_memory=0 ou 1, solaris je l'ai plus en tête, on peut changer le comportement), que jamais malloc ne donnera NULL. Si le système vient à manquer de mémoire, le noyau fera le ménage (OOM killer)
 
Les deux comportements ont leurs utilités.

* Ce qui m'emmerde avec les implementations d'overcommit, c'est que le bon choix est a faire application par application; mais que les implementations ne permettent un reglage que global.
 
* Pour l'OP: j'ai teste sur une machine avec 32 G de memoire, aucun probleme a allouer un tableau contigu de 16G.
 
* Il y a plusieurs choses a ne pas confondre:
- la taille de l'espace memoire adressable par un processus (ca va dependre de l'architecture et de l'OS)
- la taille de l'espace memoire gerable par l'OS
- la taille de l'espace memoire physiquement adressable
- la taille des registres d'adresse
- la taille des registres de donnee
 
La premiere est toujours inferieure a la seconde.
La troisieme peut etre plus petite, egale ou plus grande que les deux suivantes.
La quatrieme peut etre plus petite que la premiere.  Un probleme recurrent dans les architectures, c'est la limitation de la premiere (la suivante est confinee a l'OS, et la derniere a l'implementation, on peut utiliser tous les trucs qu'on veut beaucoup plus facilement).  On se retrouve quand meme souvent a utiliser des trucs pour l'etendre au dela de la quatrieme (segmentation, pagination sans parler des trucs immondes qui ont ete fait sur les premieres machines decimales).
Un autre probleme recurrent, est quand la taille des registres d'adresse est superieure a la taille de la memoire utilisable.  Il est tentant pour les programmeurs d'utiliser les bits supplementaires pour une ou l'autre chose; et quand l'evolution incite a avoir plus de memoire, on est plus ou moins bloque.  Par pitie pour ceux qui vont devoir maintenir vos programmes, ne le faite pas en 64 bits.
 
Le "nombre de bits" d'un processeur est -- sauf manipulation par le departement marketting, manipulations ayant d'ailleurs ete faites dans les deux sens -- la taille des registres de donnees.  Historiquement, il n'a pas particulierement de rapport avec les tailles adressables.  Sauf que la mode est aux registres d'usage generaux et donc que c'est vecu de plus en plus comme etant aussi la taille des registres d'adresse.

Pour ceux que le sujet intéresserait, les écrits de John Mashey sont intéressants.  Entre autres
http://queue.acm.org/detail.cfm?id=1165766
et le premier résultat de
http://groups.google.com/groups/se [...] ll&spell=1

effectivement, un article très fouillé, faut dire que le pedigree de l'auteur ne laisse pas trop de doutes sur ses connaissances

 
comp.arch a perdu beaucoup de son intérêt depuis que lui et Andy Glew n'y participent plus.  Si l'archi des ordinateurs t'intéresse, cherche aussi les messages de ce dernier dans groups.google.

faut être motivé pour lire tout ça  

bon bon ok