Ghost2004
Junior Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Спасибо огромное - 0.8-ая версия srep крута;).
Подробности будут позже - всё же те 24-27 Гб образов надо ещё из рар-ов, в которых они пока хранятся извлечь, да тар-ом затарить (или вместо тар'а использовать обычный rep freearc'а - но это уже отдельная история)... Так что свободное место придётся расчищать и перетасовывать. Так что пока на тех самых 7'906'363'392 тестирую.
Так вот, скорость декомпрессии на них - 20-25 Мб/с реального времени, 190 Мб/с - процессорного - так что, судя по всему, упёрлось всё в не самые новые диски, у меня при декомпрессии идёт чтение с 250-ки Seagate Barracuda 7200.8 ST3250823AS (8 Мб кэша), а запись (и повторное чтение - кстати, заметил что одно из серьёзных улучшений по сравнению с 0.7 - 0.8 читает данных (видно в диспетчере задач виндов) те же ~8 Гб, а 0.7 читала аж ~53 Гб (при -l256), поэтому и скорость выходит 20-25 в 0.8, а не 10-15) - на раздел 750-ки Seagate Barracuda 7200.10 ST3750640AS (16 Мб кэша у диска). То есть может тут вылезло ограничение в скорости дисков - надо же читать с одного диска, а на другой - и читать и писать на другой (и хоть диски на разных контроллерах висят, всё равно).
Хотя уже сжатые (первые 1.5 Гб после rep:1400mb:128:a99) данные пишутся со скоростью до 31 Мб/с - но потом она всё равно до 25 Мб/с падает (наверное 31 Мб/с - близко к копированию с моего неоптимального диска - 250-ки, на диск побыстрее - 750-ку, а вот если требуется ещё и с 750-ки читать, то скорость падает до 20-25 Мб/с - на этих данных - возможно они чем-то оптимальны, и много влезает в кеш винодоуз).
Что радует больше всего - скорость декомпрессии - те же 20-25 Мб/с реальных и 190 Мб/с процессорных и при мин.длине слова 128 или 256, и при мин.длине слова 16384.
А вот скорость компрессии как раз зависит от этой длины - как и должна: 19 Мб/с CPU, 15 МБ/с реальная при совпадениях от 16кб (сжатый размер - 4 572 251 124 - а в 0.7 версии был 4 600 444 500). 8 Мб/с CPU и 6.5 Мб/с реальная - при l256 (сжатый размер - 4 011 245 268; в 0.7 такие результаты достигались лишь если пройтись обыной rep:1400mb:256:h25 - rep:256+srep-l256 давала 4 009 500 500, а srep-l256+rep:256 3 999 030 405 - даже возникла идея сначала проходиться rep'ом той же мин.длины совпадения из-за того, что читалось в 6.5 раз больше, чем размер файла - т.е. уже ужатые до 6.2 Гб обычным репом данные читали при распаковке не 53 Гб, а лишь 41 Гб - 0.8-ая читает примерно столько же, сколько пишет, 7-8 Гб). Что характерно - в 0.7 версии два прохода srep -l256 таки неплохо помогали, откусывая 110 Мб - размер srep07-l256+sep07-l256 был 4 107 630 240 - всё равно заметно хуже, чем с обычной rep:1400mb:h25. В 0.8 толку во втором проходе - минимум, лишь 13 мб выигрыша - srep08-l256+srep08-l256 даёт 3 997 881 040 - а это уже меньше, чем rep:256+srep07-l256 - да и лучше и быстрее выйдет . Да, а ещё в 0.7 версии я пробовал и вариант с и пост- и пред- обработкой rep:1400mb:256:h27 - rep:256+srep07-l256+rep:256 - и от лишней обработки вышел неплохой выигрыш в 60-70 Мб - такой вариант давал 3 934 840 970 . На 0.8 я такого ещё не пробовал - впрочем, тут наверное стоит только пост-обработкой ограничиться.
Да, а ещё я поигрался с перебазировкой dll'ок так что у 0.8 версии - так что там таки удалось запустить srep -l128. Скорость сжатия с такой настройкой стала 7.16 Мб/c CPU, 6.5 реальная. Размер вышел 3 916 538 436 . Если сначала пройтись rep:1400Mb:128:a99:h27 - то получается 3 827 972 128 .
Короче, если собрать это дело в таблицу, то выйдет следующее:
Скорость и время сжатия 0.8 версии (для оригинального набора, без предварительной rep - там несколько другие цифры выходят):
l16kb - 19.196 Мб/с Cpu, 14.998 Мб/с real (Global 527.453 sec, Process 442.593 sec)
l256 - 7.915 Мб/с Cpu, 6.465 Мб/с real (Global 1223 sec, Process 1138.125 sec)
l128 - 7.160 Мб/с Cpu, 6.477 Мб/с real (Global 1227.219 sec, Process 1134.859 sec)
то же для расжатия:
l16kb - Cpu 191.235 mb/sec, real 20.236 mb/sec
l256 - Cpu 191.163 mb/sec, real 24.134 mb/sec
l128 - Cpu 190.658 mb/sec, real 21.505 mb/sec (кстати, тут уже размер прочитанного вырос почти до 9 Гб - наверное поэтому и немного помедленней)
l256 второй проход, данные уже были сжаты srep08-l256 - Cpu 178.774 mb/sec, real 27.547 mb/sec
l128 второй проход (но уже после простого rep:1400mb:128:a99:h27) - Cpu 187.313 mb/sec, real 24.360 mb/sec
Размеры:
Исходные данные - 7540.096 Мб
После rep:1400mb:128:a99 или rep:1700mb:128:a99:h27 - 5788.845 Мб (время распаковки-тестирования с 250-ки - 50.41 сек cpu, 224.38 сек real, скорость ~35 Мб/c - вероятно как раз в районе скорости того жёсткого диска)
Исходные данные сжатые рар'ом (в таком виде пока хранятся) - 5179.315 Мб
rep:1700mb:128:a99+lzma:192mb:max:bt4:128:lc8 - 4885.368 Мб (у рара выиграно лишь 294 Мб, 6% от сжатого размера - но какой ценой!) - сжал фриарком, без ухищрений с перестановками блоков или srep . Время сжатия - real - 9778 sec (из них 1177 - засчёт rep:128:a99 с tempfile), CPU - 13551 sec . Скорость сжатия в итоге - 809 Кб/с. Время тестирования с распаковкой в tempfile - 812.33 сек, без такой распаковки - 775 сек. Т.е. скорость около 10 Мб/с в обоих случаях.
srep07-l16kb - 4387.325 Мб
srep08-l16kb - 4360.438 Мб (17 Мб выигрыш - хотя это немного, основное преимущество 0.8 версии - скорость декомпрессии раза в 2.5 лучше)
srep07-l512 - 4042.495 Мб
srep07-l256 - 4023.032 Мб
srep07-l256+srep07-l256 - 3917.341 Мб
srep08-l256 - 3825.422 Мб (аж на 197.5 Мб лучше, чем 0.7!)
rep:256+srep07-l256 - 3823.758 Мб
srep07-l256+rep:256 - 3813.773 Мб
srep08-l256+srep08-l256 - 3812.676 Мб (уже только 104.7 Мб на фоне 0.7 - но вообще говоря, смысл второго прохода теряется - разница лишь)
rep:256+srep07-l256+rep:256 - 3752.557 Мб
srep08-l128 - 3735.102 Мб
rep:128+srep08-l128 - 3650.639 Mb
Вот такие пока результаты. Куда дальше лучше смотреть с этими 7.5 Гб данных - rep, lzma или ещё что? С 24-27 Гб данными подобного типа буду разбираться, как только с этими закончу. Тут же ещё с lzma надо будет дожимать... И, возможно, обычным rep'ом...
P.S. Да, а как в arc.ini правильно вставить srep внешним компрессором, чтобы можно было задавать параметр -l? |
так что если не будет работать, то вспоминай под какой ОС упаковал (xp/vista/linux). ну и разумеется избавься от этого архива, перепакуй или новой версией или с более высоким сжатием (ошибка была только в режиме -m1) 
). 