Discussion :

[Djobird]

Bonjour,

je travaille actuellement sur un programme qui peut parfois demander d'allouer de très grosse quantité de mémoire (plusieurs matrices de 2 giga). Impossible de partager ce calcul ou de faire petit à petit (enfin on y réfléchie encore, mais ca voudrait dire recoder une très grosse bibliothèque).

Je pensais qu'allouer une très grosse quantité de mémoire allait faire swaper l'ordi. Mais ce n'est pas le cas. Du moins pas sur tous. Sur mon ordinateur (une ubuntu 8.10 avec 5 giga de mémoire swap) le programme me donne un core dump. Sur un autre ubuntu 8.10, aucun problème le swap se fait, alors qu'il n'a que 750 Mo de mémoire swap disponible.

Nous avons tester sur d'autres ordinateurs en kubuntu 7.10 (aucune idée du swap par contre), et ca plante également.

Je voudrais donc savoir s'il est possible de forcer l'utilisation du swap, ou si vous aviez une idée d'où peut venir notre problème ?

[3DArchi]

Salut,
Es-tu sûr que l'allocation réussie sur les PC où cela plante? Testes-tu le retour de l'allocation?

[contremaitre]

Tu n'as peut etre pas de swap sur certains de tes pc.
la commande
swapon -s
Devrait de montrer quelle partition est dédiée a ta swap avec sa taille
Il y a la commade free également

[souviron34]

je travaille actuellement sur un programme qui peut parfois demander d'allouer de très grosse quantité de mémoire (plusieurs matrices de 2 giga). Impossible de partager ce calcul ou de faire petit à petit
..
Je voudrais donc savoir s'il est possible de forcer l'utilisation du swap, ou si vous aviez une idée d'où peut venir notre problème ?

C'est déjà dès le départ une mauvaise approche....

[contremaitre]

Et si tu n'as pas assez de place en mémoire, tu peux écrire toi même sur disque, dans un fichier.

[Djobird]

C'est déjà dès le départ une mauvaise approche....

Si vous connaissez une bibliothèque permettant de faire des transformer de fourrier qui gère le problème que j'ai ca ma va aussi. Mais le je dois faire une transformer sur un tableau qui peut être gigantesque (ca commence a planter à partir de 600 000 000 de case par exemple), et je n'ai pas de moyen de lui donner petit bout par petit bout de tableau. Après je n'ai pas eu le courrage de regarder le code de la bibliotheque FFTW, je peux essayer au cas ou mais je ne sais pas si j'ai le niveau pour ca.

Mon swap existe bien, après peut être est il mal utilisé je sais pas. A priori l'allocation marche sur l'autre pc puisque le pc gratte comme un fou, et surtout ne plante pas (alors qu'on effectue juste après l'allocation une écriture dans ce tableau).

Travailler avec un fichier, je ne suis pas contre, mais c'est possible ? Enfin je veux dire les données,j'y ai des tats de boucles de calcul dessus (dont à la fin transformer de fourrier).

[Jean-Marc.Bourguet]

Si vous connaissez une bibliothèque permettant de faire des transformer de fourrier qui gère le problème que j'ai ca ma va aussi. Mais le je dois faire une transformer sur un tableau qui peut être gigantesque (ca commence a planter à partir de 600 000 000 de case par exemple),

As-tu fait une analyse de la propagation des erreurs dans le cas d'une FFT d'une telle taille?

En passant, dans une vie anterieure, j'ai publie un papier decrivant comment utiliser des caches de maniere assez efficace lors de calculs de FFT.

et je n'ai pas de moyen de lui donner petit bout par petit bout de tableau. Après je n'ai pas eu le courrage de regarder le code de la bibliotheque FFTW, je peux essayer au cas ou mais je ne sais pas si j'ai le niveau pour ca.

Mon swap existe bien, après peut être est il mal utilisé je sais pas. A priori l'allocation marche sur l'autre pc puisque le pc gratte comme un fou, et surtout ne plante pas (alors qu'on effectue juste après l'allocation une écriture dans ce tableau).

Normalement, le swap est utilise sans intervention. Donc, reprenons les questions evidentes:

Est-ce que tu es sur que tu as des OS 64 bits? (Parce que pour utiliser plus de 4GB de memoire dans un process, c'est ce qu'il faut).

Est-ce que tu as bien compile en mode 64 bits? (Parce que sinon, avoir un OS et un swap adequat, ca ne sert a rien).

En passant, tu ne m'as pas l'air d'avoir les competances pour mener a bien de maniere fiable ce que tu as entrepris. Dans quel contexte es-tu?

[matafan]

Tu compiles en 32 bits ou en 64 bits ? Je ne sais pas trop comment ça se passe sous linux, mais sous beaucoup de systèmes tu ne peux pas allouer plus d'un segment (256 Mo sous AIX) pour le heap avec les options par défaut du loader. Pour allouer plus (jusqu'à un peu plus de 3 Go en 32 bits sous AIX), il faut jouer avec les options du loader.

Si tu es en 64 bits tu ne devrais pas avoir ce genre de problèmes.

En tout ca si tu coredump, c'est certainement que tu ne teste pas toutes les valeurs de retour de tes malloc()s.

[souviron34]

Si vous connaissez une bibliothèque permettant de faire des transformer de fourrier qui gère le problème que j'ai ca ma va aussi. Mais le je dois faire une transformer sur un tableau qui peut être gigantesque (ca commence a planter à partir de 600 000 000 de case par exemple), et je n'ai pas de moyen de lui donner petit bout par petit bout de tableau. Après je n'ai pas eu le courrage de regarder le code de la bibliotheque FFTW, je peux essayer au cas ou mais je ne sais pas si j'ai le niveau pour ca.

Mon swap existe bien, après peut être est il mal utilisé je sais pas. A priori l'allocation marche sur l'autre pc puisque le pc gratte comme un fou, et surtout ne plante pas (alors qu'on effectue juste après l'allocation une écriture dans ce tableau).

Travailler avec un fichier, je ne suis pas contre, mais c'est possible ? Enfin je veux dire les données,j'y ai des tats de boucles de calcul dessus (dont à la fin transformer de fourrier).

Ce que je voulais dire, sans parler des arguments des autres participants, c'est qu'avoir quelque chose qui fixe une telle taille en a-priori est voué à l'échec.

Une approche correcte serait d'avoir tout paramétré, au minimum. Et de récupérer les erreurs fatales (du style "coredump") et de faire quelque chose d'adaptatif : si pas d'erreur, on avance. Si erreur, on découpe le problème.

C'est en ça que je dis et répète : mauvais approche dès le départ.

Quant à la FFT, non seulement Jean-Marc (et d'autres dans le foru algorithmes) peuvent t'être d'un grand secours, mais de plus encore une fois on retombe sur la même conclusion : mauvaise approche.

Sans en savoir plus, c'est tout ce qu'on peut dire.

[Jean-Marc.Bourguet]

Quant à la FFT, non seulement Jean-Marc (et d'autres dans le foru algorithmes) peuvent t'être d'un grand secours,

Plutot les autres. C'etait bien dans une vie anterieure. Je m'en sortirais vraisemblablement, meme sans documents, mais au prix d'un travail que je ne suis pas pret a faire pour repondre sur DVP.

[Djobird]

Alors le projet est une parallélisation de calcul. Il existe une bibliothèque permettant d'effectuer des calculs physiques, ces calculs permettent (en très gros) de rajouter des points sur une courbe afin de la lisser. Plus on veut que la courbe soit lissée, plus il faut rajouter de points. Plus on veut de points, plus le tableau permettant de contenir ces points sera grand (pour info ces calculs sont en rapport avec des analyse de l'ordre du nanomètre). Or à un moment, afin de déterminer ces points il faut faire une transformer de fourier inverse sur ce tableau.

J'ai repéré où avait exactement lieu le coredump et ses causes, ce n'est pas dans FFT, mais bien dans la bibli que j'utilise. Mais j'ai besoin de ce tableau pour être utilisé dans FFT (je ne sais pas si je suis clair :/)

Sinon chaque allocation mémoire fait pour l'instant au maximum 1.5 giga, c'est en cumulé que je dépasse les 4 gigas, ca ne peut pas marcher quand même ?

edit : Je viens d'avoir confirmation par mon collegue sur sur son ubuntu 8.10 32 bits, le swap s'effectuait bien et l'application terminait.

[contremaitre]

J'ai repéré où avait exactement lieu le coredump et ses causes, ce n'est pas dans FFT, mais bien dans la bibli que j'utilise. Mais j'ai besoin de ce tableau pour être utilisé dans FFT (je ne sais pas si je suis clair :/)

C'est donc un bug de ta bibliothèque. Tu peux en informer les auteurs et, si c'est open source, le corriger toi meme ?

[Jean-Marc.Bourguet]

Sinon chaque allocation mémoire fait pour l'instant au maximum 1.5 giga, c'est en cumulé que je dépasse les 4 gigas, ca ne peut pas marcher quand même ?

Un process compile 32 bits ne peut pas adresser plus de 4GB de memoire avec un X86 tel qu'utilise par Linux et Windows. Les OS diminuent encore un peu ou beaucoup (de 0.5 GB a 2 GB suivant les OS, la configuration, ...) cette quantite disponible. Donc si tu fais plus de 2 allocations simultanees de 1.5 GB, tu as besoin d'un process 64 bits (et si tu en fait exactement 2, il y a des risques que tu en ai besoin aussi).

edit : Je viens d'avoir confirmation par mon collegue sur sur son ubuntu 8.10 32 bits, le swap s'effectuait bien et l'application terminait.

Et le resultat, il etait correct? Avec les infos que tu donnes, j'ai l'impression que tu n'as pas de crash par malchance mais que les resultats doivent etre faux.

[matafan]

Et en passant, ce n'est pas parce que ça coredump dans la lib que c'est la faute de la lib.

[contremaitre]

Et en passant, ce n'est pas parce que ça coredump dans la lib que c'est la faute de la lib.

Oui, pardon.
Il faut voir si l'appel de la fonction de la lib est correcte, avant.

[Djobird]

Je ne dois pas etre très clair dans mon explication.

Voici la partie de code qu ifait le coredump.

Code :

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

1
2
3
4
5
6
  newVecteur = (fftw_complex *)fftw_malloc((*newTaille)*sizeof(fftw_complex));
 
 
  for (i = 0; i < indicem; i++) {
    newVecteur[i][0] = vecteur[i][0];
		newVecteur[i][1] = vecteur[i][1];

Le malloc marche (bon c'est un fftw malloc, mais c'est la même chose),parcontre dés que met une valeur avec newVecteur[i][1] = vecteur[i][1], là ca plante.
La raison je la connais, un malloc, même si ca reserve trop de mémoire, ne va pas faire planter le programme, c'est la lecture/écriture de la zone mémoire théoriquement reservée qui fait planter.

Si la zone mémoire à réserver est trop grande, c'est simplement parce que newTaille est très grand (Chez moi ca plante a partir de 75 000 000). Si cette talle est très grande c'est parce que les valeurs à calculer sont très nombreuses (en gros c'est comme si ca devait simuler une image dont résol serait de l'ordre de 1 000 000 par 1 000 000) . Ce n'est donc pas du tous un bug (ou alors le bug vient de la facon dont Dieu à programmer le code Vie, mais là comptez pas sur moi pour essayer de le modifier).

Je n'ai pas moyen de changer la façon dont les calculs sont fait (ce sont des calculs de physiciens), s'ils ont besoin d''avoir au final un tableau aussi grand je ne peux rien. La seule chose que je peux peut être faire, c'est faire en sorte que ce tableau soit calculée petit à petit (et encore il faut que je vois ca avec les physiciens si c'est possible).

Bon si je ne peux pas adresser plus de 4 giga (en effet j'avais completement zappé ce détail), je suis powned.

[souviron34]

Je ne dois pas etre très clair dans mon explication.

Voici la partie de code qu ifait le coredump.

Code :

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

1
2
3
4
5
6
  newVecteur = (fftw_complex *)fftw_malloc((*newTaille)*sizeof(fftw_complex));
 
 
  for (i = 0; i < indicem; i++) {
    newVecteur[i][0] = vecteur[i][0];
		newVecteur[i][1] = vecteur[i][1];

Le malloc marche (bon c'est un fftw malloc, mais c'est la même chose),parcontre dés que met une valeur avec newVecteur[i][1] = vecteur[i][1], là ca plante.
La raison je la connais, un malloc, même si ca reserve trop de mémoire, ne va pas faire planter le programme, c'est la lecture/écriture de la zone mémoire théoriquement reservée qui fait planter.

Non, le malloc devrait te renvoyer NULL si il n'a pas réussi. Si il te renvoie une adresse, c'est que tu peux aller écrire dedans..

As-tu vérifié le retour ??

Si la zone mémoire à réserver est trop grande, c'est simplement parce que newTaille est très grand (Chez moi ca plante a partir de 75 000 000). Si cette talle est très grande c'est parce que les valeurs à calculer sont très nombreuses (en gros c'est comme si ca devait simuler une image dont résol serait de l'ordre de 1 000 000 par 1 000 000) . Ce n'est donc pas du tous un bug (ou alors le bug vient de la facon dont Dieu à programmer le code Vie, mais là comptez pas sur moi pour essayer de le modifier).

Je n'ai pas moyen de changer la façon dont les calculs sont fait (ce sont des calculs de physiciens), s'ils ont besoin d''avoir au final un tableau aussi grand je ne peux rien. La seule chose que je peux peut être faire, c'est faire en sorte que ce tableau soit calculée petit à petit (et encore il faut que je vois ca avec les physiciens si c'est possible).

Voilà ce qui arrive quand on fait faire par quelqu'un qui ne connait rien au problème de fond un programe qui déjà va aux limites... C'est pas de ta faute, mais c'est stupide.

Maintenant sur ton problème de base, de la parallélisation doit de toutes façons se faire quasi-obligatoirement par découpage en blocs.

La biblothèque est-elle dispo en 64 bits ? peut-elle gérer ce type d'adresse ?

Encore une fois,de toutes façons l'approche est mauvaise. Si demain (et avec les physiciens c'est toujours le cas) ils doublent la taille de ce qu'ils veulent, exigeras-tu des processeurs 128 bits ????

[contremaitre]

Non, le malloc devrait te renvoyer NULL si il n'a pas réussi. Si il te renvoie une adresse, c'est que tu peux aller écrire dedans..

By default, Linux follows an optimistic memory allocation strategy. This means that when malloc() returns non-NULL there is no guarantee that the
memory really is available.

En lisant ça j'ai cru que la memoire retournée par malloc n'etait pas forcement valide.
Mais en relisant mieux, je pense que ça veut dire qu'il peut tuer un autre process pour renvoyer cette memoire demandé. Mais du coup la memoire sera tout de meme dispo pour ecrire dedans.

Encore une fois,de toutes façons l'approche est mauvaise. Si demain (et avec les physiciens c'est toujours le cas) ils doublent la taille de ce qu'ils veulent, exigeras-tu des processeurs 128 bits ????

Je pense pas que ce soit nécessaire :
quote wikipedia :

The emergence of the 64-bit architecture effectively increases the memory ceiling to 2^64 addresses, equivalent to approximately 17.2 billion gigabytes, 16.8 million terabytes, or 16 exabytes of RAM

[souviron34]

Faux :

Je ne sais pas où tu as vu ça, mais alors ton Linux ne suit pas les normes C depuis le début....

http://man.developpez.com/man3/malloc.3.php

Pour calloc() et malloc(), la valeur renvoyée est un pointeur sur la mémoire allouée, qui est correctement alignée pour n'importe quel type de variable, ou NULL si la demande échoue.

Norme C99 :

7.20.3.3 The malloc function
Synopsis
1 #include <stdlib.h>
void *malloc(size_t size);
Description
2 The malloc function allocates space for an object whose size is specified by size and whose value is indeterminate.
Returns
3 The malloc function returns either a null pointer or a pointer to the allocated space.

K&R :

void *malloc(size_t size)
malloc returns a pointer to space for an object of size size, or NULL if the request cannot be satisfied. The space is uninitialized.

Je pense pas que ce soit nécessaire :

Et ??

Je ne vois pas en quoi le fait de dire qu'on pourrait adresser cela empêcherait des demandes dépassant, et en tous cas une programmation souple et "safe"...

[souviron34]

En lisant ça j'ai cru que la memoire retournée par malloc n'etait pas forcement valide.
Mais en relisant mieux, je pense que ça veut dire qu'il peut tuer un autre process pour renvoyer cette memoire demandé. Mais du coup la memoire sera tout de meme dispo pour ecrire dedans.

Non à mon avis ça veut dire qu'elle n'est pas forcément disponible en libre, mais que dans mémoire+swap ça marche.