我應該使用最小的類型嗎？

Question

很久以前，我記得你應該總是使用盡可能小的類型來存儲你的數據，但是我幾乎讀到的每一段代碼都不會這樣做。他們經常在整個地方使用32位整數。

我聽說過一個32位值的取值與8位值一樣快的原因，但處理器有一些方法可以一次取出幾個較小的值..對嗎？

所以如果我使用4個字節而不是4個整數，編譯器是不是應該優化這個，所以4個字節被提取/存儲在一個32位寄存器中？

或者所有這些都只是過早的優化，潛在的性能增益可以忽略不計？

Answer 1

確實過早優化！但是，一旦你正在優化，它也取決於你的架構。例如，在ARM上，內存訪問必須是32位對齊的（一些指令可以做到這一點，但他們只是做了32位訪問，然後在後臺屏蔽/移位）。如果你使用一個字節，編譯器通常會給每個'字節'四個RAM的實際字節，所以它可以更快地訪問（更不用說CPU會怪你試圖訪問未對齊的字節，而沒有特殊的代碼來處理它們）。

有一種說法，使用「廉政」的一切，因爲它是CPU的首選大小，但基本上，只要使用你需要的大小的類型，並讓有關的優化編譯器的擔心：d

Answer 2

這取決於。如果您使用的是帶有小緩存的小型處理器，那麼選擇最小的數據大小可能有意義。如果您有大量數據，例如數百萬個樣本，每個樣本需要8位精度，那麼使用最小的數據大小是有道理的。在其他大多數情況下，請將其留給編譯器。

Answer 3

在32位CPU中，將四個8位字節打包爲32位字可以改善內存訪問時間，因爲可以一次提取四個字節。然而，現在爲了操縱單個字節，CPU必須執行額外的移位掩模等。因此，無論如何將4個字節打包成一個字，或者將每個字節解壓縮（對於每個8位字節使用32位）具有優點並且利弊。

假設我們正在談論C或C++，優化編譯器通常會做出正確的決定，你，但你可以，如果你都要通過做自己包裝成結構明確地控制這種行爲，等等

但是，還有其他更好的理由使用與數據域相匹配的類型：清晰性，可維護性等。我認爲這些優勢在99％的時間裏都佔據着優勢。