EugeneRoshal
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
notAlx
В 5.90 это поломалось в Win10 2004. Я в 5.91b1 это исправил.
persicum
Я имел в виду поделить весь входной поток на блоки фиксированного размера. Для примера, пусть по 1 кб. При этом каждый свободный поток из пула потоков берет очередной доступный для обработки 1 кб блок, считает его хэш и кладет результат в какой-нибудь буфер. Хэш этого буфера можно считать либо целиком отдельным потоком, либо аналогично, разбив его на 1 кб блоки.
Если у нас в наличии одно ядро и один поток, значит этот единственный поток в одиночку будет обрабатывать 1 кб блоки. Если у нас 5 потоков, значит они по очереди будут выхватывать доступные блоки. Значение хэша в любом случае будет одним и тем же. То есть, речь не просто об изменении константы количества потоков в Blake2sp, а о другом алгоритме, пусть и на основе Blake2.
Вероятно, по сравнению с нынешним Blake2sp придется больше потратиться на синхронизацию потоков. Насколько это повлияет на общую производительность - без практической проверки сказать сложно. А реализовывать это мне не очень интересно, так как, если уж и менять Blake2sp, то хотелось бы, чтобы это был общепринятый хэш, а не нечто, уникальное для RAR. Кроме того, как вы сами заметили, производительность Blake2sp уже достаточно высока.
Не исключаю, что в Blake3 и реализовано нечто подобное, я детально его не изучал. Но тогда непонятно, откуда тяжеловесность Blake3. Предлагаемый выше алгоритм достаточно прост. |
