Discussion :

[oodini]

Tu n'aurais pas bossé pour Amesys, qui a fourni des systèmes d'écoute à Kadhafi, par hasard ?

[Emmanuel Deloget]

Tu n'aurais pas bossé pour Amesys, qui a fourni des systèmes d'écoute à Kadhafi, par hasard ?

Je peux me tromper, mais les personnes ayant bosser sur ce projet à Amesys ne vont pas passer par ici pour le claironner - principalement parce que c'était un projet placé sous le sceau du secret. Je doute qu'ils aient le droit d'en parler en public. Peu de personnes savait ce qui se tramait dans cette équipe, et quelle était la portée fonctionnelle et (surtout?) commerciale du projet (et certainement pas les consultants "de base").

Sinon, pour rebondir sur les remarques qui m'on été faites plus haut, principalement sur les système nécessitant de gros volumes de données.

En premier lieu, ces systèmes fonctionnent de moins en moins souvent sous Windows. L'aspect temps réel est souvent primordial - principalement parce que les données arrivent à un rythme soutenu, et que le plus important est surtout, surtout, de ne rien perdre - et les latences sont incontrôlables sous Windows (même sur Embedded, malgré les fonctions un peu plus RT qu'un Windows normal).

Mais bien souvent, les interfaces de traitement offline de ces données se fait avec des logiciels sous Windows. C'est là que l'algorithmique aide.

Je prends un exemple simple : imaginez, il y a 20 ans, un capteur prenant une mesure par (je sais pas, au hasard) courant de foucault, tous les millimètres, sur toute une série de tubes (disons entre 5000 et 10000) pouvant faire jusqu'à 50 mètre chacun, afin (toujours au hasard) de vérifier si ces tubes n'ont pas d'anomalie. C'est un cas bien évidemment pris totalement au hasard.

Chaque mesure est stockée dans un tableau de float, et va demander par exemple une centaine de bytes. Avec une mesure par millimètre, chaque tuyau nécessite un volume de stockage conséquent - tout en restant relativement décent. On tourne aux alentour de 5 MB par tuyaux, par 5000 tuyaux - on est à 25 Go.

Ces données sont ensuite traitées par des humains, grâce à un logiciel spécifique (incapable de prendre une décision, mais capable d'afficher des courbes précises, basées sur des calculs complexes). Pour faire ces traitements, il faut encore charger les données correspondant à un tuyau dans le Programme. 5Mo. Impossible de charger ça il y a 20 ans (à cet époque, un ordinateur avait royalement 1Mo de RAM).

Que faire, donc ? Et bien on applique des algorithmes qui nous permettent de découper les données, voire de diminuer le volume de données lorsque c'est possible - en fonction de ce qu'on souhaite faire. Si, par exemple, je souhaite afficher une courbe sur l'écran qui montre la totalité du tube, je n'ai certainement pas l'utilité des 50,000 points acquis - un millier me suffira (enfin, à l'époque : 640 maximum). Du coup, je peux prévoir un traitement qui me donnera une courbe de 640 points, une autre de 1280 points - pour le cas où je zoom x2, ... jusqu'à avoir une courbe de 50,000 points dans le cas ou j'utilise le zoom maxi - auquel cas, un algo spécificque de mapping des données en mémoire me permettra d'accéder uniquement au 640 aux points que je désire afficher. Au final, en RAM, je ne vais avoir qu'un nombre limités de points - si je conserve 2 niveaux de zoom sur deux segments successifs, j'ai besoin de 375 Ko en RAM (a peu près).

Le problème de l'OP est nécessairement différent, mais dans l'idée, le type de solution est similaire. Si les données arrivent en masse, alors il faut les stocker - et ne garder en RAM que celles qui sont importantes pour un affichage. Si les données sont sur le disque et qu'il faut les traiter, alors il faut mettre au points les algorithmes pour ne garder en RAM que ce qui est nécessaire à l'affichage. Si la taille de ces données est minime par rapport à la RAM disponible, on peut en conserver plus - notamment si l'affichage est contrôlé par l'utilisateur et qu'on veut lui offrir des bon temps de réponse. Le logiciel peut aussi observer les patterns de travail de l'utilisateur, de manière à ne garder en RAM que ce qu'il prévoie d'utiliser (avec une marge d'erreur relativement faible). Par exemple, si on détecte que l'utilisateur passe à l'écran B 70% du cas où il est sur l'écran A, on va garder en RAM les données permettant d'afficher l'écran B rapidement. Si, de temps en temps, il passe directement à l'écran C, l'affichage prendra plus de temps - mais étant donné qu'il y va plus rarement, il saura pardonner le logiciel.

Je ne connais pas de problème qui ne peut pas s’accommoder de contraintes spécifiques en stockage volatile ou non (dès lors que ces contraintes ne sont pas trop fortes). Il est évident que jouer en temps réel une vidéo HD sur une machine avec 16K de RAM sans accélérateur graphique posera ce qu'on appellera, amateurs que nous sommes d'euphémismes (ou tout simplement consultant face à un client un peu borné), un problème important. Mais si on reste dans les limites du raisonnable, alors notre seul problème ne peut être que lié à un manque d'imagination.

Je répondrais donc à l'OP : il y a 20 ans, on traitait déjà des volumes de données considérables sur PC, et les PC étaient beaucoup plus limités qu'ils ne le sont aujourd'hui.

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

Il y a 99% pour cent de chance que ça soit faux. Surtout si, comme tu le dis, ton programme est monothread. Avec besoin de 2Go tout le temps signifie que tu passes ton temps à traiter ces 2Go de données. Hors n'importe quel programme monothreadé se comporte toujours comme s'il était une personne située dans château. A moins de courir tout le temps d'une pièce à l'autre (le 1%, qui peut peut-être se justifier), dans l'immense majorité des cas, il reste dans une pièce (salon, chambre, ...) pendant un moment, puis va dans une autre pièce, et ainsi de suite. Il y a même certaines pièces dans lesquelles il ne va que rarement (la salle de bain), voire très rarement (le grenier), ou de manière très régulière et très prévisible (les toilettes), etc. Si tu identifies ces pièces, ça te donnera peut-être une piste pour manager de manière plus fiable ta mémoire.

Parce que aujourd'hui, tu es bloqué avec tes 2Go. Mais comprends bien que la technologie ne va pas évoluer aussi vite que tes besoins en RAM. Pour que tu sois vraiment tranquille, il faudrait que tu consomme 10, voire 100 fois moins que ce que tu as sur la machine - de cette manière, tu auras le temps de voir venir.

Il faut aussi savoir que ton OS, plus sage que toi, va de toute façon mettre une partie de cette mémoire en cache sur le disque (swap). C'est illusoire de croire que parce qu'un PC a 12 Go de RAM, un bloc de 2 Go alloué va pour toujours rester en RAM. Les OS ne fonctionnent pas comme ça. Il va choisir ce qu'il veut mettre en cache en fonction de ce que le processeur lui dit sur les pattern d'accès aux différentes zones mémoire - ces patterns sont peut-être différents de tes besoins. Du coup, son traitement risque fort d'être suboptimal par rapport à ce que tu pourrais écrire toi-même en connaissant le pattern d'utilisation de ces données - et les raisons derrière ces pattern d'utilisation.

Maintenant, si comme tu le dis

Je ne programme pas pour suivre des principes mais pour obtenir des résultats

Je ne vais pas te forcer à me lire.

[Emmanuel_exeter]

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)

Je compile en 64 bits et çà passe sans problème en déclarant avec des news donc sur le tas !!

J ai testé par curiosité et au cas où j en aurai besoin et ça donne quand ça bloque et c est pour 16000*500000 octets ce qui est appréciable mais loin de 8TB mais plus que ma ram.

Si je peux déclarer les données mais que le programmes se mets a utiliser le swap mon algo mettra des siècles (enfin entre trop longtemps et des millénaires) pour trouver une solution donc ça servira à rien.

Merci pour ceux qui ont aidé et pour les autres ça serait bien de ne pas polluer la discussion quand on as pas la réponse à la question !!

[jblecanard]

Au cas où tu ne le saurais pas, la programmation et le développement sont un métier complexe, pas une tâche ingrate de technicien que n'importe quel chercheur peut faire à la va-vite.

Des réponses évoluées ont été données à ton problème, mais tu restes planté à une courte vue dans laquelle tu veux une solution toute cuite et limitée aux contraintes que tu t'es fixées par manque de connaissance.

Prend du temps et fais les choses bien, ouvre ton esprit et prend des décisions techniques en connaissance de cause, sinon tu vas te retrouver avec une solution technique pourrie dont tu ne pourras rien tirer si ton volume de données double ou quadruple (et ne dis pas "ça n'arrivera pas", tu n'en sais rien!) parce tout va swaper à mort.

Bon courage cependant.

[Emmanuel Deloget]

Je compile en 64 bits et çà passe sans problème en déclarant avec des news donc sur le tas !!

J ai testé par curiosité et au cas où j en aurai besoin et ça donne quand ça bloque et c est pour 16000*500000 octets ce qui est appréciable mais loin de 8TB mais plus que ma ram.

Si je peux déclarer les données mais que le programmes se mets a utiliser le swap mon algo mettra des siècles (enfin entre trop longtemps et des millénaires) pour trouver une solution donc ça servira à rien.

Merci pour ceux qui ont aidé et pour les autres ça serait bien de ne pas polluer la discussion quand on as pas la réponse à la question !!

La réponse à la question est : ça fait depuis le début de l'informatique qu'on manipule des gros volumes de données, et tu serais le premier pour qui l'intégralité des données manipulées doivent tout le temps rester en mémoire ?

De la part de celui qui pollue : trouve la solution tout seul. J'ai perdu un temps infini à essayer de t'expliquer quelque chose, ce n'est pas parce que tu ne comprends pas que ce que j'ai dit est faux.

Sur ce, je te laisse mariner dans ton ignorance voulue. Débrouille toi.

[Hibernatus34]

Bonjour,

Ce sujet est trop long à lire.
Mais est-ce que quelqu'un a fini par expliquer que :
- Les variables globales ne sont pas sur le tas (ni sur la pile), ce sont des statiques, donc elles élargissent juste votre exe en mémoire. (les sections data)
- Il ne faut pas utiliser des tableaux C, il existe les vector etc. (on est bien sur un forum C++ ?)
- Un programme qui a besoin de +2 Go pour tourner est souvent un mauvais programme.
?

PS. Je réponds surtout à ceci, qui est faux et n'a pas reçu de réponse :

C'est tout à fait normal, les variables globales sont allouée sur le tas alors que les variables locales sont allouée sur la pile.

A confirmer. tu ne peux pas allouer 2go comme ça. tu exploses la pile.

Et la réponse :

C'est bien de lire les messages précédents avant de poster.

Là il alloue sur le tas puisqu'il utilise des variables globales.

Voilà, donc c'est ni le tas, ni la pile. C'est directement un espace alloué à votre exe dès son chargement. Pour en savoir plus, vous pouvez regarder les formats d'exe PE ou ELF, mais ça doit être expliqué aussi dans certains cours de C++.

Pour le reste, j'ai un peu mieux lu et je vois qu'on a déjà proposé le vector et revoir l'algo, alors au temps pour moi !

[davcha]

Le gars, c'est un chercheur. Faire des programmes super efficaces en mémoire, c'est pas son sujet de recherche, ici, clairement. C'est pas son boulot donc. Il peut se contenter d'une solution qui marche suffisamment bien, même si techniquement il y a mieux.

+1 pour hibernatus sinon

[screetch]

le mec se jette la tete la premiere sur une limite logicielle, et au lieu de penser "et si je faisais un truc un peu plus optimise qui marche?" il vient ici demander comment il peut contourner la limite logicielle avec des commandes de gourous.

meme si c'est pas son sujet de recherche, il y a un moment ou il faut se remettre en question.

des gros +1 a emmanuel deloget pour avoir expliquer la plupart des reponses correctes quand meme.