Discussion :

[Emmanuel_exeter]

Bonjour,

Je programme en C++ avec Code::Block sous Windows 7.

J'ai deux tableaux: un de dimension 3000 et un autre de dimension 1500. Les éléments sont des tableau de dimensions 500000 de char.

La compilation se passe sans problème mais quand inexécutable se lance le message de fin d’exécution apparait directement.

Je voudrai savoir si il a des paramètres à modifier pour permettre a l exécutable de se lancer normalement.

Merci

[Neckara]

Bonjour,

Peux-tu nous montrer le message d'erreur ?
Peux-tu nous montrer ton code?

As-tu essayé de passer par des tableau de pointeur au lieu de faire des tableau 2D ?

[Ekleog]

(3000+1500)*500000 = 2250000000
2,25G.
Normal que windows préfère faire planter ton programme que de lui allouer 2,25G de stack.
Peut-être faudrait-il essayer de le lancer en mode administrateur, si il n'y a aucun moyen de se débrouiller pour prendre moins de mémoire ?

[Emmanuel_exeter]

(3000+1500)*500000 = 2250000000
2,25G.
Normal que windows préfère faire planter ton programme que de lui allouer 2,25G de stack.
Peut-être faudrait-il essayer de le lancer en mode administrateur, si il n'y a aucun moyen de se débrouiller pour prendre moins de mémoire ?

Oui le probleme est la evidemment. Notons que ca marche avec (1500+1500)*500000
De plus, 2250000000 octets ne fais en fait "que" 2,14Go !

J'ai essayer de lancer code::block en mode administrateur mais c est exactement pareil. Je ne peux pas lancer l executable en mode administrateur car quand je lance le .exe cree windows me dit: BlahBlahBlah.exe is not a valid Win32 application.

Je pourrai me debrouiller pour diviser la taille par 4 mais je vais avoir plus de donnees a prendre en compte bientot donc ca ne fera que repouser le probleme...

Merci

[Ekleog]

Oui le probleme est la evidemment. Notons que ca marche avec (1500+1500)*500000
De plus, 2250000000 octets ne fais en fait "que" 2,14Go !

Faux. Ca fait 2,25Go. Et 2,095Gio. Oui, les unités standard sont moches.
"Preuve" en une session shell :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
$ units 
2526 units, 72 prefixes, 56 nonlinear units
 
You have: 2250000000 octets
You want: gigaoctets
        * 2.25
        / 0.44444444
You have: 2250000000 octets
You want: gibioctets
        * 2.0954758
        / 0.47721859

J'ai essayer de lancer code::block en mode administrateur mais c est exactement pareil. Je ne peux pas lancer l executable en mode administrateur car quand je lance le .exe cree windows me dit: BlahBlahBlah.exe is not a valid Win32 application.

Il y a un problème avec ta compilation alors. Il ne dit que ça ? As-tu bien tenté de recompiler et d'aller chercher la version release ?

Je pourrai me debrouiller pour diviser la taille par 4 mais je vais avoir plus de donnees a prendre en compte bientot donc ca ne fera que repouser le probleme...

Merci

Je ne sais pas combien tu as de RAM, mais si tu peux diviser la taille par 4, fais le. Parce que mieux vaut ça qu'acheter 4 fois plus de RAM. Non ?

Par ailleurs, il est normal que windows bloque une utilisation qui tente d'utiliser autant de RAM. Sinon, tu en lances 3, et tu fais crasher l'ordinateur. Comportement d'un virus basique.

[Emmanuel_exeter]

A la compilation j ai ca:

Compiling: main1.cpp
Process terminated with status 0 (0 minutes, 1 seconds)
0 errors, 0 warnings

mais quand il execute, j ai ca:

Process returned 0 (0x0) execution time : 0.002 s
Press any key to continue.

et la version release n est pas une application Windows valide.

J ai 8.00 GB de RAM donc normalement assez pour gerer mais tableaux.

Merci

[Emmanuel Deloget]

Oui le probleme est la evidemment. Notons que ca marche avec (1500+1500)*500000
De plus, 2250000000 octets ne fais en fait "que" 2,14Go !

J'ai essayer de lancer code::block en mode administrateur mais c est exactement pareil. Je ne peux pas lancer l executable en mode administrateur car quand je lance le .exe cree windows me dit: BlahBlahBlah.exe is not a valid Win32 application.

Je pourrai me debrouiller pour diviser la taille par 4 mais je vais avoir plus de donnees a prendre en compte bientot donc ca ne fera que repouser le probleme...

Merci

2,14 Go, c'est un poil supérieur à ce que Win32 accepte d'allouer à chaque process (2Go). A moins d'utiliser le flag de boot correspondant (permettant d'avoir 3Go pour chaque processus), je ne vois pas comment tu peux espérer que ça passe. Win64 n'est guère plus gentil avec toi : la limite de 2 Go est gardée par défaut si je me rappelle tout bien.

Tu as un gros, gros problème, principalement lié à tes algorithmes. Pense quand même que Rage d'id Software nécessite 1 To de données lorsque celles-ci sont décompressée. Question 1 : est-ce que ces 1 To sont tout le temps nécessaire ? Probablement pas. Parce que le jeu propose des algorithmes relativement malin pour utiliser ces données au mieux. D'où la question 2 : a tu besoin de 2 Go de données tout le temps ? Surement pas non plus.

Bref, ta seule solution, c'est de retourner à tes cahier, et de réfléchir à une solution simple, efficace, pour contourner un problème de big data. Selon le type de données (numériques, texte, ...) la solution peut varier du tout au tout.

[pyros]

a tu besoin de 2 Go de données tout le temps ? Surement pas non plus

Ca peux se justifier dans certain cas. Sans même parler de clusters ou de gros systèmes, j'ai déjà vue des applis tourner en consommant une 10aine Go de ram sur un PC "classique". Mais pas en une seul zone mémoire et encore moins en statique.

[Arzar]

Win64 n'est guère plus gentil avec toi : la limite de 2 Go est gardée par défaut si je me rappelle tout bien.

SI je comprends bien http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx IMAGE_FILE_LARGE_ADDRESS_AWARE est activé par défaut sur Win64, donc apparemment il n'y a pas besoin de faire qqchose de spécial pour profiter des 8TB de mémoire virtuelle assignable (à part compiler en mode 64 bits)

User-mode virtual address space for each 64-bit process :

With IMAGE_FILE_LARGE_ADDRESS_AWARE set (default):
x64: 8 TB
Intel Itanium-based systems: 7 TB

With IMAGE_FILE_LARGE_ADDRESS_AWARE cleared:
2 GB

[fregolo52]

a tu besoin de 2 Go de données tout le temps ? Surement pas non plus.

Pour en revenir à mon expérience : système d'écoute (espionnage ?) temps réel conçu par un grand groupe mondial pour les Armées, il faut en permanence énormément de données pour décoder/décrypter les informations.
Mais bon, ne connaissant pas la conception du programme de Emmanuel_exeter, il est difficile de savoir s'il est possible de "partager" toutes les données dans différents processus pour avoir au total toujours 2Go d'allouer mais par plusieurs processus.

[Emmanuel_exeter]

oui j ai besoin d autant et je vais meme avoir besoin de plus !
Je ne sais pas si j'ai le droit de dire pourquoi j ai besoin d autant de donnees ... je crois que j ai une clause de confidentialite, je vais verifie.

Je ne peux rien désallouer, j ai besoin de tout en meme temps.

Je sais ce qui est modifie et quand c est modifie (j implement seul un algorithme)
Je ne programme pas pour suivre des principes mais pour obtenir des resultats et en plus je ne suis pas en multithread.

J ai 8Go de RAM et 12Go de cache donc il doit y avoir un moyen de le forcer a accepter. Je pense peut etre qu avec une machine virtuelle il y a moins de verification.

[pyros]

Question idiote peut être mais tu as bien un windows 64 bits ?

En 32 bits tu es bridé à 3Go (4Go en théorie, mais windows bride la mémoire). Ca plus la fragmentation, il est fort probable que le système n'arrive pas à t'allouer toute la mémoire que tu demande.

Sinon je rejoins l'avis de Neckara. Avoir besoin d'autant de mémoire en un seul block révèle souvent une erreur de conception dans l'algo. Pour travailler sur de l'out of core avec des données pouvant aller au To, je t'assure qu'on alloue jamais plus de quelques centaines de Mo en une fois...

[fregolo52]

Sinon je rejoins l'avis de Neckara. Avoir besoin d'autant de mémoire en un seul block révèle souvent une erreur de conception dans l'algo. Pour travailler sur de l'out of core avec des données pouvant aller au To, je t'assure qu'on alloue jamais plus de quelques centaines de Mo en une fois...

Ca dépend du type de données et de l'analyse que tu en fais.

Pour avoir bosser sur les systèmes d'écoutes, les quantités de données à traiter sont énormes.

[pyros]

Ca dépend du type de données et de l'analyse que tu en fais.

Pour avoir bosser sur les systèmes d'écoutes, les quantités de données à traiter sont énormes.

Mais de là à allouer 2Go dans une variable global au début du programme, je suis sceptique... Ou peut être cas très spécifique d'embarqué où l'allocation dynamique est interdite. On voit de ces choses des fois

[fregolo52]

Mais de là à allouer 2Go dans une variable global au début du programme, je suis sceptique... Ou peut être cas très spécifique d'embarqué où l'allocation dynamique est interdite. On voit de ces choses des fois

On avait un cluster de PC.
On avait plusieurs processus qui allouaient qq centaines de Mo. Et on en avait 1 (le superviseur) qui allouait presque 2Go. Comme je l'ai dit (hier), c'était de l'allocation dynamique. On n'a jamais eu de souci (sous SUSE 10)
Ce n'est pas moi qui ait fait le superviseur, donc je ne peux pas dire si c'était un seul malloc ou plusieurs.

@Emmanuel_exeter, ton processus doit être multi-plateforme ?

[jblecanard]

Utiliser MinGW, même 64 bits, est plutôt une mauvaise idée. Ce serait plus malin d'utiliser Visual C++ Express, surtout lorsqu'on touche un peu aux limites de l'OS.

Je ne programme pas pour suivre des principes mais pour obtenir des resultats

Les principes ne sont pas là pour faire beau mais pour aider à construire correctement des programmes qui donnent des résultats. Si tu ne veux pas faire d'efforts, tu prends Matlab ou Python, pas C++.

[Invité]

et le tableau c'est obligatoire?

Parce que bon une zone contigue de memoire de 2Go...
pourquoi ne pas stocker des tableaux de tableaux...c'est deja un peu moins contraignant...