Xxhash: Добавьте хеш Meow в тесты

Созданный на 21 окт. 2018  ·  8Комментарии  ·  Источник: Cyan4973/xxHash

Самый полезный комментарий

meow_hash полностью зависит от наличия инструкций AES с аппаратным ускорением.

Я подозреваю, что без этих инструкций он даже не скомпилируется, так как код довольно короткий, и я не вижу пути для резервного кода программного обеспечения. Кроме того, все инструкции AES, которые я мог прочитать, используют прямые встроенные функции Intel, поэтому они не переносятся по архитектуре, независимо от возможностей оборудования.

Это не обязательно «плохо»: в конце концов, они получают взамен большую скорость за длительный ввод.

Но главное в том, что при использовании такого специализированного набора аппаратных инструкций переносимость исключена из списка возможностей.

В качестве побочного эффекта он даже не будет работать на платформе, используемой для тестов xxHash.

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

Все 8 Комментарий

meow_hash полностью зависит от наличия инструкций AES с аппаратным ускорением.

Я подозреваю, что без этих инструкций он даже не скомпилируется, так как код довольно короткий, и я не вижу пути для резервного кода программного обеспечения. Кроме того, все инструкции AES, которые я мог прочитать, используют прямые встроенные функции Intel, поэтому они не переносятся по архитектуре, независимо от возможностей оборудования.

Это не обязательно «плохо»: в конце концов, они получают взамен большую скорость за длительный ввод.

Но главное в том, что при использовании такого специализированного набора аппаратных инструкций переносимость исключена из списка возможностей.

В качестве побочного эффекта он даже не будет работать на платформе, используемой для тестов xxHash.

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

Это уже не так, вы должны вернуться к этому.

Да, читая объявления, мяу значительно улучшилось в нескольких версиях.
Он даже объявляет о совместимости с ARM.

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

Я только бегло посмотрел и не смог найти путь к программному резервному копированию. Может, он есть и я его просто пропустил.
Кроме того, я еще не знаю, гарантированно ли разные аппаратные модули AES будут выдавать точно такое же хеш-значение, или есть что-то еще (например, дополнительные параметры, которые могут быть заданы по-разному и требуют, чтобы инструкции для конкретной машины были единообразными). Одно дело - вычислять и использовать хэш локально, и в этом случае точное представление не имеет значения. Другой способ записать / сериализовать значение и ожидать, что оно будет прочитано / воспроизведено точно в любой другой системе. Эта часть взаимодействия немного сложнее.
Но, опять же, может быть, это есть, и мне просто нужно время, чтобы разобраться в этом.

Для справки, это против моей последней версии, Core i7 Gen 2 2,0 ГГц (Sandy Bridge).

Clang 7.0.1
Флаги: -O3 -march=native

./xxhsum 0.6.5 (64-bits little endian), by Yann Collet
Sample of 100 KB...
XXH32               :     102400 ->    54765 it/s ( 5348.2 MB/s)
XXH32 unaligned     :     102400 ->    53782 it/s ( 5252.1 MB/s)
XXH64               :     102400 ->   104882 it/s (10242.4 MB/s)
XXH64 unaligned     :     102400 ->   105935 it/s (10345.2 MB/s)
XXH32a              :     102400 ->    78027 it/s ( 7619.8 MB/s)
XXH32a unaligned    :     102400 ->    75624 it/s ( 7385.2 MB/s)
XXH64a              :     102400 ->    77204 it/s ( 7539.5 MB/s)
XXH64a unaligned    :     102400 ->    76209 it/s ( 7442.3 MB/s)
XXH auto            :     102400 ->   105179 it/s (10271.4 MB/s)
XXH auto unaligned  :     102400 ->   101546 it/s ( 9916.6 MB/s)
XXH32 auto          :     102400 ->   107646 it/s (10512.3 MB/s)
XXH32 auto unaligne :     102400 ->   104364 it/s (10191.8 MB/s)
XXH64 auto          :     102400 ->   107443 it/s (10492.4 MB/s)
XXH64 auto unaligne :     102400 ->   105843 it/s (10336.3 MB/s)
meow auto           :     102400 ->   214435 it/s (20940.9 MB/s)
meow auto unaligned :     102400 ->   213289 it/s (20829.0 MB/s)

С -march=penryn -mno-sse4.2 -mno-avx и реализацией C:

./xxhsum 0.6.5 (64-bits little endian), by Yann Collet
Sample of 100 KB...
XXH32               :     102400 ->    54106 it/s ( 5283.8 MB/s)
XXH32 unaligned     :     102400 ->    53303 it/s ( 5205.4 MB/s)
XXH64               :     102400 ->   107245 it/s (10473.1 MB/s)
XXH64 unaligned     :     102400 ->   107774 it/s (10524.8 MB/s)
XXH32a              :     102400 ->    78394 it/s ( 7655.6 MB/s)
XXH32a unaligned    :     102400 ->    79666 it/s ( 7779.9 MB/s)
XXH64a              :     102400 ->    78907 it/s ( 7705.7 MB/s)
XXH64a unaligned    :     102400 ->    78179 it/s ( 7634.6 MB/s)
XXH auto            :     102400 ->   108878 it/s (10632.6 MB/s)
XXH auto unaligned  :     102400 ->   105124 it/s (10266.0 MB/s)
XXH32 auto          :     102400 ->   105819 it/s (10333.9 MB/s)
XXH32 auto unaligne :     102400 ->   103970 it/s (10153.3 MB/s)
XXH64 auto          :     102400 ->   110021 it/s (10744.2 MB/s)
XXH64 auto unaligne :     102400 ->   107109 it/s (10459.9 MB/s)
meow auto           :     102400 ->    15962 it/s ( 1558.8 MB/s)
meow auto unaligned :     102400 ->    16022 it/s ( 1564.6 MB/s)

Это уже не так, вам следует вернуться к этому

... ааа и в Meow 0.5 это снова правда; в последней версии у них снова только кодовый путь x64 AES :)

Так что да, Meow Hash как бы специфичен для x86_64 и Nehalem +, иначе он должен переключиться на резервную версию с медленным переходом.

Между тем, XXH3 имеет векторизованные пути кода для всех x86_64 (включая Core 2 и других), Pentium 4+ (что требуется для Windows 7+), ARMv7-A с NEON (доступно на большинстве Android и всех iOS-устройств, кроме оригинального iPhone. ), ARM64 (все последние iPhone и Android), VSX POWER9 (они есть на многих серверах и суперкомпьютерах, но это нишевый рынок), и если этого было недостаточно, даже скалярная версия все еще очень быстра даже на 32-битных цели, при условии, что у них есть приличный множитель.

Я начинаю собирать еще несколько результатов тестов, так как за эти годы было несколько запросов такого рода.
Начиная с этого, запрос был постоянным.

meowHash действительно очень быстр, примерно такая же скорость, как XXH3 для больших данных (~ 100 КБ), следовательно, немного быстрее, чем XXH128 .
https://github.com/Cyan4973/xxHash/wiki/Performance-comparison

При этом meowHash действительно разработан для больших данных. Когда дело доходит до _small_ данных, производительность несопоставима, поскольку алгоритм требует больших фиксированных затрат, которые плохо амортизируются для небольших данных.

Вызывает тревогу тот факт, что существует несоответствие в том, «как представлять и интерпретировать результаты».
Для больших данных это довольно просто, может быть достаточно отсортированной таблицы, дающей мгновенное представление о рейтинге.
Однако для небольших данных это кажется более сложным.
До сих пор я использовал графики, дающие результат по скорости для разной длины и сценария. Благодаря большему количеству информации ее труднее интерпретировать.

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

Другой вопрос - сами графики. Сортированную таблицу можно относительно легко расширить. Конечно, есть ограничения, но, вообще говоря, добавление соперника добавляет лишь строчку.
Однако на графике каждый соперник представлен линией. Линии имеют тенденцию перекрываться. Есть только так много цветов, из которых можно выбирать и т. Д. Очень быстро, если количество представленных соперников велико, это просто большой беспорядок.
Таким образом, если производительность малых данных требует графа, это сильно ограничивает количество претендентов, которые могут быть представлены.

Добавление параграфа, содержащего "сырые" контрольные данные, хотя и заслуживает похвалы, - плохая замена.

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

По-прежнему существует проблема, заключающаяся в том, что графики могут представлять только ограниченное количество претендентов, и, возможно, тот, который читатель хочет наблюдать, не является частью выбранного списка (даже если доступны необработанные данные).

Мне было интересно, есть ли лучший способ представления графиков. Что-то более динамичное, чем подготовленный снимок экрана, позволяющее пользователю выбирать, какие соперники должны быть видны.

Мяу-хеш добавлен для сравнения:
https://github.com/Cyan4973/xxHash/wiki/Performance-comparison

Добавление записи в таблицу - нормально.
Но мне все еще нужен лучший способ рисования графиков для большого количества кандидатов.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги