самая быстрая хеш-функция = t1ha.

самая быстрая хеш-функция

Не стоит сравнивать не-переносимые хеши (например аппаратный sha или кульбиты на AVX2) с portable code.

Давайте попробуем найти лучшее, оставляя за скобками привязку к уникальным инструкциям/возможностям CPU.

А смысл? Благо интерфейс хэш-функции известен, а детали реализации могут быть спрятаны внутри миллионом ифдефов. Конечному-то юзеру, если речь о нём, обычно фиолетово, portable code там, или интринзики.

portable тут в другом контексте, суть в сохранении показателей производительность на разных платформах (попугаев на мегагерц).

Например, HighwayHash выдает нам 13 условных попугаев (хешей в секунду) на на x86_64 c avx2, и в 10-100 раз меньше в некоторых других случаях.

Соглашусь, что «portable» тут не лучший термин, но другого пока нет (предлагайте).

ДИСКЛАЙМЕР (а как это по-русски?)

Отказ от ответственности (притязаний).

portable тут в другом контексте, суть в сохранении показателей производительность на разных платформах (попугаев на мегагерц).

Я понял, в каком контексте тут портабл, но на всякий случай уточню -

При отсутствии изменений в самом коде? На сишке? Чисто засчёт compiler-based оптимизации?

Говорят (C), что это утопия и зависит исключительно от интеллектуальности компилятора на той или иной платформе. Даже вон OpenCL, который более constrained, и тот перфоманс портабильности не обеспечивает (ну т.е. код может быть написан универсально и работать одинаково медленно, да :)).

Поэтому я и указал, что «самая быстрая» и portable тут друг другу мешают.

Кстати, интересно, как такое хеширование показало бы себя, будучи реализовано на Halide.

Изнви/занят/коротко.

Количество воплощённы (обязательных) операций - метрика?

Метрика, пожалуй, GB/s :)

Хотя да, эта метрика абсолютная и зависит от платформы, на которой выполняется код.

Скорость хеширования потока - не единственный показатель, на который стоит смотреть.

Во многих реальных применениях «ключи» короткие.

К слову, для разработчиков хешец это отдельное отжимание )

Не стоит сравнивать не-переносимые хеши (например аппаратный sha или кульбиты на AVX2)

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

Давайте попробуем найти лучшее, оставляя за скобками привязку к уникальным инструкциям/возможностям CPU.

Стоп. Если некая функция, тут неважно хэш или любой другой мат. алгоритм, и ее можно оптимизировать за счет avx, то какбы это значит это свойство самой функции. Значит она хорошо векторизуется. А сравнивать скорость функций без векторизации/паралилизма - глупо и не имеет практического и теоретического смысла.

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

То есть avx, например, это не какая-то мифическая фича проца все ускоряющая. С помощью avx можно ускорить только алгоритмы это позволяющие в теории. Это же просто simd же

Т.е. AVX всё равно в итоге появляется, но как продукт компиляции, а не прямой продукт рук человеческих

Ааа, ну тогда ок. Но все равно, тогда тут еще помимо мат. свойств функций тестируется еще и способность компилятора оптимизировать=)

Да, о чём я выше и писал ТСу

Не стоит сравнивать не-переносимые хеши (например аппаратный sha или кульбиты на AVX2)

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

Не стоит мерятся производительностью, т.е. если нужно быстро на конкретном проце/архитектура - это другое решение.

Например, без AVX, SSE, SHA, Neon, AES-NI и т.п.:

t1ha2_atonce            :    205.500 cycle/hash,  0.201 cycle/byte,  4.983 byte/cycle, 14.949 Gb/s
xxhash64                :    236.625 cycle/hash,  0.231 cycle/byte,  4.328 byte/cycle, 12.983 Gb/s
HighwayHash64_portable  :   2880.000 cycle/hash,  2.812 cycle/byte,  0.356 byte/cycle,  1.067 Gb/s

А вот с использованием оных фичей CPU:

t1ha0_ia32aes_avx2      :     94.125 cycle/hash,  0.092 cycle/byte, 10.879 byte/cycle, 32.637 Gb/s
HighwayHash64_avx2      :    230.250 cycle/hash,  0.225 cycle/byte,  4.447 byte/cycle, 13.342 Gb/s

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

о есть avx, например, это не какая-то мифическая фича проца все ускоряющая. С помощью avx можно ускорить только алгоритмы это позволяющие в теории. Это же просто simd же

Нечаянно тут можно всё вмешать и запутать, поэтому хочу прояснить.

Авто-векторизацию сейчас умеют примерно все компиляторы, которые поддерживают кодогенерацию для процессоров с SIMD.

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

Однако, если ради скорости хеширования на конкретном CPU привязываться к его особенностям/фичам, то вместо SIMD логично использовать AES-NI или SHA-инструкции.

Соответственно поэтому, в случае t1ha, афтар НЕ пишет вектор-френдли код от слова совсем. Более того, по той-же причине я считаю HighwayHash достаточно никчемным.

Имплементация на JS есть?
Чо там с коллизиями?

С коллизиями всё отлично, даже более сем. Короче, RTFM.

js - нет, ибо unreasonable, но приму пулл-реквест.

ДИСКЛАЙМЕР (а как это по-русски?):

Отмазка.

Укуси взад того юриста, который тебе это наплел.

Вики:

Дисклеймер (англ. Disclaimer) — письменный отказ от ответственности за возможные деликтные последствия того или иного поступка в результате действий заявившего данный отказ либо третьих лиц. Под деликатными понимаются любые виды ответственности заявителя. Дисклеймер появился и получил широкое распространение в Соединённых Штатах Америки, где он по-прежнему применяется повсеместно, в том числе и в быту.