採用低bitsize積分類型，如`Int8`，他們是

什麼最近我瞭解到，每個計算週期進行機器的話，其在最現代的處理器和OS'es是32位或64位。那麼使用較小的比特尺寸值有什麼好處，如Int16,Int8,Word8？它們到底是什麼？僅僅是減少存儲量嗎？採用低bitsize積分類型，如`Int8`，他們是

我寫了一個複雜的計算程序，它由多個模塊組成，但僅通過一個返回Word64值的單個函數接口，因此整個程序的結果爲Word64值。我感興趣的是這個問題的答案，因爲這個節目，我發現自己使用了很多不同類型的Integral像Word16和Word8代表小實體的，看到他們往往得到了轉化與fromIntegral讓我想到裏面：是我做那裏有一個錯誤，那些我不知道的類型的確切好處是什麼被盲目吸引？使用其他整數類型並將它們用fromIntegral進行轉換或者我應該在各處使用Word64都有意義嗎？

來源

2012-01-22 Nikita Volkov

這些較小的類型給你，只有當你把它們存儲在拆箱陣列或類似的內存減少。在那裏，每個將採用類型後綴所指示的位數。

在一般的使用時，都採取完全一樣多的存儲作爲Int或Word，主要的區別是，值自動縮小到使用固定寬度的類型時的適當位的大小，和有（仍然）更優化（以重寫規則的形式爲主）爲Int和Word比Int8等，所以一些操作會使用那些更慢。

關於問題是否使用Word64整個或使用更小的類型，即依賴。在64位系統中，具有的優化編譯時的Word和Word64性能應該大多是因爲真正重要的事情都應該是解壓和工作是在原機器上Word#做了同樣的。但Word可能還有一些規則還沒有Word64副本，所以也許還是有區別的。在32位系統上，Word64上的大部分操作都是通過C調用實現的，所以Word64上的操作比上的操作慢多了。

那麼根據什麼更重要的是，代碼或不同的系統性能簡單，無論是

使用Word64遍及：簡單的代碼，在64位系統
使用Word性能好，只要您的值保證適合32位，並在最新安全時刻轉換爲Word64：更復雜的代碼，但在32位系統上性能更佳。

來源

2012-01-22 19:45:57

謝謝丹尼爾！請考慮我留給ehird回答的評論。由於通常你的答案是相似的，它也解決你的問題。 –

已更新的答案。根據你的情況和目標，我可能會不同意ehird。 –

在GHC，固定大小的整型都佔用一個完整的機器字，所以沒有節省空間可拿。在大多數情況下，使用機器字大小的類型（即Int和Word）可能會比固定大小的類型更快，但使用固定大小的整數類型將比執行明確的迴繞更快。

您應該爲您使用的值範圍選擇適當的類型。 maxBound :: Word8是255，255 + 1 :: Word8是0 - 如果你正在處理八位字節，那正是你想要的。（例如，ByteString s被定義爲存儲Word8 s）。

如果你只是有一些不需要特定位數的整數，並且你所做的計算不會溢出，只是使用Int或Word（或甚至Integer）。固定大小的類型比常規的整型不常見，因爲在大多數情況下，您不需要特定的大小。

所以，不要用它們來表現;如果你正在尋找他們特定的語義，請使用它們：具有定義的溢出行爲的固定大小的整型類型。

來源

2012-01-22 19:40:40 ehird

一如既往，你和丹尼爾一起拯救！）好吧，所以通常'Int'和'Word'比那些小類型更好 - 我明白了。但是我指出的第二個問題呢？如果我知道最終我仍然必須將這些值上採樣到「Word64」，那麼執行「Word」中的所有內部操作仍然會更有效嗎？在這種情況下，從一開始就到處使用「Word64」，從而通過消除'fromIntegral'轉換來節省一些週期？ –

如果你打算產生一個'Word64'的結果，我也會使用'Word64'進行中間計算。在64位機器上，它將是一個機器字，所以不應該有任何性能問題，'fromIntegral'將在運行時成爲NOP。 – ehird

節省空間嗎？我認爲，與bangpatterns他們會節省數據構造函數的空間。 – user239558

採用低bitsize積分類型，如`Int8`，他們是

回答

相關問題