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

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

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

Maz (27-08-2020 19:31): WinRAR (часть 4)  Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 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 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199

   

gyra

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



Официальный русский сайт: win-rar.ru
Официальный e-mail разработчика WinRAR (писать на русском): dev@rarlab.com
 
Финальная английская версия: 5.91 x86 | x64 (29.06.2020)
Финальная русская версия:  5.91 x86 | x64 (29.06.2020)
 
Список изменений на английском языке
(на родном – смотрите файл WhatsNew.txt в дистрибутиве на вашем языке)
Скачать RAR для macOS, FreeBSD, Linux, Android можно здесь.

 
Скачать ранее вышедшие версии также можно с официального сайта.

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

Коллекция всех ранее выходивших версий WinRAR (1995-2020): скачать (253 МБ) [обновлено 30.03.2020]

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

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

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

В теме активно отвечает на вопросы автор архиватора Евгений Рошал! Ситуация уникальная, прошу пользоваться. :)

Всего записей: 7932 | Зарегистр. 18-02-2006 | Отправлено: 12:00 14-12-2016 | Исправлено: Domin0, 13:37 26-08-2020
EugeneRoshal

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

Цитата:
Скажите, а  почему не уделяется внимания архивации с быстрым сжатием

В RAR есть отдельная ветка кода для -m1, и там уделено внимание скорости. Но там  используется тот же формат сжатия, что и для остальных методов, просто с параметрами, ориентированными на скорость. Где-то 100 - 150 мб в секунду на больших файлах у меня получается, и я посчитал, что для практических применений этого достаточно. Чтобы получить больше, нужно или сильнее убавить сжатие, или вместо стандартного RAR'овского использовать другой алгоритм, создававшийся именно для скоростного сжатия. Дополнительный алгоритм это и потеря совместимости, и усложнение исходников, а, значит, выше вероятность ошибок, и больше размер SFX модулей. С учетом наличия zip и -m0 особой нужды в этом я сейчас не вижу.

Цитата:
кучу мелких файлов записать на флешку/отправить по почте.


Цитата:
Rar.exe a -m1 xxx.rar

Попробуйте добавить ключ -s. При сжатии набора мелких файлов он будет к месту.
 
Вообще при сжатии небольшого количества мелких файлов на время выполнения скорее будет влиять не скорость основного алгоритма, а время инициализации структур данных (то же выделение памяти) и реализация работы с пакуемыми файлами.

Всего записей: 2388 | Зарегистр. 29-04-2013 | Отправлено: 19:45 03-11-2017
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
стандартный быстрый алгоритм сейчас zstd, который во всём превосходит tornado
 
rar мог бы просто пускать алгоритм -m1 на пуле потоков, если в его формате возможна сшивка независимо сжатых буферов. или можно делать это на deflate, как например в pigz. есть и просто быстрые реализации deflate - это популярная тема
 
по RS - посмотрите https://github.com/catid/leopard#benchmarks - думаю гигабайта/сек при 8192 блоков вам хватит (в rar для сравнения - 200-300 блоков)
 
насчёт RR в отдельных файлах - всё что нужно, это вынести нынешнюю RR в отдельные файолы, разрешив как угодно разбивать её. и может немного дополнить формат чтобы восстанавливать в большем числе случаев. тогда rar будет брать архив плюс те RR файлы, которые ему предоставили, определять что у нас в наличии и реконструировать потерянное

Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 15:34 06-11-2017 | Исправлено: Bulat_Ziganshin, 15:35 06-11-2017
Pasha_ZZZ



Platinum Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Bulat_Ziganshin
Цитата:
вынести нынешнюю RR в отдельные файолы, разрешив как угодно разбивать её
Я это и предлагал. Плюс чтобы RR была общая на все тома (возможно опционально), а не на каждый том отдельная.

Всего записей: 12816 | Зарегистр. 11-03-2002 | Отправлено: 15:37 06-11-2017
d3adb33f



Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal
А почему бы не добавить алгоритм сжатия Brotli ?
Он текста жмёт круче всего что я видел.

Всего записей: 564 | Зарегистр. 08-10-2015 | Отправлено: 16:33 06-11-2017
Benchmark



Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
d3adb33f
Чуть выше Евгений уже ответил:

Цитата:
Дополнительный алгоритм это и потеря совместимости, и усложнение исходников, а, значит, выше вероятность ошибок, и больше размер SFX модулей. С учетом наличия zip и -m0 особой нужды в этом я сейчас не вижу

 
В любом случае, если и менять что-то в плане алгоритмов без оглядки на обратную совместимость, то это есть смысл делать только в новой линейке версий, скажем 6.x. Заодно там же и с поддержкой устаревших ОС попрощаться.

Всего записей: 6923 | Зарегистр. 01-10-2002 | Отправлено: 16:43 06-11-2017
EugeneRoshal

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

Цитата:
rar мог бы просто пускать алгоритм -m1 на пуле потоков, если в его формате возможна сшивка независимо сжатых буферов. или можно делать это на deflate, как например в pigz. есть и просто быстрые реализации deflate - это популярная тема

Если буферы совсем независимые, может пострадать сжатие. Можно в каждом следующем буфере заглядывать в конец предыдущего, но это решение для небольших словарей. Впрочем, я -m1 занимался не слишком долго и посчитал, что для практического применения его скорости достаточно. Может когда вернусь к нему опять.

Цитата:
насчёт RR в отдельных файлах - всё что нужно, это вынести нынешнюю RR в отдельные файолы, разрешив как угодно разбивать её.

Тут это недавно обсуждалось. Причем, если это реализовать, тогда элементарно расширить функциональность на защиту любых файлов, не только архивов. Но пока меня останавливает тот факт, что QuickPar, MultiPar и им подобные так и не получили заметной популярности. Казалось бы, защита бэкапов, защита ценных данных, на каждом втором компьютере должны стоять. Но нет. Похоже сейчас это уже мало востребовано.
 
Добавлено:
d3adb33f

Цитата:
А почему бы не добавить алгоритм сжатия Brotli ?  

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

Всего записей: 2388 | Зарегистр. 29-04-2013 | Отправлено: 18:10 06-11-2017
Inoz2000



Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin
Цитата:
стандартный быстрый алгоритм сейчас zstd, который во всём превосходит tornado  
да, это правда известный факт. время идёт только вперёд.
В WinRar нету других алгоритмов (кроме Deflate) и единственный RAR5 не может обладать такой невероятной шириной достоинств, как от него хотят неравнодушные пользователи:
ndch

Цитата:
Скажите, а  почему не уделяется внимания архивации с быстрым сжатием
… а тут, только успевай! вот на двух листах один за одним - tornado, zstd и даже Brotli! Так уж совпало, что новых алгоритмов всем очень надо и не два и не три.
 
Если бы в WinRar исторически образовался какой-либо ассортимент алгоритмов сжатия, то неудивительно бы сейчас видеть подобные просьбы:
  — Почему вам бы не прикрутить ещё один к имеющемуся разнообразию...  
  — Сделайте, чтобы сжимало сильно, но быстро разархивировало на слабых машинах
  — Запилите пож-ста поддержку сжатия brotli, ощень надо. (автор недавно выключил алгоритм сжатия текста, а тут опять!)


----------
Мы все умрём. (-:

Всего записей: 5246 | Зарегистр. 23-04-2009 | Отправлено: 00:04 07-11-2017
GoblinNN

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
а почему нельзя в rar ну или хотя бы winrar добавлять новые алгоритмы в виде плагинов? даже можно дальше развить... в виде открытого API и пусть народ сам себе пилит плагины. темы/иконки делает? вот пусть и функционал добавляет. правда не понятно как все это с лицензированием будет совмещаться архиватор то платный... зато возможно появятся "tornado, zstd и даже Brotli!"

Всего записей: 2912 | Зарегистр. 11-10-2005 | Отправлено: 02:44 07-11-2017
Pasha_ZZZ



Platinum Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
GoblinNN
Цитата:
а почему нельзя в rar ну или хотя бы winrar добавлять новые алгоритмы в виде плагинов?
Потому что пострадает переносимость архивов. Надо будет сей плагин иметь и при распаковке, в том числе на разных ОС.
Нераспаковываемость архивов - это, скорей, фича Фриарк...

Всего записей: 12816 | Зарегистр. 11-03-2002 | Отправлено: 04:23 07-11-2017
Victor_VG



Tracker Mod
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
GoblinNN
 
Так же как и в любой коммерческой ОС семейства UNIX - их лицензия не запрещает использовать ПО других разработчиков даже в ядре ОС, но всю ответственность за возникшие проблемы несут их виновники, а разработчик ОС устраняет подобные  проблемы за деньги виновника их возникновения.
 
Правда лично я не вижу технического смысла в решении плодить зоопарк форматов и алгоритмов - это уже было в период UNIX войн 70-х, и кончилось общим мнением "Зоопарк вредит здоровью!", но смотрю сегодня эти старые грабли снова в боевом строю. Ну, каждому поколению персональные грабли.

----------
Жив курилка! (Р. Ролан, "Кола Брюньон")
Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti

Всего записей: 34389 | Зарегистр. 31-07-2002 | Отправлено: 04:30 07-11-2017 | Исправлено: Victor_VG, 04:36 07-11-2017
ndch

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

Цитата:
Значит нежелательно часто вводить новые алгоритмы. Каждые несколько лет, на мой взгляд, это часто.
Речь была про последние 20 лет.
20 лет это rar2, это начало зоопарка, это новые требования к железу (озу в первую очередь).
 

Цитата:
С учетом наличия zip и -m0 особой нужды в этом я сейчас не вижу.  

Не сейчас, последние 20 лет.
 
Знаете почему не писал ранее ? Я видел ответы от вас.
 
Предыдущий пост мой это не претензия, не "вишес", а информация (возможно к размышлению).

Всего записей: 7008 | Зарегистр. 31-08-2008 | Отправлено: 08:42 07-11-2017 | Исправлено: ndch, 08:55 07-11-2017
EugeneRoshal

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

Цитата:

Цитата:
Значит нежелательно часто вводить новые алгоритмы. Каждые несколько лет, на мой взгляд, это часто.

Речь была про последние 20 лет.

В цитируемом выше тексте я отвечал про Brotli. 20 лет назад zstd и Brotli не было. И 10 лет назад не было. И 3 года назад не было. Я выбирал из того, что было доступно на момент разработки, с учетом технических параметров, лицензионных и патентных ограничений.
 
Тем временем Google пытается запатентовать ANS кодер, существенную часть zstd:
https://www.bleepingcomputer.com/news/google/google-accused-of-trying-to-patent-public-domain-technology/

Всего записей: 2388 | Зарегистр. 29-04-2013 | Отправлено: 09:20 07-11-2017
ndch

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

Цитата:
Ну а таблицу чуток повыше посмотреть? Там есть время. И г/бзип никогда медленными не были

До какого-то времени не были.
 
system.ext4.img - 1280 М
 
zstd -3 ... 611 М ... 6 sec
arc a -m=xtor:3 ... 627 М ... 7 sec
rar a -m1 ... 601 М ... 18 sec
pkzipc14 -add -lev=3 ... 616 М ... 23 sec
rar a -m0 ... 1280 М...  30 sec
PKZIP2_5 -add -lev=3 ... 617 М ... 33 sec
gzip  -1 ... 627 М ... 55 sec
bzip2 -1 ... 619 М ... 110 sec
 
Вот только с какого по какое время - не знаю.
Время тут тоже было... потрачено.
 
i3-3220, 6 Гб, hdd
 
Добавлено:
Pasha_ZZZ

Цитата:
Быстрому сжатию не "не уделяется внимания", просто ему уже давно внимание уделено, многие комбинации режим + словарь упираются в ограничения чтения/записи на винт, а на флешку и подавно.

Научите ! С учётом вышеприведённой информации.
 
EugeneRoshal

Цитата:
Где-то 100 - 150 мб в секунду на больших файлах у меня получается, и я посчитал, что для практических применений этого достаточно.

У меня не получается: 1280/18 ~ 72. Не могли бы подсказать почему ? Приблизительно...
150 мб в секунду - скорость на запись у  2,5" hdd за 50$. Не знаю для кого как, но по мне - не дорогое, но и не самое дешёвое, железо. Быстрый 2,5" винт, если не лукавить.

Всего записей: 7008 | Зарегистр. 31-08-2008 | Отправлено: 11:52 07-11-2017 | Исправлено: ndch, 12:25 07-11-2017
EugeneRoshal

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

Цитата:
У меня не получается:

Железо, тип данных. Я проверял с rar.exe x64 на i7-6700K при чтении из дискового кэша. На пожатом avi примерно 100 мб/с, на тексте - 160 мб/с.

Цитата:
rar a -m0 ... 1280 М...  30 sec

Странно, настолько медленный диск? -m0 при чтении из кэша у меня дает больше гигабайта в секунду.

Всего записей: 2388 | Зарегистр. 29-04-2013 | Отправлено: 12:28 07-11-2017
Victor_VG



Tracker Mod
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
ndch
EugeneRoshal
 
Так у HDD высокая скорость обмена по интерфейсу из кэша, а ZBTR - скорость обмена "головка - пластина" зависит от скорости вращения и плотности записи на дорожку, при этом сами данные используют примерно 2/3 ZBTR, остальное служебные данные контроллера. Иначе никак. И смотреть надо по ZBTR, не по скорости кэша. Иначе картинка меняется в сторону 100% ошибки измерений.

----------
Жив курилка! (Р. Ролан, "Кола Брюньон")
Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti

Всего записей: 34389 | Зарегистр. 31-07-2002 | Отправлено: 12:34 07-11-2017 | Исправлено: Victor_VG, 13:06 07-11-2017
ndch

Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Victor_VG
Требуется забекапить данные, записать на hdd, сжать.
Как следует правильно назвать последнюю составляющую процедуры, чтобы угодить Victor_VG и у него не было придирок ?
 
Влияние виндового дискового кеша присутствует, я этого не отрицаю. То же касается и фрагментации фс, свободного места на ней  и т.д. и т.п.
НО! В общем и целом сходимость результатов не нулевая.
 
EugeneRoshal
Цитата:
-m0 при чтении из кэша у меня

ndch
Цитата:
i3-3220, 6 Гб, hdd

Всего записей: 7008 | Зарегистр. 31-08-2008 | Отправлено: 12:39 07-11-2017 | Исправлено: ndch, 12:46 07-11-2017
Pasha_ZZZ



Platinum Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
ndch
Не нравится RAR-формат - юзайте другие. ZStandard, LZ4 показывают высокие результаты по скорости. Brotli, LZ5 и Lizard - медленнее, но жмут сильнее.

Всего записей: 12816 | Зарегистр. 11-03-2002 | Отправлено: 12:43 07-11-2017
ndch

Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Pasha_ZZZ
Послушайте, не я заявлял:

Цитата:
Быстрому сжатию не "не уделяется внимания", просто ему уже давно внимание уделено, многие комбинации режим + словарь упираются в ограничения чтения/записи на винт, а на флешку и подавно.  

 
Вы просто так кнопки нажимаете или как ?
 
При этом:
zstd -3 ... 611 М ... 6 sec
arc a -m=xtor:3 ... 627 М ... 7 sec
rar a -m1 ... 601 М ... 18 sec
 
Более того: "Странно, настолько медленный диск"
 

Цитата:
Юзайте другие.
... медленнее, но жмут сильнее.

Да не нужно мне медленнее. Ровно наоборот !

Всего записей: 7008 | Зарегистр. 31-08-2008 | Отправлено: 12:44 07-11-2017 | Исправлено: ndch, 12:50 07-11-2017
Pasha_ZZZ



Platinum Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
ndch
-m0 - фактически копирование. 1280/30=42МБ/с ваша скорость, зачем вам выше. zip легко будет быстрее.

Всего записей: 12816 | Зарегистр. 11-03-2002 | Отправлено: 12:50 07-11-2017
ndch

Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Pasha_ZZZ
 
zstd -3 ... 611 М ... 6 sec
arc a -m=xtor:3 ... 627 М ... 7 sec
rar a -m1 ... 601 М ... 18 sec
pkzipc14 -add -lev=3 ... 616 М ... 23 sec
rar a -m0 ... 1280 М...  30 sec
PKZIP2_5 -add -lev=3 ... 617 М ... 33 sec
gzip  -1 ... 627 М ... 55 sec
bzip2 -1 ... 619 М ... 110 sec  
 
Добавлено:

Цитата:
zip легко будет быстрее.

Что ?
 
Добавлено:

Цитата:
-m0 - фактически копирование

Копирование на перфокарты - фактически копирование.
 

Цитата:
1280/30=42МБ/с ваша скорость

Вывод неверен.
 

Цитата:
зачем вам выше

Чтобы не тратить время.
 
 
 
 
 
 
EugeneRoshal
Могу я поинтересоваться такой стратегией записи ?
 

Всего записей: 7008 | Зарегистр. 31-08-2008 | Отправлено: 12:51 07-11-2017 | Исправлено: ndch, 13:00 07-11-2017
   

Страницы: 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 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199

Компьютерный форум Ru.Board » Компьютеры » Программы » WinRAR (часть 3)
Maz (27-08-2020 19:31): WinRAR (часть 4)


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

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

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru