Bonjour,
J'aimerais savoir si vous savez si il existe une fonction d'allocation qui soit optimisée au niveau des bits. Je m'explique : habituellement, quand je déclare int i = 5 par exemple, je n'utilise que 3 bits sur les 32 (ou 64 ). Existe t'il une fonction d'allocation qui me permettrai de récuperer les 29 bits restant pour d'autres allocations ? Ayant déja beaucoup cherché sans succes je pense ecrire cette fonction moi meme, mais cela me semble assez compliqué , car il me faudrait utiliser des masques pour récuperer les differentes valeur stockées dans un mot mémoire. Qu'en pensez vous ?
Merci

Pour 40€ tu peux avoir 2G de RAM. Je suis près à t'envoyer immédiatement un chèque de 1 centime pour compenser la perte de tous ces bits. (Je te laisse faire le calcul sur combien de bits pour peut acheter avec 1 centime).

C'est pour une tres grosse application et le gain de ces bits ne serait pas negligeable

Si t'as envie de perdre ton temps, tu peux utiliser char qui a une taille minimale de 8 bits (et non 32). Si t'as encore plus envie de perdre ton temps, tu peux t'amuser à faire du bit packing à coup de masques et de shifts. Dans tous les cas, je doute fort que tu puisses avoir des int bruts non alignés.
 
Et il est très peu probable que tes pressions mémoire soient sur du stockage d'entiers...

 
J'aimerais bien voir ton argumentation. On a le même "problème" (appli 32 bits qui sur certains traitements dépasse allègrement les 4Go fatidiques), et le temps de développement et de tests de ce que tu veux faire, pour un gain qui reste à démontrer, me semblent représenter un coût bien supérieur (et de loin) à une stratégie de découpage en lots (grid computing par exemple).

C'est pour un simulateur de reseau de neurones distribué. Le but est de faire tourner un maximum de neurones sur chaque machine.
Donc selon vous c'est quelque chose de difficilement réalisable et inutile ? Ou alors y en a t'il qui pensent que c'est faisable ? La solution que je vois consisterais stocker un numero de masque ( de 1 a 36 pour un octet par exemple ) a utiliser pour chaque allocation, mais ca me semble un peu lourd. Avez-vous des idées a me proposer ?
Merci de vos avis

Bien sûr: ne pas faire un truc pareil.

Je pense qu'en premier lieu, un audit mémoire serait plus profitable. S'il n'y en a jamais eu et que le code est conséquent, alors je suis prêt à parier qu'il y a des fuites mémoires, ou des libérations jamais effectuées, ou des algorithmes inutilement gourmands. Les corriger peut grandement améliorer les choses à moindre frais (en plus de stabiliser le produit).

Ensuite, si tu es déjà en distribué et que vous avez déjà tiré sur la corde, alors il ne reste que le découpage en taches plus petites pour les lots les plus lourds. En plus avec un bon ordonnanceur de tâches, c'est une stratégie plus payante, en tout cas ça l'a été chez nous (on fait du calcul distribué).

Mais dans tous les cas, à moins d'une étude sérieuse (et que forcément vous ètes les seuls à pouvoir faire sur le produit) des gains sur ce que tu proposes est à effectuer avant de se lancer dans la bataille. Mais honnêtement, je partage l'avis de taz et de masklinn : le gain reste largement à démontrer.

et tu ne peux pas utiliser des bitfields aux endroits où tu gaspillerais beaucoup de mémoire de cette manière, plutôt que faire un allocateur ?
 
edit : typo

Non. La résolution est le char qui fait 8 bit au minimum (parfois plus sur certaines architectures comme les DSP).

Si c'est pour une variable toute seule, ça n'a bien sur aucun intérêt. Le problème se pose quand on a plusieurs variables (une structure, par exemple) et qu'on cherche à réduire l'empreinte mémoire d'un tableau de structure.

Par exemple :

donne

Dans ce cas particulier, on peut analyser quelle sont les plages de valeurs requises pour chaque champ et optimiser la mémoire en utilisant des champs de bits dont la largeur est optimisée à l'usage qui en est fait, ce qui donne :

http://www.bien-programmer.fr/notes.htm#bitfield

On voit que la taille de la structure est passée de 24 à 8 char ...

Merci de vos avis. Je pense que je vais réfléchir encore un peu avant de me lancer, bien sur je comprend que ce soit a faire en dernier lieu, mais je vais quand meme le faire au moins pour voir le résultat.

Mais comme rien n'est gratuit, ce qu'on gagne en place, on va le perdre en efficacité d'accès aux valeurs, dès qu'on y accède pas en bloc, non?
A+,

Oui. Il faut choisir entre optimisation en taille et en vitesse. C'est pas un scoop !

C'est juste que tes tests donnaient l'impression (execution time) qu'on y gagnait aussi en temps d'execution, ce qui ne doit être le cas que de certains usages, et que je n'aurais pas voulu que l'auteur du topic le pense. Ici, c'est peut être l'allocation plus importante qui consomme un peu plus de temps dans le premier cas.
A+,

Ca, c'est juste une indication que donne systématiquement mon environnement de développement (Code::Blocks). J'ai juste fait un copié/collé de la sortie...
 
D'ailleurs, ma remarque portait sur la taille et non sur le temps...