Использование целочисленных типов с низким битом, таких как `Int8` и для чего они нужны - PullRequest
9 голосов
/ 22 января 2012

Недавно я узнал, что каждый цикл вычислений выполняется для машинных слов, которые на большинстве современных процессоров и ОС являются 32-битными или 64-битными.Так каковы преимущества использования меньших значений размера битов, таких как Int16, Int8, Word8?Для чего они нужны?Это только уменьшение памяти?

Я пишу сложную программу вычислений, которая состоит из нескольких модулей, но связана только с одной функцией, которая возвращает значение Word64, поэтому вся программа приводит к значению Word64.Я заинтересован в ответе на этот вопрос, потому что внутри этой программы я обнаружил, что использую множество различных типов Integral, таких как Word16 и Word8, для представления небольших объектов, и вижу, что они довольно часто конвертируются с помощью fromIntegral заставил меня задуматься: не ошибся ли я, и какая была польза от тех типов, о которых я не знал, которые слепо привлекали меня?Имеет ли смысл вообще использовать другие целочисленные типы и вечно конвертировать их с fromIntegral, или, может быть, я должен был просто использовать Word64 везде?

Ответы [ 2 ]

8 голосов
/ 22 января 2012

В GHC целочисленные типы фиксированного размера занимают полное машинное слово, поэтому экономии места не будет.Использование типов машинного размера (то есть Int и Word), вероятно, будет быстрее, чем типы фиксированного размера, в большинстве случаев, но использование целочисленного типа фиксированного размера будет быстрее, чем выполнение явного переноса.

Вы должны выбрать соответствующий тип для диапазона значений, которые вы используете.maxBound :: Word8 - это 255, 255 + 1 :: Word8 - это 0, и если вы имеете дело с октетами, это именно то, что вам нужно.(Например, ByteString s определены как сохраняющие Word8 s.)

Если у вас просто есть несколько целых чисел, которым не нужно определенное количество битов, и вычисления, которые вы делаете, не выполняются 'Переполнение не происходит, просто используйте Int или Word (или даже Integer).Типы фиксированного размера встречаются реже, чем обычные целочисленные типы, поскольку в большинстве случаев вам не нужен конкретный размер.

Поэтому не используйте их для производительности;используйте их, если вы ищете их специфическую семантику: целочисленные типы фиксированного размера с определенным поведением переполнения.

6 голосов
/ 22 января 2012

Эти меньшие типы дают вам уменьшение памяти только тогда, когда вы храните их в распакованных массивах или аналогичных. Там каждый будет принимать столько битов, сколько указано суффиксом типа.

В общем случае все они занимают столько же памяти, сколько Int или Word, основное отличие состоит в том, что значения автоматически сужаются до соответствующего размера в битах при использовании типов с фиксированной шириной, и есть ( все же) больше оптимизаций (в основном в форме правил перезаписи) для Int и Word, чем для Int8 и т. д., поэтому некоторые операции будут медленнее при их использовании.

Относительно вопроса, следует ли использовать Word64 повсюду или использовать меньшие типы, это зависит. В 64-битной системе при компиляции с оптимизацией производительность Word и Word64 в основном должна быть одинаковой, поскольку там, где это важно, оба должны быть распакованы, а работа выполняется на необработанной машине Word#. Но, вероятно, еще есть несколько правил для Word, которые еще не имеют Word64, так что, возможно, в конце концов есть разница. В 32-разрядной системе большинство операций на Word64 осуществляются с помощью вызовов C, поэтому операции на Word64 на намного медленнее, чем операции на Word.

Таким образом, в зависимости от того, что важнее, простота кода или производительность в разных системах, либо

  1. использование Word64 во всем: простой код, хорошая производительность на 64-битных системах
  2. используйте Word, если ваши значения гарантированно поместятся в 32-битные и преобразуются в Word64 в самый последний безопасный момент: более сложный код, но лучшая производительность в 32-битных системах.
...