Package: ghc-bitvec (1.1.6.0-1.3)

Un newtype sur 'Bool' avec une meilleure instance de 'Vector' : 8x moins de mémoire, jusqu'à 3500x plus rapide. Le paquet <https://hackage.haskell.org/package/vector vector> représente des tableaux unboxed de 'Bool's en consommant 1 octet (8 bits) par booléen. Cette bibliothèque fournit un wrapper newtype 'Bit' et une instance personnalisée d'un 'Vector' unboxed, qui empaquette densément les bits, obtenant une __empreinte mémoire 8x plus petite.__ Les performances restent globalement les mêmes ; la dégradation la plus significative survient pour les écritures aléatoires (jusqu'à 10 % plus lent). En revanche, pour certaines opérations bit en masse, 'Vector' 'Bit' est jusqu'à 3500x plus rapide que 'Vector' 'Bool'. === Sécurité des threads * "Data.Bit" est plus rapide, mais les écritures et les flips ne sont pas thread-safe. C'est parce que les mises à jour naïves ne sont pas atomiques : elles lisent le mot entier depuis la mémoire, puis modifient un bit, puis réécrivent le mot entier. Modifier concurrentiellement des slices non intersectantes du même tableau sous-jacent peut aussi conduire à des résultats inattendus, car elles peuvent partager un mot en mémoire. * "Data.Bit.ThreadSafe" est plus lent (généralement 10-20 %), mais les écritures et les flips sont thread-safe. De plus, modifier concurrentiellement des slices non intersectantes du même tableau sous-jacent fonctionne comme attendu. Cependant, les opérations qui affectent plusieurs éléments ne sont pas garanties comme étant atomiques. === Paquets similaires * <https://hackage.haskell.org/package/bv bv> et <https://hackage.haskell.org/package/bv-little bv-little> n'offrent pas de vecteurs mutables. * <https://hackage.haskell.org/package/array array> est efficace en mémoire pour 'Bool', mais manque d'une interface 'Vector' pratique et n'est pas thread-safe.