atomic.load() 是否比正常調用更快

Question

最近我在 c++ 中使用了很多原子序數，因為我使用線程太多並且線程安全對我來說很重要

好吧，我遇到了 printf() function 的問題，這是一個例子

atomic_uint64_t count = {0}

printf("%lu",count);

// It gives error couple of errors like  atomic(cost atomic&) = delete; and use of deleted function atomic so i had to write it like this to make it work

printf("%lu",count.load());

// Or

printf("%lu",(uint64_t)count);

好吧無論如何我不知道哪個對性能更好我真的很關心速度

所以我開始考慮哪個更好地檢索值並在 if 條件或其他任何地方使用它

喜歡

if(count.load() < 8 ){

// Do smth
}

或者

if(count < 8){
// Do smth
}

哪個對速度和性能更好，謝謝。

Answer 1

它們的含義完全相同（除非您傳遞非默認的 memory 訂單，例如count.load(std::memory_order_acquire) ）。

我希望為所有 ISA 的所有編譯器生成的程序集沒有區別，當然啟用了優化。 我在https://godbolt.org/上查看的代碼中沒有 GCC/clang/MSVC/ICC。 無論其內聯到的周圍代碼如何，這都是正確的。

如果有任何差異，並且速度較慢或需要更多代碼大小，請在您使用的任何編譯器中將其報告為錯過優化的編譯器錯誤。 （除非您禁用了優化，否則對包裝函數的額外調用是可能的。）

---

至於錯誤，那是因為您在尚未暗示類型的上下文中對其進行評估：作為可變參數 function ( printf ) 的操作數。

如果有足夠的上下文暗示您想要來自atomic<T>的基礎 T 值（這就是atomic_uint64_t ），則調用operator T()重載，它被記錄為等效於.load() 。 分配和.store()的交易相同。

沒有任何其他功能可以讓您僅訪問原子 64 位 integer 的低 32 位（不幸的是）； 即使在 32 位機器上，當前的編譯器實際上也會 go 麻煩進行 64 位原子加載（這在某些 32 位機器上是有效的，而不是在其他機器上），然后如果你轉換值，則丟棄高 32到更窄的類型。 （這是一個錯過的優化，但編譯器目前確實沒有優化原子。）

因此.load沒有任何歧義可以解決，或者演員可以選擇不同的負載。

---

.load()和.store()存在的一個原因是它們采用std::memory_order參數，該參數默認為seq_cst但如果您只需要原子性但只需要線程之間的 acq/rel 同步，則可能會更弱。 或者根本沒有relaxed的，只是原子性。

另一個原因是讓您編寫foo.load()來提醒讀者您的代碼這是一個原子變量，而不僅僅是一個簡單的原始類型。 出於這種風格的原因，我更喜歡count.load() 。 據推測，如果您將其類型從uint64_t更改，您會想要更改打印方式，而不是將其轉換為uint64_t 。 如果您更改其類型，使用.load()將使編譯器警告您格式字符串不匹配。