使用位集進行位圖存儲有什么好處？

Question

我目前正在評估是否應該使用單個大型bitset或許多64位無符號long（uint_64）來存儲大量位圖信息。 在這種情況下，位圖表示幾GB內存頁面的當前狀態（臟/非臟），並且有數千個條目。

我正在執行的工作要求我能夠查詢和更新臟頁，包括在兩個臟頁位圖之間執行OR操作。

為了清楚起見，我將執行以下操作：

• 從文件導入位圖，並使用現有位圖執行按位OR運算
• 計算漢明重量（計算設置為1的位數，表示臟頁數）
• 重置/清除一位，將其標記為已更新/清除
• 檢查位的當前狀態，以確定它是否干凈

看起來很容易在C ++ bitset上執行按位操作，並且很容易計算漢明重量。 但是，我想這里沒有任何魔力 - CPU只能在可以存儲在寄存器中的字節數上執行按位操作 - 因此bitset使用的例程可能與我自己實現的相同。 漢明重量也可能是這樣。

此外，從文件中位集導入位圖數據看起來很難看-我需要執行bitshifts多次，如圖所示這里 。 我想，考慮到我將使用的位集的大小，這會對性能產生負面影響。 當然，我想我可以只使用許多小的位集，但這可能沒有優勢（其他可能也很容易實現）。

一如既往，任何建議都是適當的。 謝謝！

Answer 1

聽起來你有一個非常具體的一次性應用程序。 就我個人而言，我從來沒有使用過bitset，但從我可以說它的優點是可以訪問就好像它是一個bool數組，以及能夠像向量一樣動態增長。

從我可以收集到的，你真的不需要其中任何一個。 如果是這種情況，如果填充bitset是一個戲劇，我會傾向於自己做，因為分配一大堆整數並對它們進行位操作真的很簡單。

鑒於具有非常具體的要求，您可能會從自己的優化中受益。 訪問原始位數據對此至關重要（例如，使用預先計算的單個字節的漢明權重表，如果有備用內存，則使用兩個字節）。

我一般不主張重新發明輪子...但如果你有特殊的優化要求，最好定制你的解決方案。 在這種情況下，您實現的功能非常簡單。

Answer 2

我想如果我是你，我可能會省去任何DIY的麻煩並使用boost :: dynamic_bitset 。 他們已經在功能方面涵蓋了所有基礎，包括流操作員重載，您可以將其用於文件IO（或者只是以unsigned int的形式讀取數據並使用他們的轉換，請參閱他們的示例）和count方法漢明重量。 Boost受到Sutter和Alexandrescu的高度重視，他們在頭文件中做了所有事情 - 沒有鏈接，只需#include適當的文件。 此外，不同於標准庫bitset ，你可以等到運行到指定位集的大小。

編輯：Boost似乎允許您需要的快速輸入讀數。 dynamic_bitset提供以下構造函數：

template <typename BlockInputIterator>
dynamic_bitset(BlockInputIterator first, BlockInputIterator last,
               const Allocator& alloc = Allocator());

底層存儲是Block s的std::vector （或幾乎與它相同的東西），例如uint64 。 因此，如果您將位圖作為uint64的std::vector讀入，則此構造函數會將它們直接寫入內存而不進行任何位移。

Answer 3

成千上萬的聲音聽起來並不多。 但也許你有數百萬。

我建議你編寫你的代碼 - 如果你有一個理想的實現通過抽象（開始使用任何實現更容易編碼，忽略任何性能和內存需求問題）然后嘗試幾個替代的特定實現來驗證（通過測量它們）表現最好。

您甚至沒有考慮過的一個解決方案是使用Judy數組（特別是Judy1數組）。