У современных процессоров есть инструкции по сжатию

Question

Мне было интересно это некоторое время, так как сжатие используется практически во всем.

• Есть ли в кремнии основные инструкции по поддержке сжатия на типичном современном чипе процессора?

• Если нет, то почему они не включены?

• Почему это отличается от шифрования, когда некоторые процессоры имеют аппаратную поддержку таких алгоритмов, как AES?

Answer 1

У них нет общего сжатия инструкций.

AES работает с очень маленькими блоками данных, он принимает два 128-битных входа, выполняет некоторые нетривиальные вычисления на них, выдает один 128-битный выход. Специальная инструкция для ускорения вычислений очень помогает.

На современном оборудовании скорость сжатия без потерь часто ограничена задержкой ОЗУ. Выделенные инструкции не могут улучшить скорость, большие и более быстрые кэши могут, но современные процессоры уже имеют очень сложные многоуровневые кэши. Они уже достаточно хорошо работают на сжатие.

Если вам нужно сжать много гигабит / с, есть несколько автономных ускорителей , но они не являются частями процессоров, обычно подключаются автономные микросхемы на PCIx. И они очень нишевые продукты, потому что большинству пользователей просто не нужно так быстро сжимать столько данных.

Тем не менее, современные процессоры имеют много вещей для сжатия с потерями мультимедиа . Большинство из них имеют несколько расширений набора векторных инструкций (mmx, sse, avx), и некоторые из этих инструкций очень помогают, например, сценарий сжатия видео. Например, _mm_sad_pu8 (SSE), _mm_sad_epu8 (SSE2), _mm256_sad_epu8 (AVX2) очень полезны для оценки ошибок сжатия 8x8 блоков 8-битных пикселей. Версия AVX2 обрабатывает 4 строки блока всего за несколько циклов (5 циклов на Haswell, 1 на Skylake, 2 на Ryzen).

Наконец, многие процессоры имеют встроенные графические процессоры, которые включают специализированный кремний для аппаратного кодирования и декодирования видео, обычно h.264, более новые также h.265. Вот таблица для графических процессоров Intel , AMD имеет отдельные названия для кодировки и декодирования деталей. Этот кремний еще более энергоэффективен, чем инструкции SIMD в ядрах.

Answer 2

Многие приложения во всех видах доменов, безусловно, могут извлечь выгоду и используют алгоритмы сжатия данных. Поэтому было бы неплохо иметь аппаратную поддержку сжатия и / или распаковки, аналогично аппаратной поддержке других популярных функций, таких как шифрование / дешифрование, различные математические преобразования, подсчет битов и другие. Однако сжатие / декомпрессия обычно работают с большими объемами данных (много МБ или более), и разные алгоритмы демонстрируют разные схемы доступа к памяти, которые потенциально либо не совместимы с традиционными иерархиями памяти, либо даже оказывают на них негативное влияние. Кроме того, в результате работы с большими объемами данных и в случае их реализации непосредственно в главном конвейере ЦП, ЦП почти полностью был бы занят в течение длительных периодов времени, выполняя сжатие или распаковку. С другой стороны, рассмотрим шифрование, например, шифрование небольших объемов данных является типичным, и поэтому имеет смысл иметь аппаратную поддержку шифрования непосредственно в CPU.

Именно по этим причинам многие компании использовали аппаратные механизмы сжатия / распаковки (ускорители) в виде ASIC или FPGA в качестве сопроцессоров (встроенных, встроенных или внешних) или плат расширения (подключенных через PCIe / NVMe) в том числе:

• Адаптеры Intel QuickAssist .
• Microsoft Xpress .
• Карта сжатия / распаковки данных IBM PCIe .
• Аппаратные адаптеры сжатия Cisco .
• AHA378 .
• Многие академические Porposals .

Тем не менее, можно достичь очень высокой пропускной способности на одном современном ядре x86. В 2010 году корпорация Intel опубликовала документ , в котором обсуждаются результаты реализации алгоритма декомпрессии DEFLATE под названием igunzip. Они использовали одно физическое ядро ​​на базе Nehalem и экспериментировали с использованием одного логического ядра и двух логических ядер. Они достигают впечатляющей производительности декомпрессии более 2 Гбит / с. Ключевая инструкция x86: PCLMULQDQ . Однако современные аппаратные ускорители (такие как QuickAssist) могут работать примерно в 10 раз быстрее.

Intel имеет ряд связанных патентов:

• Устройство для аппаратной реализации сжатия данных без потерь .
• Аппаратные средства и способы декомпрессии данных .
• Системы, методы и устройства для декомпрессии с использованием аппаратного и программного обеспечения .
• Системы, способы и устройства для сжатия с использованием аппаратного и программного обеспечения .

Хотя трудно определить, какие продукты Intel использовали методы или конструкции, предложенные в этих патентах.

Answer 3

Есть такие присущие. Например, в наборе AVX512:

• _mm512_mask_compress_pd, _mm512_maskz_compress_pd do Непрерывное хранение активных элементов float32 (VCOMPRESSPD как инструкция AVX-512)
• _mm512_mask_compress_ps, _mm512_maskz_compress_ps so Непрерывное хранение активных элементов float64. (VCOMPRESSPS как инструкция AVX-512)
• _mm512_mask_compress_epi32, _mm512_maskz_compress_epi32, _mm512_mask_compressstoreu_epi32 do Непрерывное хранение активных элементов int32 (VPCOMPRESSD как инструкция AVX-512)
• _mm512_mask_compress_epi64, _mm512_maskz_compress_epi64 do Непрерывное хранение активных элементов int64 (VPCOMPRESSQ как инструкция AVX-512)

из Справочник Intel

Если процессоры стараются быть как можно более общими, они действительно добавляют новые инструкции, когда выигрыш и использование того стоят (определяется производителем).

Я считаю, что это хороший вопрос, и есть попытки реализовать это. В частности, FPGA могут быть запрограммированы для вычисления одного алгоритма за один цикл. Я подозреваю, что для процессоров размер этих инструкций может быть слишком большим (в пространстве) для ROI (возврат инвестиций) и является объектом особых команд высокого класса (как в AVX512), и не подходит для Графические процессоры.

Чтобы поддержать эту идею, существует документ от 2012 года Zip-io: Архитектура для сжатия больших данных для конкретного приложения , Jun et al (Intel, MIT) разрабатывает инфраструктуру сжатия FPGA.

Я позволю себе выбросить реферат:

Мы вступили в эпоху «больших данных»: масштабирование сетей и датчики привели к экспоненциальному увеличению количества данные. Сжатие является эффективным способом борьбы со многими из них. большие наборы данных и алгоритмы сжатия для конкретных приложений стали популярными в задачах с большими рабочими комплектами. К несчастью, эти алгоритмы сжатия часто вычислительно сложно и может привести к замедлению на уровне приложения при реализации в программном обеспечении. Чтобы решить эту проблему, мы исследуем ZIPIO, рамки для сжатия с ускорением FPGA. Используя это Система демонстрирует, что немодифицированное промышленное программное обеспечение рабочая нагрузка может быть ускорена в 3 раза при одновременном достижении более чем 1000-кратное сжатие в его наборе данных.