Version imprimable
salut.
A confirmer. tu ne peux pas allouer 2go comme ça. tu exploses la pile.
par contre faire une allocation dynamique avec un bon vieux malloc ou new ne posera pas de souci.
c'est ce que j'ai constaté quand j'ai voulu allouer 600Mo dans une fonction.
C'est bien de lire les messages précédents avant de poster.Citation:
Envoyé par fregolo52
Là il alloue sur le tas puisqu'il utilise des variables globales.
Mais ce qui m'étonne un peu, c'est que sous windows, on peut allouer plus grâce à des variables globales qu'avec un new, alors que sous débian (virtualisé en plus), c'est l'inverse et j'ai même réussi à allouer l'espace qu'il souhaitait.
Ce qui est aussi marrant, c'est que le fait de faire planter l'allocation pour les variables globales fait planter le programme avant l'entrée dans le main et que ce dernier retourne 0 sans aucun message d'erreur.
Mais je pense que dans ce cas là, c'est surtout un problème de conception.
dsl. pas bien vu sur l écran du portable.
je ne suis pas expert linux. mais quasi tout est configurable. il doit exister des variables à augmenter pour son souci.
sous Windows, il y a la base de registre. c'est comme ça qu'on avait réglé des pb de taille de stack ip.
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.
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...
Ca dépend du type de données et de l'analyse que tu en fais.Citation:
Envoyé par pyros
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 :mrgreen:Citation:
Envoyé par fregolo52
On avait un cluster de PC.Citation:
Envoyé par pyros
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 ?
Non, l important est de faire tourner l algo est d avoir des resultats
En dynamique OK. Mais en statique je trouve ça quand même très osé...Citation:
c'était de l'allocation dynamique
@Emmanuel_exeter Alors, 32 ou 64bits ? Et tu es sûr de ne pas vouloir utiliser des new ou des std::vector ? Ca m'étonne quand même que la différence de perf soit si élevée.
J'ai pris le train en marche et j'ai du mal à accrocher. :aie:
Pour compléter les tests de Neckara.
Je viens de mettre ton code dans Visual Studio.
avec #define A 490294Le linker m'insulte en disant :
Donc sous Windows (XP dans mon cas), on est limité à environ 80Mo en allocation statique.Citation:
LINK : fatal error LNK1248: image size (934C1000) exceeds maximum allowable size (80000000)
Erreur !!!
avec #define A 49294Il ne me dit rien alors qu'on alloue 200Mo. :koi:
[edit]
ca ne résoud pas le pb, mais j'ai trouvé un truc intéressant ici.
Thus if you allocate an array dynamically (the limit is large and described in detail by other posts.
int a1 = new int[SIZE]; // SIZE limited only by OS/HardwareAlternatively if the array is allocated on the stack then you are limited by the size of the stack frame. N.B. vectors and other containers have a small presence in the stack but usually the bulk of the data will be on the heap.
int a2[SIZE]; // SIZE limited by COMPILER to the size of the stack frame
64 bits
D'après l'article suivant http://www.viva64.com/en/k/0036/ les tailles maximales des différents segments de mémoire sous Windows sont :
Static data (variables globales) : 2Gb (32 bits et 64bits)
Stack data : 1mb (32 bits et 64 bits)
Dynamic data (Heap): 2Gb en 32 bits 8Tb en 64 bits
Donc le seul moyen de manipuler des tableaux de plus de 2Gb est de les allouer dynamiquement (avec des new[]/delete[]) et de compiler en 64 bits
Si ça plante encore à l’exécution, alors c'est que :
- Il y a un autre bug ailleurs dans le programme.
Ou :
- Le projet est configuré pour compiler en 32 bits. Je ne connais pas Code::blocks mais je suis presque certain que par défaut Code::block compile pour du 32 bits.
Oui, par défaut C::B est "livré" avec minGW32, il faut installer (séparément) MinGW64 et configurer C::B pour faire du 64bit.Citation:
Envoyé par Arzar
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.
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++.Citation:
Envoyé par Emmanuel_exeter
et le tableau c'est obligatoire?
Parce que bon une zone contigue de memoire de 2Go...:mrgreen:
pourquoi ne pas stocker des tableaux de tableaux...c'est deja un peu moins contraignant...
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.Citation:
Envoyé par Emmanuel_exeter
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.
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.Citation:
a tu besoin de 2 Go de données tout le temps ? Surement pas non plus
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)Citation:
Envoyé par Emmanuel Deloget
Citation:
Envoyé par msdn
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.Citation:
Envoyé par Emmanuel Deloget
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.