mon prog c++ n'utilise pas le swap

Version imprimable

Salut!
Je débute en c++ et j'ai le problème suivant:
je veux exécuter un prog qui crée une matrice de "double" de dimension 20000 x 20000:

Code:

1
2
3
4
5
6
7
8
#include <iostream>
using namespace std;
 
int main(){
  cout<<"size of double: "<< sizeof(double)<<endl;
  double** Matrix=new double*[20000];
  for (int i=0; i<20000; i++) Matrix[i]=new double[20000];
}

Quand je lance le prog, j'obtiens la sortie suivante:

Code:

1
2
3
4
size of double: 8
terminate called after throwing an instance of 'std::bad_alloc'
  what():  St9bad_alloc
Aborting

Si je tape la commande linux "free -s 0.01" pendant l'exécution du prog, je remarque que la mémoire physique diminue pratiquement jusque zéro puis que le prog s'arrête. Je ne comprends pas pourquoi il ne continue pas à tourner en utilisant les 18 GB de mon swap (oui, je sais, c'est beaucoup)...
Quelqu'un a une idée??

(je suis sous debian et je compile avec g++)

sortie de "free -s 0.01":

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
             total       used       free     shared    buffers     cached
Mem:        516692     437852      78840          0      40244     190016
-/+ buffers/cache:     207592     309100
Swap:     17757076        112   17756964
 
             total       used       free     shared    buffers     cached
Mem:        516692     445044      71648          0      40244     190016
-/+ buffers/cache:     214784     301908
Swap:     17757076        112   17756964
 
             total       used       free     shared    buffers     cached
Mem:        516692     455088      61604          0      40244     190016
-/+ buffers/cache:     224828     291864
Swap:     17757076        112   17756964
 
             total       used       free     shared    buffers     cached
Mem:        516692     467364      49328          0      40244     190016
-/+ buffers/cache:     237104     279588
Swap:     17757076        112   17756964
 
             total       used       free     shared    buffers     cached
Mem:        516692     476788      39904          0      40244     190016
-/+ buffers/cache:     246528     270164
Swap:     17757076        112   17756964
 
             total       used       free     shared    buffers     cached
Mem:        516692     489064      27628          0      40244     190016
-/+ buffers/cache:     258804     257888
Swap:     17757076        112   17756964
 
             total       used       free     shared    buffers     cached
Mem:        516692     499604      17088          0      40244     190016
-/+ buffers/cache:     269344     247348
Swap:     17757076        112   17756964
 
             total       used       free     shared    buffers     cached
Mem:        516692     510564       6128          0      40240     188996
-/+ buffers/cache:     281328     235364
Swap:     17757076        112   17756964
 
CRASH!

16/08/2006, 15h42
Matthieu Brucher

Attention, c'est un programme 32bits, non ? Donc son espace adressable est de 4Go maximum, et sous Linux c'est limité à 2Go par processus. Même si c'est juste juste au niveau de la mémoire, si tu as d'autres objets volumineux, ça plantera sans aucun doute.
16/08/2006, 17h27
Ti-R

Ce n'est pas possible d'allouer un peu moins de mémoire pour ton problème ?

D'allouer 20000 double, et de réutiliser cet espace 20000 fois ?

car 8*20000*20000 = 2.98 Go de mémoire.... c'est pas mal, un peu trop :?
16/08/2006, 17h32
Médinoc

J'ai bien peur que ce soit la seule solution:

20,000 * 20,000 : 400,000,000 de doubles.
Un double faisant 4 ou 8 octets, on se retrouve déjà avec 1.6 Go dans le premier cas, 3.2 Go dans le second cas (enfin, avec de "petits" Go) ---> Sur une machine 32bits, le second cas a déjà épuisé la mémoire disponible pour un processus.
16/08/2006, 18h29
koala01

Salut,

AMHA, une matrice carrée de 20.000 doubles, ca fait effectivement énrome… Est tu sur d'avoir besoin d'une matrice si grande?

D'un autre coté, n'oublie quand meme pas qu'une matrice, au niveau de la mémoire, ca garde toujours une seule dimention.

Rien ne t'empeche d'utiliser la formule classique

Code:

position[ligne][colone]=position[ligne*nombre_colone+colone]

ou ses dérivées, principalement, afin de t'éviter d'avoir à jouer systématiquement avec des pointeur de pointeurs...

Juste par aquit de conscience: quelle application pourrait nécessiter de disposer en permanence de 400.000.000 (car, il s'agit bien de cela) d'éléments, et en type double, qui plus est???
16/08/2006, 18h41
mat.M

Citation:

for (int i=0; i<20000; i++) Matrix[i]=new double[20000];

Et la gestion d'exceptions elle est ou ? :?
Si c'était géré par un try..catch on serait plus fixés...
Pour des grosses allocations il faut passer par d'autres méthodes que new , utiliser des fonctions spécifiques à Linux pour la gestion de mémoire.
16/08/2006, 20h11
jeroman

Et si tu créais un fichier de 20000*20000*8 octets qui ferait office de swap ?
17/08/2006, 01h56
keket123

Merci à tous pour vos réponses! Sur les autres forums, on me répond que des conneries...
Je ne savais pas que j'étais limité à 2GB de mémoire par prog...
Il ne me reste plus qu'à implémenter un système efficace d'adressage sur 64 bits, pour mon proco 32 bits, et à modifier un peu mon noyau :mrgreen:

En fait, dans mon vrai programme, je dois inverser une matrice d'entiers 20.000 x 20.000 (un truc de malade). Comme elle est symétrique, je ne stocke que sa partie triangulaire supérieure dans mon array 20.000 x 20.000, et je profite de la place dans la partie triangulaire inférieure pour y stocker la décomposition de Choleski (matrice également triangulaire, mais contenant des double). Comme j'ai besoin de ma matrice initiale pour calculer sa décomposition de Choleski, je suis obligé de les avoir toutes les deux en mémoire simultanément.

Bon, si je comprends bien, les solutions sont:
- exécuter mon prog sur un machine >32bits
- utiliser un fichier sur le disque, plutot qu'un array de arrays en mémoire
- rendre carrées mes deux matrices triangulaires (chipotage d'indices) et les stocker dans 2 matrices séparées (une d'entiers, et une de double)

Vous inquiétez pas pour le temps d'exécution, c'est un prog que je fais pour mon mémoire, c'est pas un prog que j'utiliserai tous les jours, donc c'est pas grave s'il lui faut 1 semaine pour tourner.

Encore merci, et si vous avez d'autres idées, ne vous gênez pas... ;)
17/08/2006, 14h48
tut

Citation:

Envoyé par keket123

Encore merci, et si vous avez d'autres idées, ne vous gênez pas... ;)

Oui :
appeler Meteo France, je crois que c'est eux qui ont le plus gros ordinateur de France...
17/08/2006, 18h17
keket123

arf, c'est maintenant que je regrette d'être belge!
Vu la taille du pays, meteo belgique se contente sûrement d'un bon vieux C64 ;)
18/08/2006, 01h47
ciol2.6.12

Ce n'est pas 3 Go par processus (en espace utilisateur, en fait 4 Go - 1 Go réservé pour le noyau) ? Avec une possibilité de réduire l'espace du noyau en recompilant afin d'atteindre environ 3.5 Go ?

par exemple ici http://kerneltrap.org/node/2450
ils expliquent l'inverse, c'est à dire augmenter l'espace pour le noyau.

?
18/08/2006, 09h05
Matthieu Brucher

C'est en-dessous des 3Go, plutôt vers les 2.5, j'ai une fois vu le platage en tant réel avec un top.
Sous Windows sans modif, c'est 2Go, avec un switch au démarrage, c'est 3Go.