Vous pouvez donner mon code PackedArray un essai avec un bitsPerItem
de 1
.
Il implémente un conteneur d'accès aléatoire dans lequel les éléments sont compressés au niveau du bit. En d'autres termes, il agit comme si vous étiez en mesure de manipuler, par exemple, uint9_t
ou uint17_t
tableau:
PackedArray principle:
. compact storage of <= 32 bits items
. items are tightly packed into a buffer of uint32_t integers
PackedArray requirements:
. you must know in advance how many bits are needed to hold a single item
. you must know in advance how many items you want to store
. when packing, behavior is undefined if items have more than bitsPerItem bits
PackedArray general in memory representation:
|-------------------------------------------------- - - -
| b0 | b1 | b2 |
|-------------------------------------------------- - - -
| i0 | i1 | i2 | i3 | i4 | i5 | i6 | i7 | i8 | i9 |
|-------------------------------------------------- - - -
. items are tightly packed together
. several items end up inside the same buffer cell, e.g. i0, i1, i2
. some items span two buffer cells, e.g. i3, i6
efficace en termes de mémoire ou CPU? – robert
@robert: Je suppose qu'en termes de mémoire en premier lieu. C'est à cause du peu de frais de traitement possibles, mais des frais généraux sérieux en cas de manque de mémoire cache. – ruslik
@robert: il y a une différence? S'il y a un grand nombre de bits, les performances seront limitées par les échecs d'antémémoire, donc l'emballage des bits aussi serré que possible donnera les meilleures performances. Seulement s'il y a très peu de bits, il peut être plus efficace d'utiliser un octet entier (ou plus) par bit. –