Последняя доступная версия:

http://www.overclockers.ru/softnews/33991.shtml

А как можно увеличить скорость распаковки/запаковки?
Он всегда показывает скорость около 15-20 мб/с. Проц при этом загружен на 10-15%. И с большим файлом надо ждать очень долго.

2 Serjius
для этого надо чтобы у архиватора были опции в командной строке либо в GUI позволяющие настраивать объём используемой оперативки при сжатии это позволит ускорить процесс. Помоему у 7-Zip этого нету.

Serjius
Кол-во потоков >1 ставить не пробовали?

LODblRb
А это разве не от размера словаря зависит? Эта настройка там есть, но она вроде бы же от качества сжатия зависит.

О как! Мне оказывается ответили! А я уже и ждать перестал и не заглядывал сюда. Но всё равно спасибо!

Пробовал, ни на что не влияет, причём для разных форматов. Тут уже что то изменилось, может новая версия так повлияла . Тестил разными файлами (но для удобства наблюдения брал большие - AVI и PDF), в основном наблюдается такая картина: скорость запаковки в формат .7z около 5 мб/с, распаковки 12-15. С форматом .zip работает быстрее, на тех же файлах запаковка около 15 мб/с, распаковка 30-40. Всё это в режиме "скоростной". Нагрузка на процессор составляет 50%.
При изменении режима на "нормальный", скорость падает немного (например с 5 до 3,5-4 мб/с), но загрузка процессора уже 100%.
Причём для этих ави-шек и пдф-ок размер архивного файла практически не отличается от оригинала по размеру. Но это понятно, там и так уже всё утрамбовано. Более рыхлые файлы типа текста после упаковки в .7z существенно компактнее, чем .zip. Например папка с сейвами от игры Готика-2 весит в распакованном виде 122мб, в .7z - 5,28мб, в .zip - 34,2мб. Запаковано всё в режиме "нормальный".

Когда уже научиться паковать в 4/8-емь потоков? Или это физически невозможно?

Serjius
Не за что, а вообще — на тему можно подписаться, и не заглядывать постоянно ;)
Попробовал у себя воспроизвести, не получилось, уже на самом быстром сжатии 200мб видео в 7z проц (sempron 3000+) загружен полностью, скорость ~1.6мб/с. То же самое, но с макс. сжатием дает ~1.1мб/с. В zip на макс. вообще < 500 кб/с, этого я что-то вообще не понял (версия 7-zip 9.04 beta). В общем, если у вас в 7z на максимальном дает 15-20 мб/с с загрузкой проца 10-15%, то это имхо радоваться надо :) Вообще, можно было бы еще провести эксперимент с пожатием чего-нибудь с рамдиска на него же, с обязательной многопоточностью, просто чтобы точно избавиться от влияния дисковой подсистемы, но нужно ли оно, это вопрос ;)
Насчет результативности — она может изменяться почти от нуля (видео, mp3, pdf) до бесконечности (текстовый файл из одного повторяющегося символа, например ;), это просто для уточнения.

Добавлено спустя 7 минут 25 секунд:
moty
Не просто возможно, а уже как бы и реализовано немного ;)

Нет, не даёт . 10-15% наблюдаются изредка и для маленьких файлов. Я ж говорю, что то изменилось, нагрузка на проц стала выше, может из-за обновлённой версии 7z (сейчас стоит 4.65, раньше была 4.57, если не ошибаюсь).
Вот сейчас провёл ещё один эксперимент, наверное более корректный - папку "system32" из другой винды (размер в проводнике 863мб) закатал в 7z с разными настройками. Итак, в режиме "скоростной", 2 потока получился файл 322 мб, при этом проц был загружен на 45-50%, процесс шёл 2мин. 17сек. В режиме "максимальный", 2 потока получился файл 212мб, проц был загружен на 90-95%, процесс шёл 5мин. 4сек.
Распаковал последний файл на другой диск - процесс шёл около 1 мин., скорость отображал около 15мб/с, проц был загружен на 20-40% (постоянно прыгала нагрузка).
З.Ы. система №1 из профиля, только проц работает на 3ГГц.

9.04 beta в руки с алгоритмом LZMA2.

Опаньки, а он шустрый, выпустил, а я даже и не заметил...

Вот результаты мини-тестирования, которые я провёл: ( исошка deusEX 722 мегабайта)
словарь 16 МБ Слово 32 Блок - 2 гигабайта. 7zip 9.05 alpha x64
7zip lzma1
3:04 min
589 mb
7zip lzma2
1:50 min
598 mb
2 и 4 потока соотв.
Неплохо, неплохо.

Винрар 9.50 бэта 5 - х64
2.59 минут
файл размером 604 мб
Растёт убиццо винрара

Чет потестил что lzma что lzma2 -скорость одинаковая.
Жал 100-метровую авишку и так и так 24 сек.

Количество потоков изменять пробывал? Версия архиватора - 9.05 альфа? При выборе пресетов ( там где быстрый, нормальный, ультра и т.п.) алгоритм сжатия сбрасывается на lzma1. Это баг, судя по всему.



жмите реальный контент, а не уже сжатые данные.

Хотя только что пожал авишку на 300 мб - 49 секунд вместо минуты и 5 секунд.

moty
cure72
давно уже протестировано: ищите мой пост с тестированием LZMA2: viewtopic.php?f=8&t=75175&start=180

moty
Прогнал на папке с фото -200мб,Версия архиватора - 9.05 альфа,потоков 2,пресет нормальный
Итог LZMA 45 секунд ,LZMA2 49 секунд.
Я не ошибся LZMA2 у меня выходит медленнее.В один поток жать смысла не вижу .

ааа.... собсно, чего вы хотели? Если вы не поняли - больше 2х потоков под лзма1 нету.

учитывая, что часто приходится давать архивы другим, есть ли смысл паковать нераспространенным среди обычных юзеров, архиватором?

Всегда можно сделать самораспаковывающийся ехешник.

рассвет распространенный среди обычных юзеров WinRAR открывает 7z архивы (пока кроме метода LZMA2)

moty
Я не понял в чем фишка LZMA2 если он медленней LZMA

cure72 фишка в поддержке более 2х ядер при сжатии.
еще раз - смотрите мой пост на этой странице: viewtopic.php?f=8&t=75175&start=180
в каком месте он медленнее?
может в 2 ядра и медленнее, на в 2+ уже совсем без вариантов (см. выше.)

updated: сейчас на работе на E8500 (без разгона) проверил в 2 ядра LZMA и LZMA2 (папка 118Мб - Pagemaker7 файлы .pmd)
одинаково сжималось 25 секунд.
LZMA - 4,22 МБ (4 431 713 байт)
LZMA2 - 4,22 МБ (4 431 440 байт)

Только что протестил 9.06 beta
Сжимал аудиотреки во флаке.
Исходный размер 276 МБ
LZMA2 сжал за 1 мин 0 сек 01 мсек - 279 МБ
LZMA сжал за 0 мин 59 сек 34 мсек - 279 МБ
С учетом погрешности измерений, результаты идентичны.
В первом случае нагрузка равномерно распределялась на 4 ядра с общей загрузкой ЦП ~ 45%
Во втором грузились 2 ядра, но каждое примерно на 80%, загрузка системы была идентичной, порядка 45%

Таким образом преимущество получает LZMA, как более эффективный алгоритм на данный момент.