EugeneRoshal
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору uShell Цитата: а оптимизации привязаны к степени сжатия? | -m1 использует свою реализацию поиска строк, и часть оптимизаций к -m1 неприменима. Для -m2 ... -m5 они используются одинаково. Цитата: Если какое-то изменение даёт выигрыш в скорости ценой степени сжатия | На всех моих тестах потеря сжатия новой версии по сравнению с 5.80 не превышает сотых долей процента, то есть, пренебрежимо мала. При этом выигрыш в скорости от этой потери сжатия вполне заметен. Впрочем, желающие могут сами сравнить сжатие rarbase.exe из http://www.rarlab.com/rar/.1/rar59v2.rar и rar 5.80. Если мне самому удастся увидеть потерю сжатия хотя бы в пару десятых процента, тогда надо будет думать что с этим делать. Можно будет рассмотреть и предложенный вами вариант. Цитата: Кстати, если размеры блоков подбираются под кэш, их вполне можно не "зашивать" в алгоритм, а читать из конфигурации | Это имело бы смысл, если бы какой-то из размеров вызывал заметное замедление на каком-то из процессоров. Для Xeon E5-2650v2 мы перебрали все размеры блоков и все они в RarBase.exe для него оптимальны. Для 3950X я их подбирал специально, и они тоже оптимальны. Для i7-6700k и пары других старых интеловских low end CPU я, вроде бы, наблюдал 1-2% падения скорости из-за неоптимальности размера одного из блоков. Но это на уровне погрешности и иногда на 6700k превращалось в 0%, а то и в небольшой выигрыш новой версии. Статистика пока крайне скудна для каких-то выводов. Единственный новый процессор, на котором проверялась эта версия, это упомянутый выше 3950X. Как оно работает на 3900X, 3700X, 9900k, 9700k информации пока нет. А именно на новых многоядерниках я и ожидаю выигрыш в скорости от этой оптимизации. |