通過將它們轉換為更大的 integer 數據類型來一次添加整個字節數組是否有效？

Question

如果我有兩個包含u8的 arrays ，我可以將它們轉換為更大的 integer 類型以減少我需要做的添加數量嗎？ 例如，如果兩個字節 arrays 每個包含 4 個字節，我可以將它們每個都變成一個u32 ，進行加法，然后將它們轉換回來嗎？

例如：

let a = u32::from_ne_bytes([1, 2, 3, 4]);
let b = u32::from_ne_bytes([5, 6, 7, 8]);

let c = a + b;
let c_bytes = u32::to_ne_bytes(c);

assert_eq!(c_bytes, [6, 8, 10, 12]);

此示例生成正確的 output。

1. 這是否總是導致正確的 output （假設沒有溢出）？
2. 這比單獨添加要快嗎？
3. 它適用於其他 integer 類型嗎？ 例如 u32 中的 2 個u16與u16 u32 u32

如果這存在並且很常見，它叫什么？

Answer 1

1. 這是否總是導致正確的 output （假設沒有溢出）？

是的。 如果每個總和小於 256，這將根據需要添加字節。 您在每種情況下都指定了“ne”，用於本地字節序。 無論本機字節順序如何，這都會起作用，因為操作是按字節計算的。

如果您編寫代碼來實際檢查總和是否都在范圍內，那么您幾乎肯定會撤消您獲得的任何額外加速（如果有的話）。

2. 這比單獨添加要快嗎？

也許。 唯一確定的方法是測試。

3. 它適用於其他 integer 類型嗎？ 例如 u32 中的 2 個u16與u16 u32 u32

可以，但是需要注意字節順序。

如果這存在並且很常見，它叫什么？

這並不常見，因為它通常是不必要的。 這種類型的優化使代碼更難閱讀，並引入了相當大的復雜性和錯誤機會。 Rust 編譯器和它們之間的 LLVM 能夠找到您永遠不會想到的極其復雜的優化，同時您的代碼保持可讀性和可維護性。

如果它有一個名字，它就是 SIMD，而且大多數現代處理器本身就支持它的一種形式（SSE、MMX、AVX）。 您可以使用內置函數手動執行此操作，例如core::arch::x86_64::_mm_add_epi8 ，但 LLVM 可能會自動執行此操作。 嘗試手動執行此操作可能會干擾 LLVM 否則會執行的優化，同時使您的代碼更容易出錯。

---

我無論如何都不是匯編代碼方面的專家，但我查看了為以下兩個函數生成的程序集：

#[no_mangle]
#[inline(never)]
pub fn f1(a1: u8, b1: u8, c1: u8, d1: u8, a2: u8, b2: u8, c2: u8, d2: u8) -> [u8; 4]{
    let a = u32::from_le_bytes([a1, b1, c1, d1]);
    let b = u32::from_le_bytes([a2, b2, c2, d2]);
    u32::to_le_bytes(a + b)
}

#[no_mangle]
#[inline(never)]
pub fn f2(a1: u8, b1: u8, c1: u8, d1: u8, a2: u8, b2: u8, c2: u8, d2: u8) -> [u8; 4]{
    [a1 + a2, b1 + b2, c1 + c2, d1 + d2]
}

f1的程序集：

movzx r10d, byte ptr [rsp + 8]
shl ecx, 24
movzx eax, dl
shl eax, 16
movzx edx, sil
shl edx, 8
movzx esi, dil
or esi, edx
or esi, eax
or esi, ecx
mov ecx, dword ptr [rsp + 16]
shl ecx, 24
shl r10d, 16
movzx edx, r9b
shl edx, 8
movzx eax, r8b
or eax, edx
or eax, r10d
or eax, ecx
add eax, esi
ret

對於f2 ：

add r8b, dil
add r9b, sil
add dl, byte ptr [rsp + 8]
add cl, byte ptr [rsp + 16]
movzx ecx, cl
shl ecx, 24
movzx edx, dl
shl edx, 16
movzx esi, r9b
shl esi, 8
movzx eax, r8b
or eax, esi
or eax, edx
or eax, ecx
ret

更少的指令並不一定會讓它更快，但這不是一個糟糕的指導方針。

---

在仔細測量和測試之后，將這種優化視為最后的手段。