Bonjour à tous,
Je suis parfaitement débutant en C++ (mais j'essaye de faire des
efforts). Je parle courament C et Fortran depuis de nombreuses
années...
J'utilise à partir d'un programme C/Fortran la libboost. Depuis que
j'ai porté ce code sous Solaris, j'ai des problèmes de mémoire
(free() sous Solaris rend la mémoire à l'application et non au
système, ce qui peut poser des problèmes...).
Je fais donc la course au gaspillage mémoire inutile et surtout,
j'essaye de libérer la mémoire dès qu'elle ne sert plus. Pour ce
faire, je vire autant que faire se peut toute variable statique
inutile, tout couple malloc/free pour les remplacer par des
mmap/munmap (mémoire effectivement libérée par Solaris).
Deuxième question : je sais utiliser mmap/munmap depuis le C. Est-ce
que je peux utiliser la même chose en C++ ? Sinon, comment faire ?
En fait, il faut absolument que je libère ce truc qui me consomme
700 Mo de mémoire :-(
Problème : j'ai un wrapper à la libboost qui a été écrit en C++ et
que j'ai déjà modifié malgré mes faibles compétences C++.
J'ai quelque chose uqi ressemble à une allocation :
static graph_t graph(num_nodes);
J'ai l'impression qu'il s'agit d'une allocation d'un tableau de
structure. num_nodes est un entier tout bête. Dans mon bouquin de
C++, on me dit qu'un tableau est déclaré sous la forme :
static graph_t graph[num_nodes];
Première question : quelle est la différence entre ces deux
syntaxes ?
Bonjour à tous,
Je suis parfaitement débutant en C++ (mais j'essaye de faire des
efforts). Je parle courament C et Fortran depuis de nombreuses
années...
J'utilise à partir d'un programme C/Fortran la libboost. Depuis que
j'ai porté ce code sous Solaris, j'ai des problèmes de mémoire
(free() sous Solaris rend la mémoire à l'application et non au
système, ce qui peut poser des problèmes...).
Je fais donc la course au gaspillage mémoire inutile et surtout,
j'essaye de libérer la mémoire dès qu'elle ne sert plus. Pour ce
faire, je vire autant que faire se peut toute variable statique
inutile, tout couple malloc/free pour les remplacer par des
mmap/munmap (mémoire effectivement libérée par Solaris).
Deuxième question : je sais utiliser mmap/munmap depuis le C. Est-ce
que je peux utiliser la même chose en C++ ? Sinon, comment faire ?
En fait, il faut absolument que je libère ce truc qui me consomme
700 Mo de mémoire :-(
Problème : j'ai un wrapper à la libboost qui a été écrit en C++ et
que j'ai déjà modifié malgré mes faibles compétences C++.
J'ai quelque chose uqi ressemble à une allocation :
static graph_t graph(num_nodes);
J'ai l'impression qu'il s'agit d'une allocation d'un tableau de
structure. num_nodes est un entier tout bête. Dans mon bouquin de
C++, on me dit qu'un tableau est déclaré sous la forme :
static graph_t graph[num_nodes];
Première question : quelle est la différence entre ces deux
syntaxes ?
Bonjour à tous,
Je suis parfaitement débutant en C++ (mais j'essaye de faire des
efforts). Je parle courament C et Fortran depuis de nombreuses
années...
J'utilise à partir d'un programme C/Fortran la libboost. Depuis que
j'ai porté ce code sous Solaris, j'ai des problèmes de mémoire
(free() sous Solaris rend la mémoire à l'application et non au
système, ce qui peut poser des problèmes...).
Je fais donc la course au gaspillage mémoire inutile et surtout,
j'essaye de libérer la mémoire dès qu'elle ne sert plus. Pour ce
faire, je vire autant que faire se peut toute variable statique
inutile, tout couple malloc/free pour les remplacer par des
mmap/munmap (mémoire effectivement libérée par Solaris).
Deuxième question : je sais utiliser mmap/munmap depuis le C. Est-ce
que je peux utiliser la même chose en C++ ? Sinon, comment faire ?
En fait, il faut absolument que je libère ce truc qui me consomme
700 Mo de mémoire :-(
Problème : j'ai un wrapper à la libboost qui a été écrit en C++ et
que j'ai déjà modifié malgré mes faibles compétences C++.
J'ai quelque chose uqi ressemble à une allocation :
static graph_t graph(num_nodes);
J'ai l'impression qu'il s'agit d'une allocation d'un tableau de
structure. num_nodes est un entier tout bête. Dans mon bouquin de
C++, on me dit qu'un tableau est déclaré sous la forme :
static graph_t graph[num_nodes];
Première question : quelle est la différence entre ces deux
syntaxes ?
- ou bien la mémoire n'est plus utilisée par l'application et le
système en a besoin (pour lui ou pour une autre application) et
alors il va swapper la mémoire non utilisée
- ou bien la mémoire n'est plus utilisée par l'application et le
système en a besoin (pour lui ou pour une autre application) et
alors il va swapper la mémoire non utilisée
- ou bien la mémoire n'est plus utilisée par l'application et le
système en a besoin (pour lui ou pour une autre application) et
alors il va swapper la mémoire non utilisée
Problème : j'ai un wrapper à la libboost qui a été écrit en C++ et
que j'ai déjà modifié malgré mes faibles compétences C++.
J'ai quelque chose uqi ressemble à une allocation :
static graph_t graph(num_nodes);
Dans mon bouquin de
C++, on me dit qu'un tableau est déclaré sous la forme :
static graph_t graph[num_nodes];
Deuxième question : je sais utiliser mmap/munmap depuis le C. Est-ce
que je peux utiliser la même chose en C++ ? Sinon, comment faire ?
En fait, il faut absolument que je libère ce truc qui me consomme
700 Mo de mémoire :-(
Problème : j'ai un wrapper à la libboost qui a été écrit en C++ et
que j'ai déjà modifié malgré mes faibles compétences C++.
J'ai quelque chose uqi ressemble à une allocation :
static graph_t graph(num_nodes);
Dans mon bouquin de
C++, on me dit qu'un tableau est déclaré sous la forme :
static graph_t graph[num_nodes];
Deuxième question : je sais utiliser mmap/munmap depuis le C. Est-ce
que je peux utiliser la même chose en C++ ? Sinon, comment faire ?
En fait, il faut absolument que je libère ce truc qui me consomme
700 Mo de mémoire :-(
Problème : j'ai un wrapper à la libboost qui a été écrit en C++ et
que j'ai déjà modifié malgré mes faibles compétences C++.
J'ai quelque chose uqi ressemble à une allocation :
static graph_t graph(num_nodes);
Dans mon bouquin de
C++, on me dit qu'un tableau est déclaré sous la forme :
static graph_t graph[num_nodes];
Deuxième question : je sais utiliser mmap/munmap depuis le C. Est-ce
que je peux utiliser la même chose en C++ ? Sinon, comment faire ?
En fait, il faut absolument que je libère ce truc qui me consomme
700 Mo de mémoire :-(
JKB writes:Bonjour à tous,
Je suis parfaitement débutant en C++ (mais j'essaye de faire des
efforts). Je parle courament C et Fortran depuis de nombreuses
années...
J'utilise à partir d'un programme C/Fortran la libboost. Depuis que
j'ai porté ce code sous Solaris, j'ai des problèmes de mémoire
(free() sous Solaris rend la mémoire à l'application et non au
système, ce qui peut poser des problèmes...).
Je fais donc la course au gaspillage mémoire inutile et surtout,
j'essaye de libérer la mémoire dès qu'elle ne sert plus. Pour ce
faire, je vire autant que faire se peut toute variable statique
inutile, tout couple malloc/free pour les remplacer par des
mmap/munmap (mémoire effectivement libérée par Solaris).
Deuxième question : je sais utiliser mmap/munmap depuis le C. Est-ce
que je peux utiliser la même chose en C++ ? Sinon, comment faire ?
En fait, il faut absolument que je libère ce truc qui me consomme
700 Mo de mémoire :-(
Pourquoi?
Il faudrait vraiment que tu nous explique cette extraordinaire
affirmation que le fait de ne pas rendre la mémoire au système pose
problème.
De deux choses, trois:
- ou bien la mémoire sera utilisée de nouveau par l'application et
alors il serait ridicule de la rendre au système pour la lui
redemander tout de suite après.
- ou bien la mémoire n'est plus utilisée par l'application et le
système n'en a pas besoin et alors à quoi ça sert de la lui rendre?
- ou bien la mémoire n'est plus utilisée par l'application et le
système en a besoin (pour lui ou pour une autre application) et
alors il va swapper la mémoire non utilisée et reprendre les pages
de RAM.
Dans tous le cas, je ne vois pas l'intérêt de rendre la mémoire au
système.
Alors, es tu bien sur d'être dans un cas où c'est nécessaire?
Problème : j'ai un wrapper à la libboost qui a été écrit en C++ et
que j'ai déjà modifié malgré mes faibles compétences C++.
J'ai quelque chose uqi ressemble à une allocation :
static graph_t graph(num_nodes);
J'ai l'impression qu'il s'agit d'une allocation d'un tableau de
structure. num_nodes est un entier tout bête. Dans mon bouquin de
C++, on me dit qu'un tableau est déclaré sous la forme :
static graph_t graph[num_nodes];
Première question : quelle est la différence entre ces deux
syntaxes ?
Dans le second cas, la mémoire est allouée au lancement du programme,
comme mémoire statique. num_nodes * sizeof(graph_t) octets sont
alloués. Cette mémoire n'est pas libérée, tant que le processus n'est
pas tué ou qu'il ne fasse un exec(2) ou similaire.
Dans le premier cas, on ne peut que faire des suppositions, car il
s'agit soit de l'appel au constructeur de la classe graph_t (si c'en
est une), soit de l'appel à la fonction graph (si c'en est une), et
dans ces deux cas, il peut se produire n'importe quoi selon ce qui est
programmé dans ces fonctions.
JKB <knatschke@koenigsberg.fr> writes:
Bonjour à tous,
Je suis parfaitement débutant en C++ (mais j'essaye de faire des
efforts). Je parle courament C et Fortran depuis de nombreuses
années...
J'utilise à partir d'un programme C/Fortran la libboost. Depuis que
j'ai porté ce code sous Solaris, j'ai des problèmes de mémoire
(free() sous Solaris rend la mémoire à l'application et non au
système, ce qui peut poser des problèmes...).
Je fais donc la course au gaspillage mémoire inutile et surtout,
j'essaye de libérer la mémoire dès qu'elle ne sert plus. Pour ce
faire, je vire autant que faire se peut toute variable statique
inutile, tout couple malloc/free pour les remplacer par des
mmap/munmap (mémoire effectivement libérée par Solaris).
Deuxième question : je sais utiliser mmap/munmap depuis le C. Est-ce
que je peux utiliser la même chose en C++ ? Sinon, comment faire ?
En fait, il faut absolument que je libère ce truc qui me consomme
700 Mo de mémoire :-(
Pourquoi?
Il faudrait vraiment que tu nous explique cette extraordinaire
affirmation que le fait de ne pas rendre la mémoire au système pose
problème.
De deux choses, trois:
- ou bien la mémoire sera utilisée de nouveau par l'application et
alors il serait ridicule de la rendre au système pour la lui
redemander tout de suite après.
- ou bien la mémoire n'est plus utilisée par l'application et le
système n'en a pas besoin et alors à quoi ça sert de la lui rendre?
- ou bien la mémoire n'est plus utilisée par l'application et le
système en a besoin (pour lui ou pour une autre application) et
alors il va swapper la mémoire non utilisée et reprendre les pages
de RAM.
Dans tous le cas, je ne vois pas l'intérêt de rendre la mémoire au
système.
Alors, es tu bien sur d'être dans un cas où c'est nécessaire?
Problème : j'ai un wrapper à la libboost qui a été écrit en C++ et
que j'ai déjà modifié malgré mes faibles compétences C++.
J'ai quelque chose uqi ressemble à une allocation :
static graph_t graph(num_nodes);
J'ai l'impression qu'il s'agit d'une allocation d'un tableau de
structure. num_nodes est un entier tout bête. Dans mon bouquin de
C++, on me dit qu'un tableau est déclaré sous la forme :
static graph_t graph[num_nodes];
Première question : quelle est la différence entre ces deux
syntaxes ?
Dans le second cas, la mémoire est allouée au lancement du programme,
comme mémoire statique. num_nodes * sizeof(graph_t) octets sont
alloués. Cette mémoire n'est pas libérée, tant que le processus n'est
pas tué ou qu'il ne fasse un exec(2) ou similaire.
Dans le premier cas, on ne peut que faire des suppositions, car il
s'agit soit de l'appel au constructeur de la classe graph_t (si c'en
est une), soit de l'appel à la fonction graph (si c'en est une), et
dans ces deux cas, il peut se produire n'importe quoi selon ce qui est
programmé dans ces fonctions.
JKB writes:Bonjour à tous,
Je suis parfaitement débutant en C++ (mais j'essaye de faire des
efforts). Je parle courament C et Fortran depuis de nombreuses
années...
J'utilise à partir d'un programme C/Fortran la libboost. Depuis que
j'ai porté ce code sous Solaris, j'ai des problèmes de mémoire
(free() sous Solaris rend la mémoire à l'application et non au
système, ce qui peut poser des problèmes...).
Je fais donc la course au gaspillage mémoire inutile et surtout,
j'essaye de libérer la mémoire dès qu'elle ne sert plus. Pour ce
faire, je vire autant que faire se peut toute variable statique
inutile, tout couple malloc/free pour les remplacer par des
mmap/munmap (mémoire effectivement libérée par Solaris).
Deuxième question : je sais utiliser mmap/munmap depuis le C. Est-ce
que je peux utiliser la même chose en C++ ? Sinon, comment faire ?
En fait, il faut absolument que je libère ce truc qui me consomme
700 Mo de mémoire :-(
Pourquoi?
Il faudrait vraiment que tu nous explique cette extraordinaire
affirmation que le fait de ne pas rendre la mémoire au système pose
problème.
De deux choses, trois:
- ou bien la mémoire sera utilisée de nouveau par l'application et
alors il serait ridicule de la rendre au système pour la lui
redemander tout de suite après.
- ou bien la mémoire n'est plus utilisée par l'application et le
système n'en a pas besoin et alors à quoi ça sert de la lui rendre?
- ou bien la mémoire n'est plus utilisée par l'application et le
système en a besoin (pour lui ou pour une autre application) et
alors il va swapper la mémoire non utilisée et reprendre les pages
de RAM.
Dans tous le cas, je ne vois pas l'intérêt de rendre la mémoire au
système.
Alors, es tu bien sur d'être dans un cas où c'est nécessaire?
Problème : j'ai un wrapper à la libboost qui a été écrit en C++ et
que j'ai déjà modifié malgré mes faibles compétences C++.
J'ai quelque chose uqi ressemble à une allocation :
static graph_t graph(num_nodes);
J'ai l'impression qu'il s'agit d'une allocation d'un tableau de
structure. num_nodes est un entier tout bête. Dans mon bouquin de
C++, on me dit qu'un tableau est déclaré sous la forme :
static graph_t graph[num_nodes];
Première question : quelle est la différence entre ces deux
syntaxes ?
Dans le second cas, la mémoire est allouée au lancement du programme,
comme mémoire statique. num_nodes * sizeof(graph_t) octets sont
alloués. Cette mémoire n'est pas libérée, tant que le processus n'est
pas tué ou qu'il ne fasse un exec(2) ou similaire.
Dans le premier cas, on ne peut que faire des suppositions, car il
s'agit soit de l'appel au constructeur de la classe graph_t (si c'en
est une), soit de l'appel à la fonction graph (si c'en est une), et
dans ces deux cas, il peut se produire n'importe quoi selon ce qui est
programmé dans ces fonctions.
On Sat, 4 Oct 2008 10:53:16 +0000 (UTC), JKB
:Problème : j'ai un wrapper à la libboost qui a été écrit en C++ et
que j'ai déjà modifié malgré mes faibles compétences C++.
J'ai quelque chose uqi ressemble à une allocation :
static graph_t graph(num_nodes);
Déclaration et définition d'un objet "graph" de type "graph_t".
L'équivalent en pseudo-C serait :
static graph_t graph;
graph.constructeur (num_nodes);
La première opération n'alloue que sizeof(graph_t) octets, ce qui
n'est probablement pas beaucoup.
La deuxième est un appel à une fonction (le constructeur), qui peut
faire tout ce que fait une fonction normale, y compris allouer
dynamiquement de la mémoire. Faut regarder la doc de graph_t pour
savoir ce que ce constructeur fait effectivement.Dans mon bouquin de
C++, on me dit qu'un tableau est déclaré sous la forme :
static graph_t graph[num_nodes];
C'est une syntaxe partiellement héritée du C.Deuxième question : je sais utiliser mmap/munmap depuis le C. Est-ce
que je peux utiliser la même chose en C++ ? Sinon, comment faire ?
En fait, il faut absolument que je libère ce truc qui me consomme
700 Mo de mémoire :-(
Quel est ton problème exactement ? Tu dois gérer plus de 2 Go sur un
système 32 bits ? On est quand même en 2008 ; on pourrait croire que
les développements qui ont vraiment besoin du 64 bits se font en 64
bits.
'fin bon, si tu veux transformer l'énorme allocation effectuée par
"static graph_t graph(num_nodes);" en un mmap(), va falloir aller voir
le code du constructeur de graph_t.
On Sat, 4 Oct 2008 10:53:16 +0000 (UTC), JKB
<knatschke@koenigsberg.fr>:
Problème : j'ai un wrapper à la libboost qui a été écrit en C++ et
que j'ai déjà modifié malgré mes faibles compétences C++.
J'ai quelque chose uqi ressemble à une allocation :
static graph_t graph(num_nodes);
Déclaration et définition d'un objet "graph" de type "graph_t".
L'équivalent en pseudo-C serait :
static graph_t graph;
graph.constructeur (num_nodes);
La première opération n'alloue que sizeof(graph_t) octets, ce qui
n'est probablement pas beaucoup.
La deuxième est un appel à une fonction (le constructeur), qui peut
faire tout ce que fait une fonction normale, y compris allouer
dynamiquement de la mémoire. Faut regarder la doc de graph_t pour
savoir ce que ce constructeur fait effectivement.
Dans mon bouquin de
C++, on me dit qu'un tableau est déclaré sous la forme :
static graph_t graph[num_nodes];
C'est une syntaxe partiellement héritée du C.
Deuxième question : je sais utiliser mmap/munmap depuis le C. Est-ce
que je peux utiliser la même chose en C++ ? Sinon, comment faire ?
En fait, il faut absolument que je libère ce truc qui me consomme
700 Mo de mémoire :-(
Quel est ton problème exactement ? Tu dois gérer plus de 2 Go sur un
système 32 bits ? On est quand même en 2008 ; on pourrait croire que
les développements qui ont vraiment besoin du 64 bits se font en 64
bits.
'fin bon, si tu veux transformer l'énorme allocation effectuée par
"static graph_t graph(num_nodes);" en un mmap(), va falloir aller voir
le code du constructeur de graph_t.
On Sat, 4 Oct 2008 10:53:16 +0000 (UTC), JKB
:Problème : j'ai un wrapper à la libboost qui a été écrit en C++ et
que j'ai déjà modifié malgré mes faibles compétences C++.
J'ai quelque chose uqi ressemble à une allocation :
static graph_t graph(num_nodes);
Déclaration et définition d'un objet "graph" de type "graph_t".
L'équivalent en pseudo-C serait :
static graph_t graph;
graph.constructeur (num_nodes);
La première opération n'alloue que sizeof(graph_t) octets, ce qui
n'est probablement pas beaucoup.
La deuxième est un appel à une fonction (le constructeur), qui peut
faire tout ce que fait une fonction normale, y compris allouer
dynamiquement de la mémoire. Faut regarder la doc de graph_t pour
savoir ce que ce constructeur fait effectivement.Dans mon bouquin de
C++, on me dit qu'un tableau est déclaré sous la forme :
static graph_t graph[num_nodes];
C'est une syntaxe partiellement héritée du C.Deuxième question : je sais utiliser mmap/munmap depuis le C. Est-ce
que je peux utiliser la même chose en C++ ? Sinon, comment faire ?
En fait, il faut absolument que je libère ce truc qui me consomme
700 Mo de mémoire :-(
Quel est ton problème exactement ? Tu dois gérer plus de 2 Go sur un
système 32 bits ? On est quand même en 2008 ; on pourrait croire que
les développements qui ont vraiment besoin du 64 bits se font en 64
bits.
'fin bon, si tu veux transformer l'énorme allocation effectuée par
"static graph_t graph(num_nodes);" en un mmap(), va falloir aller voir
le code du constructeur de graph_t.
Le 04-10-2008, ? propos de
Re: Problème d'allocation,
Fabien LE LEZ ?crivait dans fr.comp.lang.c++ :On Sat, 4 Oct 2008 10:53:16 +0000 (UTC), JKB
:Problème : j'ai un wrapper à la libboost qui a été écrit en C++ et
que j'ai déjà modifié malgré mes faibles compétences C++.
J'ai quelque chose uqi ressemble à une allocation :
static graph_t graph(num_nodes);
Déclaration et définition d'un objet "graph" de type "graph_t".
L'équivalent en pseudo-C serait :
static graph_t graph;
graph.constructeur (num_nodes);
La première opération n'alloue que sizeof(graph_t) octets, ce qui
n'est probablement pas beaucoup.
La deuxième est un appel à une fonction (le constructeur), qui peut
faire tout ce que fait une fonction normale, y compris allouer
dynamiquement de la mémoire. Faut regarder la doc de graph_t pour
savoir ce que ce constructeur fait effectivement.Dans mon bouquin de
C++, on me dit qu'un tableau est déclaré sous la forme :
static graph_t graph[num_nodes];
C'est une syntaxe partiellement héritée du C.Deuxième question : je sais utiliser mmap/munmap depuis le C. Est-ce
que je peux utiliser la même chose en C++ ? Sinon, comment faire ?
En fait, il faut absolument que je libère ce truc qui me consomme
700 Mo de mémoire :-(
Quel est ton problème exactement ? Tu dois gérer plus de 2 Go sur un
système 32 bits ? On est quand même en 2008 ; on pourrait croire que
les développements qui ont vraiment besoin du 64 bits se font en 64
bits.
'fin bon, si tu veux transformer l'énorme allocation effectuée par
"static graph_t graph(num_nodes);" en un mmap(), va falloir aller voir
le code du constructeur de graph_t.
Je veux pouvoir le libérer si besoin. Maintenant, je suis sur des
machines massivement parallèles (64 procs, 64 bits, 64 Go de
mémoire [seulement] aujourd'hui et avec un OS 64 bits) et je lance des
calculs d'optimisation sur des cartographies à l'échelle d'un pays.
Chaque calcul élémentaire nécessite le calcul de plusieurs centaines
de trajets dans la cartographie _complète_. J'utilise aussi à des
fins de développement du 32 bits avec le même OS (moins de mémoire
et moins de procs) et le problème reste le même. À l'extrême limite,
ça pourrait très bien fonctionner entièrement en 32 bits,
puisqu'aucun processus ne consomme plus de 1,5 Go.
Par ailleurs, ces processus sont _indépendants_ entre eux.
Je ne peux pas me permettre que chaque processus me prenne 2 * 1,5
Go de mémoire pour seulement 1,5 Go utile. J'en suis donc à
optimiser l'utilisation de la mémoire au mieux pour éviter que ça
swappe.
Le 04-10-2008, ? propos de
Re: Problème d'allocation,
Fabien LE LEZ ?crivait dans fr.comp.lang.c++ :
On Sat, 4 Oct 2008 10:53:16 +0000 (UTC), JKB
<knatschke@koenigsberg.fr>:
Problème : j'ai un wrapper à la libboost qui a été écrit en C++ et
que j'ai déjà modifié malgré mes faibles compétences C++.
J'ai quelque chose uqi ressemble à une allocation :
static graph_t graph(num_nodes);
Déclaration et définition d'un objet "graph" de type "graph_t".
L'équivalent en pseudo-C serait :
static graph_t graph;
graph.constructeur (num_nodes);
La première opération n'alloue que sizeof(graph_t) octets, ce qui
n'est probablement pas beaucoup.
La deuxième est un appel à une fonction (le constructeur), qui peut
faire tout ce que fait une fonction normale, y compris allouer
dynamiquement de la mémoire. Faut regarder la doc de graph_t pour
savoir ce que ce constructeur fait effectivement.
Dans mon bouquin de
C++, on me dit qu'un tableau est déclaré sous la forme :
static graph_t graph[num_nodes];
C'est une syntaxe partiellement héritée du C.
Deuxième question : je sais utiliser mmap/munmap depuis le C. Est-ce
que je peux utiliser la même chose en C++ ? Sinon, comment faire ?
En fait, il faut absolument que je libère ce truc qui me consomme
700 Mo de mémoire :-(
Quel est ton problème exactement ? Tu dois gérer plus de 2 Go sur un
système 32 bits ? On est quand même en 2008 ; on pourrait croire que
les développements qui ont vraiment besoin du 64 bits se font en 64
bits.
'fin bon, si tu veux transformer l'énorme allocation effectuée par
"static graph_t graph(num_nodes);" en un mmap(), va falloir aller voir
le code du constructeur de graph_t.
Je veux pouvoir le libérer si besoin. Maintenant, je suis sur des
machines massivement parallèles (64 procs, 64 bits, 64 Go de
mémoire [seulement] aujourd'hui et avec un OS 64 bits) et je lance des
calculs d'optimisation sur des cartographies à l'échelle d'un pays.
Chaque calcul élémentaire nécessite le calcul de plusieurs centaines
de trajets dans la cartographie _complète_. J'utilise aussi à des
fins de développement du 32 bits avec le même OS (moins de mémoire
et moins de procs) et le problème reste le même. À l'extrême limite,
ça pourrait très bien fonctionner entièrement en 32 bits,
puisqu'aucun processus ne consomme plus de 1,5 Go.
Par ailleurs, ces processus sont _indépendants_ entre eux.
Je ne peux pas me permettre que chaque processus me prenne 2 * 1,5
Go de mémoire pour seulement 1,5 Go utile. J'en suis donc à
optimiser l'utilisation de la mémoire au mieux pour éviter que ça
swappe.
Le 04-10-2008, ? propos de
Re: Problème d'allocation,
Fabien LE LEZ ?crivait dans fr.comp.lang.c++ :On Sat, 4 Oct 2008 10:53:16 +0000 (UTC), JKB
:Problème : j'ai un wrapper à la libboost qui a été écrit en C++ et
que j'ai déjà modifié malgré mes faibles compétences C++.
J'ai quelque chose uqi ressemble à une allocation :
static graph_t graph(num_nodes);
Déclaration et définition d'un objet "graph" de type "graph_t".
L'équivalent en pseudo-C serait :
static graph_t graph;
graph.constructeur (num_nodes);
La première opération n'alloue que sizeof(graph_t) octets, ce qui
n'est probablement pas beaucoup.
La deuxième est un appel à une fonction (le constructeur), qui peut
faire tout ce que fait une fonction normale, y compris allouer
dynamiquement de la mémoire. Faut regarder la doc de graph_t pour
savoir ce que ce constructeur fait effectivement.Dans mon bouquin de
C++, on me dit qu'un tableau est déclaré sous la forme :
static graph_t graph[num_nodes];
C'est une syntaxe partiellement héritée du C.Deuxième question : je sais utiliser mmap/munmap depuis le C. Est-ce
que je peux utiliser la même chose en C++ ? Sinon, comment faire ?
En fait, il faut absolument que je libère ce truc qui me consomme
700 Mo de mémoire :-(
Quel est ton problème exactement ? Tu dois gérer plus de 2 Go sur un
système 32 bits ? On est quand même en 2008 ; on pourrait croire que
les développements qui ont vraiment besoin du 64 bits se font en 64
bits.
'fin bon, si tu veux transformer l'énorme allocation effectuée par
"static graph_t graph(num_nodes);" en un mmap(), va falloir aller voir
le code du constructeur de graph_t.
Je veux pouvoir le libérer si besoin. Maintenant, je suis sur des
machines massivement parallèles (64 procs, 64 bits, 64 Go de
mémoire [seulement] aujourd'hui et avec un OS 64 bits) et je lance des
calculs d'optimisation sur des cartographies à l'échelle d'un pays.
Chaque calcul élémentaire nécessite le calcul de plusieurs centaines
de trajets dans la cartographie _complète_. J'utilise aussi à des
fins de développement du 32 bits avec le même OS (moins de mémoire
et moins de procs) et le problème reste le même. À l'extrême limite,
ça pourrait très bien fonctionner entièrement en 32 bits,
puisqu'aucun processus ne consomme plus de 1,5 Go.
Par ailleurs, ces processus sont _indépendants_ entre eux.
Je ne peux pas me permettre que chaque processus me prenne 2 * 1,5
Go de mémoire pour seulement 1,5 Go utile. J'en suis donc à
optimiser l'utilisation de la mémoire au mieux pour éviter que ça
swappe.
Le 04-10-2008, ? propos de
Re: Problème d'allocation,
Pascal J. Bourguignon ?crivait dans fr.comp.lang.c++ :JKB writes:Bonjour à tous,
Je suis parfaitement débutant en C++ (mais j'essaye de faire des
efforts). Je parle courament C et Fortran depuis de nombreuses
années...
J'utilise à partir d'un programme C/Fortran la libboost. Depuis que
j'ai porté ce code sous Solaris, j'ai des problèmes de mémoire
(free() sous Solaris rend la mémoire à l'application et non au
système, ce qui peut poser des problèmes...).
[...]
Alors, es tu bien sur d'être dans un cas où c'est nécessaire?
Oui, parce que cette allocation prend 1,5 Go de mémoire, que le code
fait un fork() pour une sombre histoire de surveillance de processus
et de cloture de pipes et que je ne vois aucune raison de traîner
1,5 Go de mémoire dans un processus qui devrait faire au plus
quelques Mo.
Le problème est que cette non libération de données
inutiles provoque un doublement de l'espace mémoire occupé et que la
machine qui fait tourner le truc swappe non pas parce qu'elle n'a
pas assez de mémoire physique, mais parce qu'elle passe son temps à
coller dans le swap ces données inutiles à la moitié des processus.
Dans le premier cas, on ne peut que faire des suppositions, car il
s'agit soit de l'appel au constructeur de la classe graph_t (si c'en
est une), soit de l'appel à la fonction graph (si c'en est une), et
dans ces deux cas, il peut se produire n'importe quoi selon ce qui est
programmé dans ces fonctions.
Le graph_t est déclaré comme suit :
typedef adjacency_list < listS, vecS, directedS, Vertex, Edge> graph_t;
J'avoue que cela ne m'aide pas...
Le 04-10-2008, ? propos de
Re: Problème d'allocation,
Pascal J. Bourguignon ?crivait dans fr.comp.lang.c++ :
JKB <knatschke@koenigsberg.fr> writes:
Bonjour à tous,
Je suis parfaitement débutant en C++ (mais j'essaye de faire des
efforts). Je parle courament C et Fortran depuis de nombreuses
années...
J'utilise à partir d'un programme C/Fortran la libboost. Depuis que
j'ai porté ce code sous Solaris, j'ai des problèmes de mémoire
(free() sous Solaris rend la mémoire à l'application et non au
système, ce qui peut poser des problèmes...).
[...]
Alors, es tu bien sur d'être dans un cas où c'est nécessaire?
Oui, parce que cette allocation prend 1,5 Go de mémoire, que le code
fait un fork() pour une sombre histoire de surveillance de processus
et de cloture de pipes et que je ne vois aucune raison de traîner
1,5 Go de mémoire dans un processus qui devrait faire au plus
quelques Mo.
Le problème est que cette non libération de données
inutiles provoque un doublement de l'espace mémoire occupé et que la
machine qui fait tourner le truc swappe non pas parce qu'elle n'a
pas assez de mémoire physique, mais parce qu'elle passe son temps à
coller dans le swap ces données inutiles à la moitié des processus.
Dans le premier cas, on ne peut que faire des suppositions, car il
s'agit soit de l'appel au constructeur de la classe graph_t (si c'en
est une), soit de l'appel à la fonction graph (si c'en est une), et
dans ces deux cas, il peut se produire n'importe quoi selon ce qui est
programmé dans ces fonctions.
Le graph_t est déclaré comme suit :
typedef adjacency_list < listS, vecS, directedS, Vertex, Edge> graph_t;
J'avoue que cela ne m'aide pas...
Le 04-10-2008, ? propos de
Re: Problème d'allocation,
Pascal J. Bourguignon ?crivait dans fr.comp.lang.c++ :JKB writes:Bonjour à tous,
Je suis parfaitement débutant en C++ (mais j'essaye de faire des
efforts). Je parle courament C et Fortran depuis de nombreuses
années...
J'utilise à partir d'un programme C/Fortran la libboost. Depuis que
j'ai porté ce code sous Solaris, j'ai des problèmes de mémoire
(free() sous Solaris rend la mémoire à l'application et non au
système, ce qui peut poser des problèmes...).
[...]
Alors, es tu bien sur d'être dans un cas où c'est nécessaire?
Oui, parce que cette allocation prend 1,5 Go de mémoire, que le code
fait un fork() pour une sombre histoire de surveillance de processus
et de cloture de pipes et que je ne vois aucune raison de traîner
1,5 Go de mémoire dans un processus qui devrait faire au plus
quelques Mo.
Le problème est que cette non libération de données
inutiles provoque un doublement de l'espace mémoire occupé et que la
machine qui fait tourner le truc swappe non pas parce qu'elle n'a
pas assez de mémoire physique, mais parce qu'elle passe son temps à
coller dans le swap ces données inutiles à la moitié des processus.
Dans le premier cas, on ne peut que faire des suppositions, car il
s'agit soit de l'appel au constructeur de la classe graph_t (si c'en
est une), soit de l'appel à la fonction graph (si c'en est une), et
dans ces deux cas, il peut se produire n'importe quoi selon ce qui est
programmé dans ces fonctions.
Le graph_t est déclaré comme suit :
typedef adjacency_list < listS, vecS, directedS, Vertex, Edge> graph_t;
J'avoue que cela ne m'aide pas...
Je viens de trouver un clear() qui semble vider le graph. Je vais de
ce pas tester... en espérant que cela rende la mémoire au système et
pas à l'application...
Je viens de trouver un clear() qui semble vider le graph. Je vais de
ce pas tester... en espérant que cela rende la mémoire au système et
pas à l'application...
Je viens de trouver un clear() qui semble vider le graph. Je vais de
ce pas tester... en espérant que cela rende la mémoire au système et
pas à l'application...
JKB wrote:Je viens de trouver un clear() qui semble vider le graph. Je vais de
ce pas tester... en espérant que cela rende la mémoire au système et
pas à l'application...
Il n'y a pas de raison, ça va juste faire un free. C'est l'allocateur
qu'il faut changer.
J'ai l'impression que vous cherchez plutôt une implémentation de
malloc/free utilisant mmap (et munmap) plutôt que sbrk à interposer
devant le malloc de la libc. Ça doit exister, mais je ne sais pas si une
des 15 implémentations de malloc livrées avec solaris le fait.
JKB wrote:
Je viens de trouver un clear() qui semble vider le graph. Je vais de
ce pas tester... en espérant que cela rende la mémoire au système et
pas à l'application...
Il n'y a pas de raison, ça va juste faire un free. C'est l'allocateur
qu'il faut changer.
J'ai l'impression que vous cherchez plutôt une implémentation de
malloc/free utilisant mmap (et munmap) plutôt que sbrk à interposer
devant le malloc de la libc. Ça doit exister, mais je ne sais pas si une
des 15 implémentations de malloc livrées avec solaris le fait.
JKB wrote:Je viens de trouver un clear() qui semble vider le graph. Je vais de
ce pas tester... en espérant que cela rende la mémoire au système et
pas à l'application...
Il n'y a pas de raison, ça va juste faire un free. C'est l'allocateur
qu'il faut changer.
J'ai l'impression que vous cherchez plutôt une implémentation de
malloc/free utilisant mmap (et munmap) plutôt que sbrk à interposer
devant le malloc de la libc. Ça doit exister, mais je ne sais pas si une
des 15 implémentations de malloc livrées avec solaris le fait.
J'ai l'impression que vous cherchez plutôt une implémentation de
malloc/free utilisant mmap (et munmap) plutôt que sbrk à interposer
devant le malloc de la libc. Ça doit exister, mais je ne sais pas si une
des 15 implémentations de malloc livrées avec solaris le fait.
C'est exactement ça et je n'ai pas trouvé. Je me demande même si ça
existe...
JKB
J'ai l'impression que vous cherchez plutôt une implémentation de
malloc/free utilisant mmap (et munmap) plutôt que sbrk à interposer
devant le malloc de la libc. Ça doit exister, mais je ne sais pas si une
des 15 implémentations de malloc livrées avec solaris le fait.
C'est exactement ça et je n'ai pas trouvé. Je me demande même si ça
existe...
JKB
J'ai l'impression que vous cherchez plutôt une implémentation de
malloc/free utilisant mmap (et munmap) plutôt que sbrk à interposer
devant le malloc de la libc. Ça doit exister, mais je ne sais pas si une
des 15 implémentations de malloc livrées avec solaris le fait.
C'est exactement ça et je n'ai pas trouvé. Je me demande même si ça
existe...
JKB