int32_t的延遲是否低於int8_t，int16_t和int64_t？

Question

（我指的是Intel CPU，主要是GCC，但可能是ICC或MSVC）

使用int8_t是真的， int16_t或int64_t與int32_t相比效率較低，因為生成了額外的指令來在CPU字大小和所選變量大小之間進行轉換？

如果有人有任何示例或最佳實踐，我會感興趣嗎？ 我有時使用較小的可變大小來減少緩存行負載，但是我說只消耗了50個字節的緩存行，其中一個變量是8位int，通過使用剩余的緩存行空間並將8位int提升為a，可以更快地處理32位int等？

Answer 1

您可以將更多uint8_t s填充到緩存行中，因此加載N uint8_t將比加載N uint32_t更快。

此外，如果您使用帶有SIMD指令的現代英特爾芯片，智能編譯器將對其進行矢量化。 同樣，在代碼中使用一個小變量將允許編譯器將更多通道填充到SIMD寄存器中。

我認為最好使用最小的尺寸，並將細節留給編譯器。 當涉及到這樣的東西時，編譯器可能比你（和我）更聰明。 對於許多操作（比如無符號加法），編譯器可以對uint8 ， uint16或uint32使用相同的代碼（並忽略高位），因此沒有速度差異。

最重要的是，高速緩存未命中比任何算術或邏輯操作都要昂貴，因此擔心緩存（以及數據大小）幾乎總是比簡單算術更好。

（過去很長一段時間，在Sun工作站上，使用double比float顯着快，因為硬件只支持double 。我認為現代x86不再是真的，因為SIMD硬件（SSE）等）直接支持單精度和雙精度）。

Answer 2

Mark Lakata在正確的方向上回答了問題。
我想補充一些觀點。

Agner文檔是了解和優化決策的絕佳資源。

指令表文檔具有最常見指令的延遲。 您可以看到其中一些在原生大小版本中表現更好。
例如，可以消除mov ， mul具有較少的延遲。
然而，我們在談論獲得1個時鍾 ，我們將不得不執行大量指令來補償緩存未命中。
如果這是整個故事，那將是不值得的。

解碼器帶來了真正的問題。
當您使用一些長度變化的前綴（並且您將使用非原生大小的單詞）時，解碼器需要額外的周期。

因此，操作數大小前綴會更改指令其余部分的長度。 預編碼器無法在單個時鍾周期內解決此問題。 從此錯誤中恢復需要6個時鍾周期。 因此，避免這種長度變化的前綴非常重要。

現在，不再是最近（但現在仍然存在）的微觀，懲罰是嚴厲的，特別是有一些類型的算術指令。
在后來的微觀領域，這已經得到了緩解，但仍然存在懲罰。

要考慮的另一個方面是使用非本機大小需要在指令前添加前綴 ，從而生成更大的代碼。 盡管英特爾CPU可以處理非本機字大小，但它最接近聲明“ 生成用於在CPU字大小和所選變量大小之間進行轉換的附加指令 ”。
對於其他特別是RISC，CPU，這通常不正確，可以生成更多指令。

因此，在充分利用數據緩存時， 您也會錯誤地使用指令緩存 。

在常見的x64 ABI上，堆棧必須在16字節邊界上對齊並且通常編譯器以本機字大小或接近的一個（例如64位系統上的DWORD）保存本地變量也是值得的。
只有在分配足夠數量的本地變量或者使用數組或壓縮結構時，才能從使用小變量大小中獲益。
如果聲明一個uint16_t var，它可能會占用單個uint64_t的相同堆棧空間，因此最好選擇最快的大小。

此外，當它來到數據緩存時，它是重要的位置 ，而不僅僅是數據大小。

那么該怎么辦？

幸運的是，您無需在擁有小數據或小代碼之間做出決定。

如果您有相當數量的數據，通常使用數組或指針以及使用中間變量來處理。 這一行代碼就是一個例子。

t = my_big_data[i];

我的方法是：

• 保持數據的外部表示，即my_big_data數組盡可能小。 例如，如果該陣列存儲溫度對每個元素使用編碼的uint8_t 。

• 保持數據的內部表示，即t變量，盡可能接近CPU字大小。 例如， t可以是uint32_t或uint64_t 。

這樣，您可以編程優化兩個緩存並使用本機字大小。
作為獎勵，您可以稍后決定切換到SIMD指令，而無需重新my_big_data內存布局。

---

真正的問題是程序員花費了太多時間來擔心在錯誤的地方和錯誤的時間提高效率; 過早優化是編程中所有邪惡（或至少大部分）的根源。
D. Knuth

在設計結構時，內存布局應該是問題驅動的。 例如，年齡值需要8位，城市距離以英里為單位需要16位。
在對算法進行編碼時，使用已知編譯器對該范圍具有的最快類型。 例如，整數比浮點數快， uint_fast8_t不比uint8_t慢。

那時，是時候通過改變算法（通過使用更快的類型，消除冗余操作等）來改善性能開始，然后如果需要數據結構（通過對齊，填充，打包等）。