search

erthink / t1ha

One of the fastest hash functions
https://www.ptsecurity.com
Other
345 stars 31 forks source link

[REJECTED] Бинарник для Windows #2

Closed sergeevabc closed 7 years ago

sergeevabc commented 7 years ago

Леонид, в разделе релизов одни исходники, хорошо бы скомпилировать .exe под Win7x64.

Slach commented 7 years ago

Сергей, можно я за автора отвечу? какой такой бинарник? это чисто библиотечный код, в нем main никакого нету и не предвидится

erthink commented 7 years ago

Как верно было подмечено @Slach бинарников здесь точно не будет. Грубо говоря, примерно в 100500 раз проще встроить t1ha в проект на уровне исходного кода, нежели подключать какие-то бинарники, а мне обеспечивать их сборку.

Для тестирования есть отдельный проект smhasher, см. README.md. Однако, если не ошибаюсь, там есть проблемы со сборкой под Windows.

Более того, пока t1ha требует для компиляции GCC-совместимый компилятор. Если вам нужна поддержка MSVC, то два варианта:

sergeevabc commented 7 years ago

@leo-yuriev, «бинарник» это скомпилированная (двоичная, готовая к запуску, binary executable) версия «сырца» (исходного кода, source). Т.е. искал попробовать .exe для платформы Windows. Ибо алгоритмов подсчёта контрольных сумм/хэширования придумано уже вагон и тележка, но обычный пользователь на состояние 2016 года всё ещё использует CRC32, MD5 и SHA1, часами обсчитывая/верифицируя целостность .iso, .mkv и прочих крупных файлов. Редко встретишь более производительные Blake2sp в HashTab, Edonr512 в Rhash, Skein512 в Digest и xxHash64 в платной версии HashOnClick. Зато сравнительных графиков пруд пруди, а толку? Лежат-пылятся.

@Slach, почему Сергей? Лучше лишний раз зайти в профиль и уточнить имя.

Bulat-Ziganshin commented 7 years ago

я вам рекомендую blake2sp, это всё же 256-битный криптохеш со скоростью несколько гиг/сек на современных cpu. из того что можно легко найти в готовом виде: 7z h -scrcsha256 files... - 200 МБ/сек 7z h -scrcsha1 files... - 400 МБ/сек

бесплатная gui-утилита: http://encode.ru/threads/1707-CHK-Checksum-Utility?p=42452&viewfull=1#post42452

erthink commented 7 years ago
  1. BLAKE2sp:
    • быстрее чем t1ha, так как использует аппаратное ускорение (SIMD/SSE на x86).
    • 7z h -scrcBLAKE2sp
  2. t1ha для другого:
    • не-криптографическое хеширование;
    • на разных платформах (не x86_64), с приличной скоростью и одинаковыми результатами;
    • т.е. так чтобы при переходе с платформы на платформу или смене CPU у вас принципиально ничего не менялось.
sergeevabc commented 7 years ago

@Bulat-Ziganshin, честь видеть вас в сей скромной теме — много лет наблюдаю за вашей деятельностью. Однако ирония в том, что именно вы, современный Прометей, обладатель золотых мозгов по части архивирования (привет долгострою Freearc) и оптимизации (чего стоят доработки xxHash) до сих пор держите всё это внутри «академической тусовки». Тем временем народ «на земле» истово алчет обсчитать больший объём за меньшее время, но находит лишь более-менее скоростную реализацию устаревших CRC32/MD5/SHA1.

По всем тестам xxHash32/64 в разы быстрее CRC32, так может пора спустить огонь на землю?

Приведу пример шагания в ногу со временем: создатель менеджера паролей Keepass осчастливил бетой с оптимальной функцией формирования ключа Argon2, оставив в прошлом b/scrypt/PBKDF2.

Bulat-Ziganshin commented 7 years ago

зачем ваш скорость хеширования в десятки ГБ/с? эти алгоритмы разрабатываются для in-memory использования. для хеширования же файлов я вам уже дал советы на все случаи жизни

@leo-yuriev скорость t1ha - 20 ГБ/с на ядро, скорость SIMD-реализации blake2sp - 1 ГБ/с на ядро. авторы blake2 предоставляют не то exe, не то исходники (я уже не помню), позволяющие обсчитывать порядка 3 ГБ/с на i7-2600K (используя все ядра). К слову, используя ту же технику simd+mt распараллеливания, SHA1p обсчитывается со скоростью 14 ГБ/с, а SHA2p - кажись те же 3 ГБ/с (соответствующий код есть в OpenSSL, данные получены из его встроенного бенчмарка). А не за горами ещё и процессоры с инструкциями SHA...

sergeevabc commented 7 years ago

@Bulat-Ziganshin, в присоветованной GUI-утилите CHK отсутствует алгоритм Blake2sp, а сама она далека от удобства также бесплатных RapidCRC или MultiHasher (скажем, обсчёт крупного файла из списка можно прервать лишь закрытием программы с потерей предыдущих данных).

Кстати, просил тех и других, чтобы внедрили Blake2sp. Так мнутся на месте: «мол, есть аж четыре версии Blake2 и какую поддерживать — не знаем». Вот так нерешительность тормозит прогресс.

Из консольных под Windows хороши Rhash (Edonr512, бывший конкурент Blake2, побеждает на встроенном тесте), Hashdeep (есть уникальные фишки типа piecewise mode) и Digest (Skein512 обгоняет различные версии Blake2 на встроенном тесте).

Но вопрос остаётся: xxHash64 быстрее для контроля целостности файлов, чем CRC32?

Bulat-Ziganshin commented 7 years ago

мне кажется я ясно написал - скорость xxHash64 - 16 ГБ/с, t1ha - 20 ГБ/с, CRC32 - от 3 до 30 ГБ/с. и это ещё без учёта многоядерности. у вашего hdd скорость какая?

Bulat-Ziganshin commented 7 years ago

Кстати, просил тех и других, чтобы внедрили Blake2sp. Так мнутся на месте: «мол, есть аж четыре версии Blake2 и какую поддерживать — не знаем». Вот так нерешительность тормозит прогресс.

очевидно rar'овскую. подозреваю что в 7z именно она, только без оптимизации.

в присоветованной GUI-утилите CHK отсутствует алгоритм Blake2sp, а сама она далека от удобства

вот-вот. вы ожидаете от автора ещё и разработки удобной gui-утилиты? наверно нет. тогда зачем вам этот exe-шник - вообще непонятно

sergeevabc commented 7 years ago

@Bulat-Ziganshin, скоростные характеристики тестового HDD:

1

Вы ожидаете от автора ещё и разработки удобной gui-утилиты?

Ожидаю бинарник, простой консольный hash.exe путь-до-файла. Чтобы технология вышла из соревнования «академиков» между собой и помогла обычным людям. А удобство — со временем. Как удобство пришло в RapidCRC и MultiHasher (хотя начиналось с консольной md5sum), которые лучше советовать, когда говорим о разработанной поляне CRC32/MD5/SHA1, чем CHK (понятно, последняя программа вам ближе, ибо её автор тусуется на Encode.ru).

Bulat-Ziganshin commented 7 years ago

Вот и сравните "максимум 125 МБ/с" с 3 ГБ/с вышеупомянутого blake2sp

Ожидаю бинарник, простой консольный hash.exe путь-до-файла

тогда возьмите 7z-sha{1,2} или blake2sp, чем они вас не устраивают? по качеству эти криптохеши на голову лучше таких простых хешей как xxhash/t1ha

Чтобы технология вышла из соревнования «академиков» между собой и помогла обычным людям.

эта технология вообще для решения других задач соптимизирована. её нет смысла на медленных носителях применять. был бы у вас хотя бы ram-disk... :)

sergeevabc commented 7 years ago

@Bulat-Ziganshin, давайте я опишу типичный сценарий и движение мысли.

Скажем, есть образы iso, фильмы mkv и фотографии raw — это большие файлы и их много. Гоняешь их туда-сюда: делаешь бэкапы, делишься с кем-то, etc. Для подтверждения целостности (что файлы в точках А и Б совпадают) считаешь контрольные суммы. Крипто здесь избыточен, вероятность коллизий минимальна, так? Требуется лишь скорость. Замеряешь CRC32/MD5/SHA1/Blake2sp (и ряд вышеупомянутых других) — зачастую побеждает CRC32. Потом гуглишь-гуглишь и находишь графики, убеждающие тебя, что CRC32 это не предел и можно быстрее.

Bulat-Ziganshin commented 7 years ago

вы меня извините просто убиваете. я вам десять раз уже написал, что бенчмарки в памяти - это одно, а с файлами вы всё равно упрётесь в скорость самого диска. неужели вы неспособны понять, что 3 ГБ/с - быстрее любого вашего диска? поэтому авторам rhash и т.д. достаточно добавить совместимый с rar5 хеш. а вы похоже исходите из принципа "чужого времени не жалко", пытаясь заставить других людей выполнять совершенно ненужную работу.

sergeevabc commented 7 years ago

@Bulat-Ziganshin, это потому, что вы говорите как с другим «академиком», а я из народа. И вот, что я слышу: «алгоритмы работают быстрее, чем работает диск — диск это бутылочное горлышко, поэтому смена алгоритма не принесёт выгоды, а только оторвёт чужое время». Такой ответ противоречит тому, что я вижу: CRC32 при обсчёте файлов опережает Blake2sp со всеми его Гб/с.

Отсюда вопрос: возможно ли в данных условиях превзойти CRC32 (с помощью xxHash64)?

Bulat-Ziganshin commented 7 years ago

видите где? если в бенчмарках, то они работают в озу. если в hashtab/7z, то там видимо реализовано неоптимально. вы возьмите blake2sp.exe от создателей blake2 и потестируйте. Вот exe-шник, который я компилировал в 13-м году из их кода, он даёт 1 ГБ/с на моём cpu (скорость 3 ГБ/с я высчитал исходя из 5 циклов/байт, которые рапортует их собственный бенчмарк - не знаю, почему в реальности всё гораздо хуже). От реализации в 7z/hashtab он отличается полноценным использованием многопоточности.

C:\Testing\!Hashing\blake2_code_20130131\b2sum\sse2>timer b2sum-x64.exe -a blake2sp z:\4g
ffeaa3d66b2c995c5c672657ba50d0ff8f28255121ab7cdb438a1c47558a9f0e z:\4g

Kernel Time  =     1.825 = 00:00:01.825 =  39%
User Time    =    19.328 = 00:00:19.328 = 413%
Process Time =    21.153 = 00:00:21.153 = 452%
Global Time  =     4.680 = 00:00:04.680 = 100%
sergeevabc commented 7 years ago

Методика испытаний:

То есть

dd if=/dev/random of=january bs=1G count=4
contig january
...
timecmd rhash --crc32 january
timecmd blake -a blake2sp february
...

Получил следующие результаты.

Алгоритм Программа Время
CRC32 Rhash 1.3.4 0:00:49.88
Blake2sp x64, офсайт 0:01:00.45
Blake2sp x64, ваша 0:01:05.58
Bulat-Ziganshin commented 7 years ago

и то что времена настолько близки, вам ничего не говорит? скорей всего ращзница только в том, что rhash умнее и делает I/O параллельно с вычислениями, а b2 - по очереди. вы dd в nul замерьте. ну и померяйте скорость всего этого на меньших файлах, которые в дисковый кеш влезают

Bulat-Ziganshin commented 7 years ago

и вместо батника возьмите программу, которая показывает cpu time, хотя бы игоревскую. там увидите, что crc у вас простаивает большую часть времени, да и b2 и одного ядра не загружает

sergeevabc commented 7 years ago

Какую «Игоревскую программу» взять для замера? Ваш timer готов попробовать.

Дополнительные результаты.

Алгоритм Программа Время
CRC32 7z 16.04 x64 0:00:45.54
Blake2sp 7z 16.04 x64 0:00:46.24
Bulat-Ziganshin commented 7 years ago

timer включен в пакет http://www.7-cpu.com/utils.html. Или можете скачать мой набор - там кроме timer, есть ещё и read, замеряющий скорость чтения файла с диска.

4GB/45 = ~100 MB/sec, это и есть скорость вашего диска. в общем, у нас типичная ситуация - когда программист разбирается с хотелкой пользователя, выясняется что она бессмысленна, поскольку тот не разбирается в элементарных (ну с моей точки зрения) вещах. Вот вам типичный скан скорости HDD, создаваемый программой HD Tune Pro. Как видите, скорость меняется от 120 МБ/с в начале диска до 60 МБ/с в конце: image

Bulat-Ziganshin commented 7 years ago

забавным образом, у меня нет дисков медлененей 400 МБ/с. вот что выходит у меня: первое выполнение упирается в скорость cpu и потому User Time (т.е. собственно время вычисления хеша) = 93% от Global Time. второе же упирается в скорость диска и потому user time там всего 20% от общего времени работы.

Z:\>timer 7z h -scrcblake2sp 4g.dll
1 file, 4531060447 bytes (4322 MiB)
Kernel Time  =     0.748 = 00:00:00.748 =   4%
User Time    =    14.102 = 00:00:14.102 =  93%
Process Time =    14.851 = 00:00:14.851 =  98%
Global Time  =    15.147 = 00:00:15.147 = 100%

Z:\>timer 7z h -scrccrc32 base-_128m-m1.rar5
1 file, 4639243236 bytes (4425 MiB)
Kernel Time  =     0.842 = 00:00:00.842 =   8%
User Time    =     1.934 = 00:00:01.934 =  20%
Process Time =     2.776 = 00:00:02.776 =  29%
Global Time  =     9.500 = 00:00:09.500 = 100%
sergeevabc commented 7 years ago

Вывод слегка отличается, ибо timer на офсайте 14.0.0 x64, а у вас 3.01 x86.

CRC32

timer64 7z h -scrccrc32 march
1 file, 4294967296 bytes (4096 MiB)
Kernel  Time =     2.402 =    4%                                
User    Time =     2.184 =    4%                                
Process Time =     4.586 =    9%    
Global  Time =    49.036 =  100%

SHA1

timer64 7z h -scrcsha1 april
1 file, 4294967296 bytes (4096 MiB)
Kernel  Time =     2.184 =    4%                                
User    Time =    11.965 =   23%                                
Process Time =    14.149 =   27%    
Global  Time =    50.864 =  100%

Blake2sp

timer64 7z h -scrcblake2sp may
1 file, 4294967296 bytes (4096 MiB)
Kernel  Time =     2.168 =    4%
User    Time =    18.642 =   36%
Process Time =    20.810 =   40%    
Global  Time =    51.038 =  100%

Выходит, CRC32 в данных условиях за примерно равное время наименее прожорливый? То есть и потребляет меньше энергии и оставляет больше ресурсов другим приложениям? И главное: могут ли xxHash64, t1ha, etc обсчитать файлы за то же время, съедая ещё меньше?

Bulat-Ziganshin commented 7 years ago

да, всё верно. лучше всего тут будет crc32c - он позволит снизить загрузку процессора с 4% до 0.5% и таким образом сэкономить примерно 2 ватта.

sergeevabc commented 5 years ago

@leo-yuriev, t1ha по-прежнему не доступен в виде .exe, верно?