Сайт | Скачать | Видео | Wiki

Автор Тема: mkpfs сжатие  (Прочитано 15889 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн ilfat

  • Ветеран
  • *****
  • Сообщений: 438
  • Репутация: +11/-0
Re: mkpfs сжатие
« Ответ #45 : 13 Февраль 2017, 17:42:15 »
Будьте внимательнее: lz4 -Xhc.
Сори, опечатка.
Перепаковал palemoon в lz4 -Xhc, не ракета, но первый запуск ускоряет заметно
Размер естественно будет больше, но я его предложил как алогоритм для опции быстрого сжатия (-g), а ракета он в плане скорости сжатия, а не скорости запуска, по сравнению с xz -Xbcj, который как я понял идет по умолчанию в PuppyRus.

Оффлайн ilfat

  • Ветеран
  • *****
  • Сообщений: 438
  • Репутация: +11/-0
Re: mkpfs сжатие
« Ответ #46 : 13 Февраль 2017, 17:56:59 »
Протестировал сегодня свой комп. Прогнал тест по всей базе МагОС. Результаты справедливы только конекретно к моему железу (проц + носитель)
Это средние результаты чтения по всей базе:
Код
read  all                           lz4          42.43 sec
read  all                      lz4 -Xhc          33.57 sec
read  all                           lzo          31.24 sec
read  all                          gzip          39.59 sec
read  all                            xz          81.98 sec
read  all                  xz -Xbcj x86          80.03 sec
Здесь размеры по сжатию и время упаковки. Выложу несколько больших модулей, на них будет понятнее:
Код
write                           20-x-base.xzm                      lz4           226M          2.76  sec
write                           20-x-base.xzm                 lz4 -Xhc           190M         12.39  sec
write                           20-x-base.xzm                      lzo           175M         62.02  sec
write                           20-x-base.xzm                     gzip           159M         44.38  sec
write                           20-x-base.xzm                       xz           131M         95.40  sec
write                           20-x-base.xzm             xz -Xbcj x86           128M        188.10  sec
Код
write                             10-core.xzm                      lz4           182M          3.17  sec
write                             10-core.xzm                 lz4 -Xhc           151M         11.12  sec
write                             10-core.xzm                      lzo           139M         56.72  sec
write                             10-core.xzm                     gzip           125M         44.25  sec
write                             10-core.xzm                       xz           102M         82.79  sec
write                             10-core.xzm             xz -Xbcj x86            99M        164.11  sec
Код
write                    46-2-libreoffice.xzm                      lz4           137M          1.31  sec
write                    46-2-libreoffice.xzm                 lz4 -Xhc           115M          6.85  sec
write                    46-2-libreoffice.xzm                      lzo           105M         45.20  sec
write                    46-2-libreoffice.xzm                     gzip            95M         33.28  sec
write                    46-2-libreoffice.xzm                       xz            78M         62.72  sec
write                    46-2-libreoffice.xzm             xz -Xbcj x86            72M        124.39  sec
З.Ы. Железо AMD Athlon64x2 (2 ядра, 3ггц), HDD Samsung 500GB SATA2
« Последнее редактирование: 14 Февраль 2017, 10:02:00 от sfs »

Оффлайн DdShurick

  • Это Риччи
  • Активный участник
  • Ветеран
  • ****
  • Сообщений: 8635
  • Репутация: +187/-2
  • Старый чайник
Re: mkpfs сжатие
« Ответ #47 : 13 Февраль 2017, 18:29:43 »
ракета он в плане скорости сжатия
С точки зрения пользователя при сжатии, кроме файла сохранения, скорость некритична, а вот скорость запуска программ - важно. Но тут угадать трудно, влияют два фактора: скорость чтения и мощность процессора. Получается сугубо индивидуально.
Моноблок Lenovo IdeaCentre c200 (Intel Atom D525, Intel GMA 3150, 2 Gb RAM) Richy64
Nettop Acer Aspire Revo R3610 (Atom N330, nVidia GeForce 9400, 3 Gb RAM) Richy64

Оффлайн betcher

  • Модератор
  • Ветеран
  • ****
  • Сообщений: 3019
  • Репутация: +35/-0
  • Автор темы
    • MagOS linux
Re: mkpfs сжатие
« Ответ #48 : 13 Февраль 2017, 18:45:55 »
С точки зрения пользователя при сжатии, кроме файла сохранения, скорость некритична, а вот скорость запуска программ - важно. Но тут угадать трудно, влияют два фактора: скорость чтения и мощность процессора. Получается сугубо индивидуально.
Абсолютно верно. Вот и пытаюсь автоматизировать выбор алгоритма. Разница порой в разы, это критично.

Оффлайн sfs

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 33972
  • Репутация: +231/-0
    • PuppyRus-A
Re: mkpfs сжатие
« Ответ #49 : 14 Февраль 2017, 09:31:36 »
mkpfs dir  (из copmpression-std)
mkpfs -g dir  (из copmpression-fast)
mkpfs dir  -comp xz -Xbcj x86 После разбора параметров двигаем shift до слова -comp, все что после передаем mksquashfs вместо $compression-std, пойдет?
Проще все в переменную copmpression-std="xz -b 512K -Xbcj x86" - причем у нас архитектура - на авто определении - пусть останется
В плюс к -g может добавить -f --fast ? В перспективе г убрать
Если интересно мнение со стороны
Конечно интересно. Не дистрозависимые аспекты надо обсуждать на одном форуме. Зачем создавать искусственные проблемы
Почему бы не сделать ключ к компресии
Потому, что на практике достаточно 2 вариантов:
1. Любимый по дефолту
2. Быстрый для промежуточного
Остальное - лишние усложнения
для fast компрессии может и  lz4 -Xhc подойти
По моим данным он медленнее.
Когда сделаем copmpression-std="xz -b 512K -Xbcj x86" - можно будет в copmpression-fast=любые параметры
Пока так нельзя, т.к. xz K -Xbcj x86 -b 512 не работает
скорость запуска программ - важно. Но тут угадать трудно,
Поэтому у нас по дефолту минимальный размер - это для всех хорошо. Остальные варианты - специфика железа и мне кажется - ловля блох

Сделайте тогда и вторую переменную compression-std для основного алгоритма.
Могу, но хотелось бы после переделки pfsmerge-dir. Или надо срочно - тормозятся эксперименты?

Оффлайн betcher

  • Модератор
  • Ветеран
  • ****
  • Сообщений: 3019
  • Репутация: +35/-0
  • Автор темы
    • MagOS linux
Re: mkpfs сжатие
« Ответ #50 : 14 Февраль 2017, 09:55:56 »
Проще все в переменную copmpression-std="xz -b 512K -Xbcj x86" - причем у нас архитектура - на авто определении - пусть останется
Может не очень удачно объяснил. Я предлагаю три варианта.
1. Стандартный (как сейчас без параметров)
2. Быстрый (тоже черезпеременную gzip или lz4)
3. Любые параметры, которые передаются mksqushfs
А по поводу shift  это уже вариант реализации.

Оффлайн ilfat

  • Ветеран
  • *****
  • Сообщений: 438
  • Репутация: +11/-0
Re: mkpfs сжатие
« Ответ #51 : 14 Февраль 2017, 09:59:30 »
Потому, что на практике достаточно 2 вариантов
У каждого они свои. При этом для флешки у меня они одни, для ПК с HDD другие, для ноута с SSD третьи. Вы со своей колокольни видите только xz -Xbcj x86 по умолчанию и lz4 для fast и хотите чтобы ваше видение было по умолчанию в PFS-Utils, а все остальные пусть конфиги ковыряют. Вы только не воспринимайте, пожалуйста, в штыки. Здоровая дискуссия на этапе разработки не повредит :)
В плюс к -g может добавить -f --fast ? В перспективе г убрать
Полностью согласен, очень логично.
xz -b 512K -Xbcj x86
А почему не xz -b 1M -Xbcj x86? Если уж за размер бороться, то размер блока в 1мб дает меньший размер на выходе.
Поэтому у нас по дефолту минимальный размер - это для всех хорошо. Остальные варианты - специфика железа и мне кажется - ловля блох
С ловлей блох не соглашусь, перевел базу в один модуль PFS со сжатием lz4 -Xhc и разница заметна, 3.54 против 12.68 по умолчанию по скорости чтения. И это не просто цифры, а на деле видна разница.

Оффлайн ilfat

  • Ветеран
  • *****
  • Сообщений: 438
  • Репутация: +11/-0
Re: mkpfs сжатие
« Ответ #52 : 14 Февраль 2017, 10:11:13 »
Вы со своей колокольни видите только xz -Xbcj x86 по умолчанию и lz4 для fast и хотите чтобы ваше видение было по умолчанию в PFS-Utils, а все остальные пусть конфиги ковыряют.
Тут я не имел ввиду менять умолчания, пусть остаётся как есть, просто нужна возможность с помощью опций из командной строки выбирать то что нужно конкретно каждому пользователю не обращаясь к конфигу, а чтобы опции не плодить передавать опции напрямую mksquashfs, как предлагают, и желательно не только алгоритм, но если возможно и размер блока.

Оффлайн sfs

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 33972
  • Репутация: +231/-0
    • PuppyRus-A
Re: mkpfs сжатие
« Ответ #53 : 14 Февраль 2017, 10:24:40 »
3. Любые параметры, которые передаются mksqushfs
А по поводу shift  это уже вариант реализации.
Не уверен, что приживется. Где юзер, а где ключи xz -b 1M -Xbcj x86 - я и сам не запомню
Не проще ли наделать себе mkpfs-flash и т.д. с разными параметрами...
Вы со своей колокольни
"Моя колокольня" - это несколько лет практического использования пфс  ;)

-f --fast - сделал в гит и вики
С ловлей блох не соглашусь, перевел базу в один модуль PFS со сжатием lz4 -Xhc и разница заметна, 3.54 против 12.68 по умолчанию по скорости чтения.
Можно подробнее

Оффлайн DdShurick

  • Это Риччи
  • Активный участник
  • Ветеран
  • ****
  • Сообщений: 8635
  • Репутация: +187/-2
  • Старый чайник
Re: mkpfs сжатие
« Ответ #54 : 14 Февраль 2017, 11:40:20 »
это несколько лет
Всего лишь?
Моноблок Lenovo IdeaCentre c200 (Intel Atom D525, Intel GMA 3150, 2 Gb RAM) Richy64
Nettop Acer Aspire Revo R3610 (Atom N330, nVidia GeForce 9400, 3 Gb RAM) Richy64

Оффлайн ilfat

  • Ветеран
  • *****
  • Сообщений: 438
  • Репутация: +11/-0
Re: mkpfs сжатие
« Ответ #55 : 14 Февраль 2017, 14:59:06 »
Можно подробнее
Ну вот к примеру простейший тест: sudo time -p rsync -a /usr/bin/ /tmp/, где бинарники, заметьте, собираются из всех слоев AUFS и если раньше на стандартной поставке МагОС, то есть со сжатием модулей в xz (в базе их 34 штуки) тест справлялся за 12.46 сек, после конвертации в lz4 время сократилось до 5.59 сек.
После тестов по подборке оптимального алгоритма для моего железа победителями стали lz4 -Xhc и lzo, они шли ноздря в ноздрю опережая друг друга от теста к тесту на несколько милисекунд. Ввиду многократной разницы по скорости сжатия в пользу lz4 -Xhc я и выбрал его для своего железа (на том же железе, но для флешки победитель gzip) После конвертации базы в lz4 -Xhc скорость теста еще снизилась до 4.8 сек. Далее было принято волевое решение ;) собрать всю базу в один PFS модуль и тут я уперся в ваш алгоритм по умолчанию :) Пришлось подождать.. Далее разборка и сборка заново уже со своим алгоритмом. Вот такие выкрутасы) Так теперь скорость теста снизилась уже до 3.54 сек. Это что касается цифр.
Реальную разницу я сразу заметил на менюшках КДЕ, которые жутко тормозят при первом открытии, правда, если предусмотрено сохранение кэша, то такой беды нет. Сейчас менюшки выпадают почти без задержки. Речь не о приросте скорости чтения из squashfs на 20-30 процентов, которые при работе трудно было бы почувствовать, а в несколько раз, что все-таки уже заметно, тем более на КДЕ. Я понимаю у вас оболочка легкая, для вас может это действительно ловля блох, если при этом еще у вас i5 и выше.
Поэтому у нас по дефолту минимальный размер - это для всех хорошо
Это точно хорошо для i7 и для маленьких и медленных флешек, для остальных не факт, если не лень заморачиваться, то возможно есть смысл подобрать свой алгоритм и тем больше в этом смысла чем быстрее носитель и медленнее процессор. Например для ноута на Celeron с SSD разница между lz4 и xz просто огромна.
Где юзер, а где ключи xz -b 1M -Xbcj x86 - я и сам не запомню
Запомнить нужно один ключ, это --help и со временем действительно нужное само запомнится. Возможно вы недооцениваете своих пользователей, уж кому надо --help то осилят.
Не уверен, что приживется.
Ключики конечно проще, указал одну буковку и вперед, но их вы тоже не хотите, при том что алгоритмов уж не так много, а букв в алфавите хватает  :)

Если все останется как сейчас, то правильно ли я понимаю, что если я из числа не согласных с xz -Xbcj x86, то мне придется каждый раз лезть в конфиг и менять компресс стд для каждого случая, отличного от предшествующего? Ну например у меня в конфиге выставлено lz4 -Xhc, решил я собрать модуль для флешки, полез в конфиг поменял на gzip, собрал, обратно поменять естественно забыл, потом запилил на этом же конфиге модуль уже под свое железо, потом понял что не то сжатие что нужно, поменял обратно на lz4 -Xhc и собрал заново и так далее? Примерно так это будет выглядеть?

Оффлайн DdShurick

  • Это Риччи
  • Активный участник
  • Ветеран
  • ****
  • Сообщений: 8635
  • Репутация: +187/-2
  • Старый чайник
Re: mkpfs сжатие
« Ответ #56 : 14 Февраль 2017, 15:13:10 »
если я из числа не согласных
То милости прошу ко мне в оппозицию. Будем писать mksqmodule. Сообща мы их быстро уделаем :)
Моноблок Lenovo IdeaCentre c200 (Intel Atom D525, Intel GMA 3150, 2 Gb RAM) Richy64
Nettop Acer Aspire Revo R3610 (Atom N330, nVidia GeForce 9400, 3 Gb RAM) Richy64

Оффлайн betcher

  • Модератор
  • Ветеран
  • ****
  • Сообщений: 3019
  • Репутация: +35/-0
  • Автор темы
    • MagOS linux
Re: mkpfs сжатие
« Ответ #57 : 14 Февраль 2017, 15:17:36 »
То милости прошу ко мне в оппозицию.
Это лучший аргумент ЗА. :)

Оффлайн ilfat

  • Ветеран
  • *****
  • Сообщений: 438
  • Репутация: +11/-0
Re: mkpfs сжатие
« Ответ #58 : 14 Февраль 2017, 15:23:25 »

То милости прошу ко мне в оппозицию. Будем писать mksqmodule. Сообща мы их быстро уделаем :)
Тестировать всегда пожалуйста :)

Оффлайн sfs

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 33972
  • Репутация: +231/-0
    • PuppyRus-A
Re: mkpfs сжатие
« Ответ #59 : 14 Февраль 2017, 15:47:49 »
Если все останется как сейчас
Я ничего не имею против
3. Любые параметры, которые передаются mksqushfs
Но меня бы интересовал в первую очередь pfsmerge-dir
Этот вариант по любому есть и останется
наделать себе mkpfs-flash и т.д. с разными параметрами...
милости прошу ко мне в оппозицию
Нет никакой оппозиции. Есть нежелание некоторых работать в коллективе