EugeneRoshal
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
naposidi
Цитата:| если стоит ещё вопрос скорости, посчитал уместным упомянуть новый blake3 |
Указанная разработчиками скорость blake3 действительно впечатляет, но возникает вопрос совместимости.
В принципе RAR5 позволяет сохранить для одного и того же файла и CRC32, и Blake3. При этом распаковщик будет использовать только ту контрольную сумму, о которой он осведомлен. То есть, в случае старой версии распаковщика - CRC32. Реально я это не проверял, но, судя по исходникам, оно должно работать именно так.
Тогда, чтобы избежать проблем с совместимостью, мы можем создавать архив и с CRC32, и с Blake3. Но тут возникает другая проблема. Если верить диаграмме, Blake3, пожалуй, и быстрее будет, чем rar'овский slicing-by-8 CRC32. То есть, если мы считаем обе контрольные суммы, то при упаковке выигрыш в скорости от использования Blake3 теряется. Можно попробовать дополнительно ускорить CRC32, используя slicing-by-16, или slicing-by-32, или PCLMULQDQ. К сожалению, SSE4.2 CRC32 инструкция не годится из-за другого полинома. Но в любом случае подсчет двух контрольных сумм будет медленнее, чем одной.
Если считать только Blake3, насколько я помню эту часть кода, старые версии смогут распаковать такие архивы, но не смогут проверить их целостность. Тоже не совсем хорошо. Как вариант, можно записывать и CRC32, и Blake3 в качестве временной переходной меры, а через несколько версий перейти только на Blake3.
Это рассуждения на случай если вообще использовать Blake3. В 5.90 я его использовать не планирую, а дальше надо будет думать, стоит ли на него переходить с Blake2 и есть ли более интересные варианты хэш-функций. Пока на мой взгляд Blake3 наиболее привлекателен из доступных хэшей, но и уже используемый Blake2sp, в общем-то, довольно быстр.
Кроме того, Blake3 еще очень нов и свеж. Надо дать ему время на отлежаться и оттестироваться. |
