Limites de l'allocation dynamique en C

Version imprimable

21/01/2016, 18h16
Zinoubad

Limites de l'allocation dynamique en C

Bonjour,

Pour un de mes programmes j'ai besoin de manipuler des tableaux d'entiers 3D de t'aille approximative 10000*100*10000. je rencontre bien évidemment des problèmes pour cela notamment sur 4g de RAM (possibilité de tester sur plus). On essaye de me convaincre de passer au C++ qui pour lui l'allocation dynamique est optimale (étant déjà codé ) et de profiter des classes vector et array. Ma question: est ce que cela est vrai??? pourrais je économiser la mémoire utilisée par mon programme en utilisant le C++??? Merci.;););););)
21/01/2016, 20h08
Matt_Houston

Euh.. non si ce n'est pas possible en C ça ne le sera pas plus en C++. Là tu outrepasses les limites de la machine, pas celles du langage de programmation.

Pour réaliser cela il faut mapper ta ressource (fichier(s) sur disque, ressource réseau...) en mémoire système, c'est-à-dire en avoir une vue restreinte dans un tampon en RAM. L'idée étant que tu rapatries régulièrement les parties que tu souhaites consulter tout en renvoyant les changements. L'implémentation d'un tel système dépend énormément des données à traiter et de la manière dont on prévoit d'y accéder. Alternativement tu peux regarder du côté d'appels système du type mmap (non portable).

Je ne sais pas quel est ton niveau, mais c'est loin d'être trivial.

Tu ne peux pas foutre tout ça dans une base de données MySQL ou PostGre ?
21/01/2016, 21h02
dalfab

Des tableaux de taille 37G 8O
Même sur gros système, je n'ai jamais vu cela.
Je pense que dans tous les cas, il faudra gérer cela de manière particulière, ou bien attendre la création d'une machine suffisamment puissante.
21/01/2016, 23h04
Zinoubad

Citation:

Envoyé par dalfab

Des tableaux de taille 37G 8O
Même sur gros système, je n'ai jamais vu cela.

La taille est de 20G0 si je code en short type.

Citation:

Envoyé par Matt_Houston

Euh.. non si ce n'est pas possible en C ça ne le sera pas plus en C++. Là tu outrepasses les limites de la machine, pas celles du langage de programmation.

Ceci répond parfaitement à ma question je te remercie.

Citation:

Envoyé par Matt_Houston

. Tu ne peux pas foutre tout ça dans une base de données MySQL ou PostGre ?

J'ai songé à les conserver sur un .txt et avoir un compromis entre vitesse de performance et mémoire, mais comme il s'agit d'un 3D je bloque un peu dans l'accès aux éléments.
22/01/2016, 08h19
ternel

Ca m'étonnerait que tu aie réellement besoin de tout cela en même temps.
Ne pourrais-tu pas répartir le calcul par blocs?
22/01/2016, 11h54
dinobogan

Quels sont les traitements à appliquer sur ces données ?
22/01/2016, 12h14
stendhal666

Citation:

J'ai songé à les conserver sur un .txt et avoir un compromis entre vitesse de performance et mémoire, mais comme il s'agit d'un 3D je bloque un peu dans l'accès aux éléments.

Je pense que tu vas devoir en passer par là. Quelles sont tes difficultés pour accéder aux éléments?
25/01/2016, 23h46
Aurel-R

Code:

Quels sont les traitements à appliquer sur ces données ?

+1

Il nous faut beaucoup plus de détails sur ce que tu cherches à faire. Oui en short tu gagneras peut être un peu de place, la encore faudrait en savoir plus sur les données. Quel est ton niveau par rapport à la gestion de la mémoire ? Quelle plateforme (Linux/Windows) ? Ton programme est-il dédié uniquement à la manipulation de tableaux 3D ou effectue t-il d'autre opérations ? ( en continue/différé) ? Ces données seront-elles partagées entre différentes machines une fois traitées ?
Au final on peut toujours trouver quelque chose d’efficace (mais surement au détriment de la flexibilité, si ton programme dois évoluer sur le long terme)

Code:

J'ai songé à les conserver sur un .txt et avoir un compromis entre vitesse de performance et mémoire, mais comme il s'agit d'un 3D je bloque un peu dans l'accès aux éléments.

As-tu pensé à un tableau de structures ? Ça sera plus simple à traiter. Oui il te faudra passer par un fichier externe pour sauvegarder et lire. En utilisant mmap() intelligemment tu te débarrasseras de pas mal d'appels systèmes d'accès au fichier (étant chargé en mémoire. Il se manipulera donc beaucoup plus facilement !)
26/01/2016, 18h25
Zinoubad

Citation:

Envoyé par Aurel-R

Citation:

Quels sont les traitements à appliquer sur ces données ?

+1

Il nous faut beaucoup plus de détails...............

Alors, Merci d'abord, et puis pour répondre, je suis passée au type short et j'ai pu gagner de la mémoire, j'ai revu tout le code pratiquement et je suis passée de 2 tableau à un seul (réinitialiser à chaque fois et recalculer sur la même SSD) au détriment du temps de calcul. mais je reste dans le raisonnable. Les tableaux 3D sont la SSD la plus importante, le reste se fait sans soucis (des calculs principalement en continue). Les données ne seront pas partagées. En ce qui concerne la plate forme, je suis suis windows, j'ai eu la chance de trouver une machine à 32Go de Ram sous linux, Mais à ma grande déception le code qui fonctionne parfaitement chez moi bloque sur une ligne parfaitement banale: " Typedef short int monType " et il m'annonce : redefinition of type monType. j'essaye de regler ça au plus vite mais ça bloque toujours
26/01/2016, 19h36
Matt_Houston

Tu ne réponds pas vraiment à la question citée, c'est plus que vague. Mais tu es peut-être sous NDA... :mrgreen:
28/01/2016, 15h48
Médinoc
Citation:

Envoyé par Zinoubad

J'ai songé à les conserver sur un .txt et avoir un compromis entre vitesse de performance et mémoire, mais comme il s'agit d'un 3D je bloque un peu dans l'accès aux éléments.

Non, pas un texte. Pour ça, il te faudrait un fichier binaire (indispensable pour de l'accès aléatoire). Idéalement, tu dois identifier dans quelle dimension les valeurs doivent être "proches" en mémoire, et mettre cette dimension "en dernier".

Et ensuite, faire un paging: Lorsque tu as besoin de la valeur, monTableau[a][b][c], ce dont tu as besoin c'est la page contenant, par exemple, tout monTableau[a][b]. Ton code utilisateur va donc la réclamer à un gestionnaire de pages que tu auras aussi implémenté.
- Si la page est déjà chargée dans le gestionnaire, il peut simplement la retourner et permettre l'accès aux valeurs qui s'y trouvent.
- Sinon, il faut la charger. Et si le gestionnaire de pages est plein, il faut en libérer une: tu choisis dans ton gestionnaire de pages celle que tu vas sacrifier; tu écris dans ton fichier, au bon emplacement, tout le contenu de ladite page; puis tu charge celle dont tu as besoin.
Optionnellement, tu pourrais aussi inclure un mécanisme pour savoir si une page est accédée en écriture ou en lecture, pour savoir si tu dois ou non passer par l'étape "écrire le contenu de la page dans le fichier".

Noter que l'OS peut avoir des mécanismes de mapping pouvant faire une partie du travail pour toi (comme dans le cas des File Mapping de Windows, lire et écrire le contenu des pages, et probablement aussi détecter les modifications).