Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Программы » WinRAR (часть 5)

Модерирует : gyra, Maz

 Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93

Открыть новую тему     Написать ответ в эту тему

Maz



Дед Мазай
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
По вопросам лечения (кряки, патчи и т.д.), а также разблокировки архивов, обращаемся в «Варезник».
Отдельная тема по сборкам WinRAR
Предыдущие части темы: 1 | 2 | 3 | 4



 
Официальный русский сайт: win-rar.com
Официальный e-mail разработчика WinRAR (писать по-русски): dev@rarlab.com
 
Стабильная английская версия: 7.00 x86 | x64 (28 февраля 2024 г.)
Стабильная русская версия:  7.00 x86 | x64 (28 февраля 2024 г.)

Текущая английская бета-версия: 7.01 beta 1 x86 | x64
Текущая русская бета-версия:  7.01 beta 1 x86 | x64
Примечание: английская бета-версия обновляется регулярно, без изменения номера версии. подробнее...
Список изменений на английском языке
(на родном – смотрите файл WhatsNew.txt в дистрибутиве на вашем языке)
Скачать RAR для macOS, FreeBSD, Linux, Android можно здесь.

Скачать ранее вышедшие версии можно с официального FTP
Таблица совместимости версий с различными ОС

Версия 3.62 (ru) с подарочным ключом (респект камраду elmorte)

Коллекционный архив версий WinRAR 1.54b - 7.00 (1995-2024): скачать (336.4 МБ) [обновлено 28.02.2024]

вместо F.A.Q. || альтернативные архиваторы

Почему задерживается русская версия? А при русском разработчике на языке XXX уже давно есть. Не захламляйте тему подобными вопросами.

Кому не нравится новая тема оформления - скачайте с официального сайта rarlab.com (из раздела Themes) и установите себе WinRAR Classic theme by Francesco Indrio
Стандартная (48x36). Маленькие кнопки (24x24)

В теме активно отвечает на вопросы автор архиватора Евгений Рошал! Ситуация уникальная, прошу пользоваться. :)
 
Таблицы для наглядности с соотношением размера словаря к потребляемой ОЗУ:
с ключом mcx | без ключа mcx

Всего записей: 38852 | Зарегистр. 26-02-2002 | Отправлено: 08:31 31-07-2023 | Исправлено: DimmY, 00:57 26-04-2024
BorlandIMHO

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
insorg

Цитата:
как их сейчас 7-zip переваривает?

Нормально переваривает. Очевидно же, что для работы с rar программа использует оригинальный код от Евгения. И так же очевидно, что поддержка rar со словарями "4+" появится в 7-zip в ближайшее время...

----------
http://www.imho.ws

Всего записей: 2405 | Зарегистр. 12-10-2006 | Отправлено: 07:59 01-12-2023
uShell

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
BorlandIMHO

Цитата:
Формат архива rar5 (а не просимый rar7).

Формат Rar7 - это контейнер Rar5 и метод сжатия 1. Он используется при словарях больше 4 ГБ. При словарях до 4 ГБ, как я понимаю, метод всегда будет 0 - такой же, как в Rar5 (если я не прав, пусть EugeneRoshal поправит). Соответственно, и 7-Zip разницы не увидит. Можно, конечно, от руки выставить 1, но я счёл это излишним.
 

Цитата:
Архивация со словарём, размер которого больше размера упаковываемых данных - редкостное извращение...

Не факт. Если у меня 1.1 ГБ данных и словарь 2 ГБ даёт выигрыш по сравнению с 1 ГБ - почему бы и нет? Другое дело, что выигрыш может быть в пару байт - тогда да, на грани извращения.

Всего записей: 1020 | Зарегистр. 12-06-2019 | Отправлено: 14:33 01-12-2023
Benchmark



Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
uShell

Цитата:
Не факт. Если у меня 1.1 ГБ данных и словарь 2 ГБ даёт выигрыш по сравнению с 1 ГБ - почему бы и нет?

 
Тут чем больше объём данных, тем больше может быть выигрыш. Скажем, файл размером 63.9Gb с большой вероятностью будет сжат лучше со словарём в 64Gb, чем с 32Gb.  В принципе очень удобно, когда весь объём сжимаемых данных умещается в словаре.

Всего записей: 6835 | Зарегистр. 01-10-2002 | Отправлено: 14:56 01-12-2023 | Исправлено: Benchmark, 14:57 01-12-2023
EugeneRoshal

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
BorlandIMHO

Цитата:
Результат:
rar5: длительность 1457.82s, итоговый размер 7088184805 байт (92%)
rar6: длительность 1548.76s, итоговый размер 7088185155 байт (92%)
rar7: длительность 835.79s, итоговый размер 7123246479 байт (92%)

На 12900K у меня с похожим файлом и аналогичными параметрами получилось:
rar5: 426s, 7356 MB
rar6: 430s, 7356 MB
rar7: 188s, 7393 MB
rar7 -mcl-: 387s, 7356 MB
 
То есть если отключить long range search, сжатие равно предыдущим версиям. Но по мне, выигрыш в скорости в 2.3 раза ценнее, чем 0.5% сжатия. Причем такое поведение характерно для уже пожатых данных. На данных с высокой избыточностью long range search часто улучшает и сжатие.

Всего записей: 2268 | Зарегистр. 29-04-2013 | Отправлено: 18:28 01-12-2023
insorg



Platinum Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
BorlandIMHO
Цитата:
Очевидно же
Оно-то многое "очевидно" и предсказуемо. Но сейчас у меня нет возможности проверить это на практике. Потому и спрашиваю...
 
Добавлено:
EugeneRoshal
Цитата:
аналогичными параметрами получилось
Я верно понимаю, что в 7 версии алгоритм упаковки "по умолчаню" упрощён? Т.е. для получения "былой силы" (в конкретном случае, временем можно пренебречь) нужно этот самый long range search включать "обратно"?

Всего записей: 16889 | Зарегистр. 04-11-2010 | Отправлено: 20:04 01-12-2023
BorlandIMHO

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Benchmark

Цитата:
файл размером 63.9Gb с большой вероятностью будет сжат лучше со словарём в 64Gb, чем с 32Gb

Вот про такое очень хотелось бы услышать комментарий Евгения...
И да, если уж речь зашла о НАСТОЛЬКО больших словарях - вспомните ещё и о ресурсах, потребных на упаковку/распаковку.
Хотя натурный эксперимент с файлом "en_windows_10_consumer_editions_version_1909_x86_dvd_10bde8bb.iso" вашу правоту подтверждает:

Исправляю.
 
uShell

Цитата:
Формат Rar7 - это контейнер Rar5 и метод сжатия 1

Формат rar7 использует метод сжатия, неизвестный более ранним версиям rar. То, что он используется исключительно с большИми словарями {думаю, что на маленьких он просто проигрывает rar5, хотя точно может сказать только автор} - не говорит, что "это тот же rar5".

----------
http://www.imho.ws

Всего записей: 2405 | Зарегистр. 12-10-2006 | Отправлено: 20:19 01-12-2023
uShell

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
для получения "былой силы" (в конкретном случае, временем можно пренебречь) нужно этот самый long range search включать "обратно"?

Наоборот - выключать. По умолчанию он "частично" включён, т.е. архиватор включает его в те моменты, когда сочтёт выгодным. На некоторых файлах это приводит к ухудшению сжатия. С другой стороны, -mcx (который, как заявлено в документации, заодно включает long range search) сжатие часто улучшает.
 

Цитата:
То, что он используется исключительно с большИми словарями {думаю, что на маленьких он просто проигрывает rar5, хотя точно может сказать только автор} - не говорит, что "это тот же rar5".

Хорошее уточнение. Но раз он офииально "зарублен" для небольших словарей - на то были причины и можно на это закладываться.

Всего записей: 1020 | Зарегистр. 12-06-2019 | Отправлено: 20:29 01-12-2023
insorg



Platinum Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
архиватор включает его в те моменты, когда сочтёт выгодным. На некоторых файлах это приводит к ухудшению сжатия
Что-то я не понял теперь ничего. Для лучшего сжатия таки что нужно - чтоб но был вкл -mcl+ или выкл -mcl- ?
Ведь, своим названием он как б про улучшение, а не наоборот...  
 
Добавлено:

Цитата:
-mcx  
Как-то считал, что одновременное применение -mcd -mce -mcl -mcx даст самое лучшее сжатие. Получается, я не так понял и нужно брать -mcd -mce -mcl- -mcx?
 
Добавлено:
Ведь, раньше по такой логике было - чем больше включено, тем лучше жмёт. А теперь логика нарушается, если так...

Всего записей: 16889 | Зарегистр. 04-11-2010 | Отправлено: 20:56 01-12-2023
Inoz2000



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Вот про такое очень хотелось бы услышать комментарий Евгения...

я, каэш, прошу прощения за свой комментарий заместо Евгения
Так вот.. Большие словари имеют заметный выигрыш при наличии повторяющихся данных, которых никто не обещал в предлагаемых Benchmark 63.9Gb .
Хотя нельзя не согласиться с утверждением

Цитата:
файл размером 63.9Gb с большой вероятностью будет сжат лучше со словарём в 64Gb, чем с 32Gb

но может быть иной вариант. При отсутствии самого главного - повторяющихся данных - выигрыша может не быыыыыыыть! — зарубите себе на носу, обладатели биг даты.
Моё имхо заключается в следующем: не стоит, ребяты, рассчитывать на «ух-ты» и на вау-эффект при большущих ваших объёмах памяти и этих словарях.
Если нет реально повторяющихся данных, в наличие которых вы реально уверены, то есть вероятность, что большой словарь не совершит ожидаемого волшебства.
Другое дело скорость.
Вот довольно обнадёживающая цитата

Цитата:
выигрыш в скорости в 2.3 раза ценнее

 
Спасибо, EugeneRoshal

Всего записей: 4920 | Зарегистр. 23-04-2009 | Отправлено: 21:24 01-12-2023
uShell

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Ведь, своим названием он как б про улучшение, а не наоборот...

Поиск на длинных дистанциях реализован более быстро и менее тщательно, чем на коротких, поэтому если на больших расстояниях повторов мало - сжатие с ключом -mcl ухудшается. Ключ -mcx принудительно выставляет -mcl+, и за счёт более тщательного поиска улучшает сжатие ценой времени. -mcd и -mce обычно включаются автоматически в старших режимах сжатия (-m5, например); сжатие обычно не ухудшают, но в моих экспериментах и не улучшают (кроме принудительных -mce+ и -mcNd+ на нужных файлах и с правильно подобранным N).
 

Цитата:
При отсутствии самого главного - повторяющихся данных - выигрыша может не быыыыыыыть!

Кстати, да. WinRAR использует какую-то разновидность метода Лемпеля-Зива, который сжимает в основном за счёт замены повторяющихся последовательностей короткими ссылками на предыдущий экземпляр. Дамп Википедии или образ диска с "обычными" файлами будут сжаты хорошо, тогда как подборка фотографий или фильм - весьма слабо. А оптимизация по скорости будет хороша для пользователей, которые не знают, насколько сжимаемы их данные. Кто знает, скорее включит для "плохих" данных -m1 или вообще -m0.

Всего записей: 1020 | Зарегистр. 12-06-2019 | Отправлено: 21:48 01-12-2023
EugeneRoshal

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
insorg

Цитата:
Я верно понимаю, что в 7 версии алгоритм упаковки "по умолчаню" упрощён?

Алгоритм поиска совпадений усложнен.

Цитата:
Т.е. для получения "былой силы" (в конкретном случае, временем можно пренебречь) нужно этот самый long range search включать "обратно"?

На объемных данных с избыточностью LRS обычно дает выигрыш в сжатии.
 
BorlandIMHO

Цитата:
Вот про такое очень хотелось бы услышать комментарий Евгения...

64 гб словарь на 64 гб данных, в отличие от 32 гб словаря, может видеть повторы на дистанциях больше 32 гб. При наличии таких повторов это может привести к росту сжатия.
 
uShell

Цитата:
На некоторых файлах это приводит к ухудшению сжатия.

Как правило, на уже пожатых. К незначительному, в доли процента.
 
Inoz2000

Цитата:
я, каэш, прошу прощения за свой комментарий заместо Евгения

Всё правильно написали

Всего записей: 2268 | Зарегистр. 29-04-2013 | Отправлено: 22:11 01-12-2023
vasevase

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
BorlandIMHO , insorg

Цитата:
А зачем такое вообще делать?
Переадресую вопрос uShell и vasevase...  

Внимательно читать же надо: я просил словарь 2ГБ
для экспериментов, а не практического "складирования"
полезного содержимого. Были заявления, что на x86 словарь 2ГБ
нечитаем/бесполезен (RAR7 вообще). Эмпирическим путём установлено,
что это не так. Сегодня ещё консольную версию "добил" -
- тоже и тестирует успешно 2ГБ-словарный архив и пакует
с новыми параметрами текстовую Wiki, выделяя так же ~2.5 ГБ ОЗУ
[256m словарь, x86 NT5x, без подкачки]. Интересно ещё было бы на Vista/7
то же самое проверить [распаковку на x86 / LAA / Rar7 с 2ГБ-словарём],
но я ими и не столь активно пользуюсь [практически не пользуюсь], и лень уже.

Цитата:
BorlandIMHO: С ним, думаю, и 5-й Winrar распакует...

С высокой долей вероятности - нет [см. статью на пред. странице].
Без ключей загрузки там выделяется максимум 2ГБ,
разбитых "мусорными" DLL-ками. У меня не получается ~1500МБ словарный 7z
распечатать на x86 без "оптимизации" этого безобразия ["Not enough memory"].
 
EugeneRoshal
А вы LAA намеренно не ставите, и не планируете ли в будущем?

Всего записей: 3180 | Зарегистр. 28-08-2010 | Отправлено: 23:09 01-12-2023 | Исправлено: vasevase, 23:38 01-12-2023
EugeneRoshal

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
vasevase
32-битная версия уже уходит со сцены. Вносить в нее такое изменение это рисковать добавить какую-нибудь сложную в обнаружении ошибку, которая всплывет только после релиза. Лет 10 назад это еще, может, имело бы смысл.

Всего записей: 2268 | Зарегистр. 29-04-2013 | Отправлено: 23:30 01-12-2023
GoblinNN

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal
посмотрите плиз на лог конвертации. зачем пишет два раза про извлечение?

Всего записей: 2908 | Зарегистр. 11-10-2005 | Отправлено: 00:01 02-12-2023
EugeneRoshal

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
GoblinNN
Да, одно лишнее. Я перевыложил английскую и русскую беты без этого дублирования.

Всего записей: 2268 | Зарегистр. 29-04-2013 | Отправлено: 00:38 02-12-2023
vasevase

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
В продолжение темы экспериментов Rar7 на x86.
Решил всё же "финализировать" тесты на Win7.
И вот, что имею доложить: разумеется, в "базовом" виде,
как и ожидалось, при распаковке словаря в 2ГБ, (выложенный
уважаемым uShell архив
) - получаем "недостаточно памяти".
 
По аналогии со старыми NT5x нужно вставить в загрузку:
bcdedit /set IncreaseUserVa 3072
 
Перезагружаемся, консольный RAR [ВНЕЗАПНО!] 3 ГБ видит.
Т.е. LAA флага нет именно у WinRar.exe {гуевая дискриминация}.
После добавления флага, и WinRar тоже проходит тест успешно,
отъедая ~ 2100944 байт. Да, и к тому, что выше писал: на NT6.1,
вроде, не наблюдается такой "замусоренности" DLL-ками.
Т.е. патчить базовые адреса не пришлось. Тестом доволен.  

Всего записей: 3180 | Зарегистр. 28-08-2010 | Отправлено: 22:48 02-12-2023 | Исправлено: vasevase, 22:52 02-12-2023
Benchmark



Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
По аналогии со старыми NT5x нужно вставить в загрузку:
bcdedit /set IncreaseUserVa 3072
 
Перезагружаемся, консольный RAR [ВНЕЗАПНО!] 3 ГБ видит

Есть прекрасная тема насчёт этого трюка:
https://superuser.com/questions/253132/what-are-the-dangers-of-manually-setting-increaseuserva
 
Вкратце: сгодится тем, для кого эксперимент - образ жизни. Для остальных чревато неожиданными последствиями даже там, где и не подумал бы.

Всего записей: 6835 | Зарегистр. 01-10-2002 | Отправлено: 23:34 02-12-2023
vasevase

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Нарыл так нарыл! 12-летней давности всхрюк
на аналоге "мейлрушных" вопрос-ответ, где сидят
и друг-дружку троллят разнообразные клоуны.    
 
Остальные, как тут заявляли, успешные x64-ки, так что не отвлекайтесь,
мы со своими багами {реальными, а не гипотетическими} сами разберёмся.

Всего записей: 3180 | Зарегистр. 28-08-2010 | Отправлено: 23:54 02-12-2023
Benchmark



Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
12-летней давности

*пожимая плечами*
 
С тех пор в 32-битном мире ничего не изменилось. И уже не изменится.

Всего записей: 6835 | Зарегистр. 01-10-2002 | Отправлено: 00:12 03-12-2023
insorg



Platinum Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Benchmark
"Вкратце", ничем не отличается от "багов" при работе с физическим 1 ГБ памяти на всё про всё. Остальное "проблемное" - кривой софт и глюкавые драйверы, которые мало кто тестировал, если они таковыми оказались.  В реальной жизни такую проблему ещё поди найди.
С другой стороны, реально больше смысла имеет тогда уж брать либо х64 ось, либо ставить серверную версию - там такие танцы с бубном не нужны.
 
 
Добавлено:
Хотя, тут уже и так натягивание совы на глобус - и 32-битные ОС, и WinRAR с требованием Win7  и хотелки в большой словарь... При этом не припомню ни единой железки, которая работала бы только на 32-битной висте/семёрке и не имела дров для её х64 версии. А коль так, то и нет смысла держаться за 32-битную ОСьку, если можно спокойно вкатить х64 и не парить мозг этими всеми патчами вовсе...
 
Добавлено:
Всяческие страдания ХР-водов, которые после установки OneCoreAPI всё так же по сей день могут запускать WinRAR 7 версии, оставим в стороне. Таких отчаянных экспериментаторов крайне мало, да и те должны понимать всю ненадёжность такого решения. Посему как раз под категорию "эксперимент - образ жизни" это всё и остаётся...
 
Добавлено:
vasevase
Цитата:
выделяя так же ~2.5 ГБ ОЗУ
[256m словарь, x86 NT5x, без подкачки].  
У меня в своё время старый добрый (тогда ещё бурно развивающийся) FreeARC консольной версии на ХР с 4 ГБ набортной оперативки (правда, уже не помню точно, после переезда на ХРх64 или до) при максимально возможном сжатии словарём в 256 МБ (на самом деле 254, но это уже мелочи) жрал что-то около 2,7 ГБ памяти на упаковке. Уже тогда было понятно, что 32-битные архиваторы упёрлись в тупик в этом плане и пора переходить на х64 для "биг даты".

Всего записей: 16889 | Зарегистр. 04-11-2010 | Отправлено: 00:16 03-12-2023
Открыть новую тему     Написать ответ в эту тему

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93

Компьютерный форум Ru.Board » Компьютеры » Программы » WinRAR (часть 5)


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru