Discussion :

[buzzkaido]

Bonjour,

Dans une application que je développe, l'utilisateur peut charger des données en mémoire.

Mais il peut arriver qu'il cherche à charger BEAUCOUP de données (plus d'un giga).

Lors du chargement des données, il est proposé à l'utilisateur d'entrer un coefficient de "sous-echantillonnage" qui permet de ne charger que 1/10ème, 1/5ème... des données. (au prix d'une perte de précision, bien sûr)

Tout marche bien, mais...

Si l'utilisateur essaie de charger (par exemple) 1 giga de données et entre un coefficient égal à 1, lors du chargement, je fait un :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

truc = new machin[1 giga]

Ce qui aboutit, en général (selon la machine) à un plantage...

Donc j'aimerais savoir comment determiner la taille maximale que je vais pouvoir allouer (pour indiquer à l'utilisateur que son coef est trop petit, ou qu'il faut qu'il rachete de la RAM...)

PS : à la fois pour Linux et Windows, avec QT

Merci !

[moldavi]

Bonjour.

Plutôt que de mettre les données en mémoire, pourquoi ne pas utiliser un fichier. Un Go, ça commence à faire beaucoup, la plupart des OS limitent la taille maximum pour un programme à environ 3 Go, il en faudra donc peu pour que ton programme se bloque une fois atteint cette limite.

Pour savoir quelle taille mémoire ton programme peux allouer dépendra donc de la taille de la mémoire programme, des ressources systèmes au moment de l'allocation.

Il faut une raison vraiment valable pour maintenir 1 Go de données en mémoire...

PS : une connaissance approfondie de la façon dont windows et linux gèrent la mémoire me semble judicieux, afin de prendre la meilleure décision possible.

[wiztricks]

Bonjour
Si tu travailles dans un environnement 32 bits tu devrais pouvoir utiliser ces 1G puisqu'à priori il ne s'agit que de mémoire virtuelle.

Comment va être balayé cet espace au sens localité des références dans l'espace et dans le temps va donner la taille de RAM qu'il faudra avoir pour que les temps de réponses ne soient pas trop dégueulasses.

Le dernier et non le moindre des soucis sera de ne pas vautrer de système en sur-utilisant les fichiers de swap. Il sera peut être judicieux d'associer cette espace mémoire à un fichier mappé en mémoire (voir mmap): cela évitera de taper dans les fichiers de 'swap' partagés.

Si la mémoire virtuelle restante est insuffisante... il faut passer en 64 bits ou faire des entrées sorties 'à la main' dans un fichier.
-W

[buzzkaido]

Merci pour les réponses.

Je compile l'application pour Windows 64 bits et Linux 64 bits, et c'est prévu pour tourner sur une machine avec 16 Go de ram (!!!)

D'une manière générale, le but est effectivement de ne PAS charger 1Go de données, mais un "sous-echantillonnage" de ces données pour travailler dessus en RAM.

Mon seul soucis est de pouvoir prévenir l'utilisateur que "l'opération demandée utilisera trop de mémoire, veuillez charger moins de données"

Ou en tout cas, d'éviter le plantage si l'allocation échoue.

[wiztricks]

D'une manière générale, le but est effectivement de ne PAS charger 1Go de données, mais un "sous-echantillonnage" de ces données pour travailler dessus en RAM.

Lorsque tu fais new de 1Go tu ne crées que de l'espace 'virtuel'.
Ce n'est que lorsque tu liras/ecriras dedans que le mécanisme de pagination va aller chercher de la mémoire physique.
Si tu ne touche que 10% du tableau possible que tu n'ais besoin que de 100Ko de mémoire physique... Tout dépendra de la localité des accès dans l'espace et le temps

Mon seul soucis est de pouvoir prévenir l'utilisateur que "l'opération demandée utilisera trop de mémoire, veuillez charger moins de données"
Ou en tout cas, d'éviter le plantage si l'allocation échoue.

Vu la RAM disponible? tu risques de bouffer du swap, d'ou ma suggestion côté mmap.
- W

[zais_ethael]

Je n'ai jamais eu à faire ça, mais un new n'est pas sensé lancer une exception ou renvoyer null dans ce genre de cas? Je veux dire, je pensais qu'après un new réussi on avait l'assurance d'avoir un accès illimité et sans risque à la mémoire demandée.

[wiztricks]

Je n'ai jamais eu à faire ça, mais un new n'est pas sensé lancer une exception ou renvoyer null dans ce genre de cas? Je veux dire, je pensais qu'après un new réussi on avait l'assurance d'avoir un accès illimité et sans risque à la mémoire demandée.

Pour ce qui est de l'espace 'virtuel' sans doute mais si tu veux que cet espace soit en plus fourni avec la RAM correspondante et le swap qui va bien....
J'ai peur qu'il n'y ait pas d'autre choix que de faire çà à la mimine avec les appels systèmes qui vont bien (mmap pour le swap mais je n'ai jamais cherché côté allocation de RAM).
- W

[buzzkaido]

wiztricks : mmap, ça marche aussi sous Windows ?

zais_ethael : je pensais pareil, mais là, le new[] plante sans prévenir (j'avais jamais vu ça...)

[zais_ethael]

Tu as pensé à gérer les exceptions?
Dans le standard un new foireux doit lancer une exception. Certains compilateurs préfèrent, pour des raisons historiques, renvoyer NULL. Dans le doute et à titre exceptionnel je te conseillerais de faire les deux.
Je ne me souviens plus du type d'exception qui est sensée être lancée, tu pourrais aller regarder dans une doc de référence ou encore faire un catch(...) pour tout gérer.

wiztricks: je m'y connais moyennement en optimisation des transferts mémoire alors je supposerais que tu as raison. Néanmoins avant ça ce serait bien de trouver un moyen de détecter les erreurs avec l'outil de base. Early optimisation is the root of all evil

PS: mmap c'est Posix, ça n'a donc pas de raison d'exister sous Windows.

[wiztricks]

wiztricks : mmap, ça marche aussi sous Windows ?

Oui mais il faut que je cherche les appels systèmes correspondants résoud le pb suivant d'abord:

zais_ethael : je pensais pareil, mais là, le new[] plante sans prévenir (j'avais jamais vu ça...)

Pas normal - si tu es sous WINDOWS, tu as peut être un event interressant dans l'eventlog.
- W

[wiztricks]

wiztricks: je m'y connais moyennement en optimisation des transferts mémoire alors je supposerais que tu as raison. Néanmoins avant ça ce serait bien de trouver un moyen de détecter les erreurs avec l'outil de base. Early optimisation is the root of all evil

Je n'optimise rien.
Demander 1 Go de mémoire virtuelle à un OS se déroulera normalement si l'environnement à été taillé pour. Si ce n'est pas le cas, on a une exception qui va remonter ou pas... Mais elle risque d'être délicate à interpréter.

PS: mmap c'est Posix, ça n'a donc pas de raison d'exister sous Windows.

Je sais. Sous Windows tu as CreateFileMapping et d'autres appels système qui permettent de faire +/- la même chose que mmap.
- W

[buzzkaido]

Merci pour les ces differentes pistes...

Effectivement, faudrait que je controle les exceptions !

Sinon, je bosse avec Qt, y'aurait-pas un equivalent de mmap sous Qt, qui soit multi-plateforme ?

[wiztricks]

Merci pour les ces differentes pistes...

Effectivement, faudrait que je controle les exceptions !

Sinon, je bosse avec Qt, y'aurait-pas un equivalent de mmap sous Qt, qui soit multi-plateforme ?

Qt offre une API de relativement haut niveau qui ne s'encombre guère avec la gestion des ressources physiques. Seul Qt/Embedded pourrait avoir des primitives pour faire çà mais si mes souvenris sont bons c'est Linux 'only'.
- W

[loufoque]

new ne plante pas mais lève une exception.
Attrape-la.

[JolyLoic]

J'ai entendu dire qu'à une époque (je ne sais pas si c'est encore vrai), sous Linux, et contrairement à ce qui est spécifié par le standard, les allocations mémoire ne vérifiaient pas vraiment qu'il y avait assez de mémoire à allouer, mais ne faisait la vraie allocation (et ce test) que par morceau, au moment où on accédait à un bout de la mémoire allouée.

L'intérêt était double : Accélérer l'allocation, et gérer certains programmes qui commencent par faire un énorme malloc au début pour finalement n'utiliser que 1% de ce qu'ils ont demandé.

Le problème est de rendre toute gestion des problèmes d'allocation impossible.

[moldavi]

Bonjour.

Je crois que le problème, c'est qu'il y a les standards, les OS, les compilateurs et sûrement plein d'autres contraintes...

Je me souviens il y a deux ans, sur du windows XP, une allocation mémoire (new), de 1 Go prenait environ 3 minutes sur une machine (en mode debug)...

Pas de problème, ça marchait, mais bon après je n'ai pas cherché à utiliser cette mémoire, c'était juste pour me rendre compte du temps que ça pouvait prendre de faire tout plein d'allocation dans un programme.

[wiztricks]

J'ai entendu dire qu'à une époque (je ne sais pas si c'est encore vrai), sous Linux, et contrairement à ce qui est spécifié par le standard, les allocations mémoire ne vérifiaient pas vraiment qu'il y avait assez de mémoire à allouer, mais ne faisait la vraie allocation (et ce test) que par morceau, au moment où on accédait à un bout de la mémoire allouée.

L'intérêt était double : Accélérer l'allocation, et gérer certains programmes qui commencent par faire un énorme malloc au début pour finalement n'utiliser que 1% de ce qu'ils ont demandé.

Le problème est de rendre toute gestion des problèmes d'allocation impossible.

Je ne sais pas ce que spécifie le "standard".

Par défaut, lorsqu'on travaille avec une mémoire virtuelle, il n'y a pas de relation entre l'espace virtuel qui a été demandé et la mémoire physique (RAM).

C'est le boulot du système d'exploitation de faire la mise en correspondance des adresses virtuelles auxquelles le programme accède avec de la mémoire physique - c'est en général le mécanisme de pagination qui fait cela.

Le système d'exploitation se comporte assez bien lorsque les programmes font des demandes 'normales'. Ce qui fait que dans la plupart des cas, il suffit de faire 'new' ou 'malloc' sans se pré-occuper de ce qui se passe 'en dessous'.

Lorsqu'on a besoin de 'beaucoup', le système n'est pas nécessairement 'bien paramétré' pour s'en sortir correctement. Il faut sortir le tournevis et ajuster le programme ou le système pour qu'il s'en sorte mieux.

Il y a donc en général des appels systèmes qui:
- permettent d'allouer la mémoire physique avant qu'on ait besoin d'accéder aux emplacements mémoires,
- mettre en correspondance des morceaux de la mémoire virtuelle avec des fichiers,
- partager des espaces mémoire entre plusieurs processus.
- W

[zais_ethael]

Bon, quel que soit le mode de fonctionnement exact, le mieux pour le savoir est encore de tester.
buzzkaido, ça devrait te prendre deux secondes... ça commence à m'énerver moi, c'est que ça m'intéresserait de savoir si il est effectivement impossible de détecter les dépassements de mémoire sous linux

[wiztricks]

J'étais parti avec du 'C' puis j'ai remplacé le 'malloc' par 'new': excusez le code ;-)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
 
# include <stdio.h>
# include <stdlib.h>
 
int main (int argc, char** argv)
{
  char* buffer;
  unsigned long  size;
 
  if (argc >= 1) {
    sscanf (argv[1], "%d", &size);
  } else {
    printf ("size: "); scanf("%d", &size);
  }
  printf ("read: %d\n", size);
 
  size *= 1024;  // assume KB
  printf ("size= %d, %X\n", size, size);
 
  buffer = new char [size];
 
  if (buffer == NULL)
    perror("failed to allocate buffer");
 
  return 0;
 
}

Execution:

mps@mps-desktop:~$ ./test2 1000000000
read: 1000000000
size= 1797783552, 6B280000 <- inférieur à 2Go

mps@mps-desktop:~$ ./test2 10000000000
read: 2147483647
size= -1024, FFFFFC00 <- supérieur à 2 Go
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Abandon (core dumped)

Je n'ai que 512 Mo sur ma bestiole Linux...
Notez que je n'accède pas au tableau ;-)
- W

[zais_ethael]

terminate called after throwing an instance of 'std::bad_alloc'

C'est assez explicite je crois...