[РЕШЕНО]Чем лучше сжимать ядро и инитрамфс?

warlock9000	# 7 лет, 2 месяца назад (отредактировано 7 лет, 2 месяца назад)
Темы: 6 Сообщения: 766 Участник с: 21 марта 2016	сжатое-не сжатое, выигрыш по скорости на современном железе врятли будет больше 1-2 сек. Конечно, если паровоз древний, типа третьего пня - тогда имеет смысл (возможно) заморачиваться. Вообще загрузка и распаковка ядра-рамфс занимают малую часть времени от общего процесса загрузки. Большая часть - это загрузка WM/DE (настроенных) https://github.com/warlock90000/awesome

# 7 лет, 2 месяца назад (отредактировано 7 лет, 2 месяца назад)

Сообщения: 766

Участник с: 21 марта 2016

сжатое-не сжатое, выигрыш по скорости на современном железе врятли будет больше 1-2 сек. Конечно, если паровоз древний, типа третьего пня - тогда имеет смысл (возможно) заморачиваться. Вообще загрузка и распаковка ядра-рамфс занимают малую часть времени от общего процесса загрузки. Большая часть - это загрузка WM/DE (настроенных)

https://github.com/warlock90000/awesome

nafanja	# 7 лет, 2 месяца назад (отредактировано 7 лет, 2 месяца назад)
Темы: 94 Сообщения: 9252 Участник с: 02 июня 2012 заблокирован	safocl, когда то сам задавался этим вопросом: - кто быстрее? даже скриптик писал, если интересно можешь сам посмотреть кто из этих сжималок быстрее работает у тебя. https://github.com/AnTAVR/test_compression берешь не сжатый!!! образ initramfs (выше писали как его создать), копируешь его к себе в папку и выполняешь. python test_compression.py initramfs-linux-fallback.img а по полученным результатам делаешь вывод, что тебе выбрать ;) Псевдографический инсталлятор Arch Linux ver. 3.8.2 Благодарности принимаются на ЯД 410012815723874

nafanja

# 7 лет, 2 месяца назад (отредактировано 7 лет, 2 месяца назад)

Темы: 94

Сообщения: 9252

Участник с: 02 июня 2012

заблокирован

safocl, когда то сам задавался этим вопросом: - кто быстрее?
даже скриптик писал, если интересно можешь сам посмотреть кто из этих сжималок быстрее работает у тебя.
https://github.com/AnTAVR/test_compression
берешь не сжатый!!! образ initramfs (выше писали как его создать), копируешь его к себе в папку и выполняешь.
python test_compression.py initramfs-linux-fallback.img
а по полученным результатам делаешь вывод, что тебе выбрать ;)

Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874

nafanja	# 7 лет, 2 месяца назад
Темы: 94 Сообщения: 9252 Участник с: 02 июня 2012 заблокирован	у меня вот такие результаты с размером initramfs-linux-custom-fallback.img 64747520b Результат gzip: сжатие 34.148588%, время компр/декомпр 3.5931/0.5348 сек. Результат bzip2: сжатие 31.061554%, время компр/декомпр 5.0383/2.9159 сек. Результат lzma: сжатие 23.509215%, время компр/декомпр 32.2143/1.2383 сек. Результат xz: сжатие 23.512925%, время компр/декомпр 31.8724/1.2665 сек. Результат lzop: сжатие 47.189950%, время компр/декомпр 0.3960/0.4988 сек. Результат lz4: сжатие 48.649439%, время компр/декомпр 0.4302/0.5622 сек. python test_compression.py initramfs-linux-custom-fallback.img 788,11s user 10,39s system 99% cpu 13:25,72 total лучшее % сжатие (от исходного размера файла) показали lzma и xz, но скорость сжатия очень низкая, да и скорость распаковки тоже низкая. у lzop и lz4 скорость сжатия и распаковки очень высокая, но % сжатия небольшой. gzip и bzip2 такие середнечки. но у gzip скорость распаковки сравнима с lzop и lz4. Псевдографический инсталлятор Arch Linux ver. 3.8.2 Благодарности принимаются на ЯД 410012815723874

nafanja

# 7 лет, 2 месяца назад

Темы: 94

Сообщения: 9252

Участник с: 02 июня 2012

заблокирован

у меня вот такие результаты с размером initramfs-linux-custom-fallback.img 64747520b


Результат gzip: сжатие 34.148588%, время компр/декомпр 3.5931/0.5348 сек.
Результат bzip2: сжатие 31.061554%, время компр/декомпр 5.0383/2.9159 сек.
Результат lzma: сжатие 23.509215%, время компр/декомпр 32.2143/1.2383 сек.
Результат xz: сжатие 23.512925%, время компр/декомпр 31.8724/1.2665 сек.
Результат lzop: сжатие 47.189950%, время компр/декомпр 0.3960/0.4988 сек.
Результат lz4: сжатие 48.649439%, время компр/декомпр 0.4302/0.5622 сек.
python test_compression.py initramfs-linux-custom-fallback.img  788,11s user 10,39s system 99% cpu 13:25,72 total

лучшее % сжатие (от исходного размера файла) показали lzma и xz, но скорость сжатия очень низкая, да и скорость распаковки тоже низкая.
у lzop и lz4 скорость сжатия и распаковки очень высокая, но % сжатия небольшой.
gzip и bzip2 такие середнечки. но у gzip скорость распаковки сравнима с lzop и lz4.

Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874

vasek	# 7 лет, 2 месяца назад
Темы: 47 Сообщения: 11743 Участник с: 17 февраля 2013	nafanja но у gzip скорость распаковки сравнима с lzop и lz4 ..... ядро сжато то же с помощью gzip ... Ошибки не исчезают с опытом - они просто умнеют

nafanja	# 7 лет, 2 месяца назад
Темы: 94 Сообщения: 9252 Участник с: 02 июня 2012 заблокирован	vasek, да, для данного типа данных gzip оптимальный вариант. Псевдографический инсталлятор Arch Linux ver. 3.8.2 Благодарности принимаются на ЯД 410012815723874

red	# 7 лет, 2 месяца назад
Темы: 30 Сообщения: 1517 Участник с: 31 августа 2011	nafanja, я так понял этот тест не учитывает работу с диском ? вернее из 10 тестов, только для первого теста компрессия будет = время чтения с диска + время на компрессию ну а дальше как повезёт, на сколько переполнена память, задействуется ли своп - и было бы печально если при малом количестве памяти, для последних тестируемых, процессор еще бы начал тратить время на чистку кеша удаляя или перемещая в своп. В общем для чистоты эксперимента нужно было бы делать чистку памяти между тестами. для safocl на сколько я понял интересен был бы параметр как [ время загрузки с диска сжатого образа + время на его распаковку ] А выбор такого оптимально параметра у каждой машины может сильно отличатся, всё зависит от диска где размещается /boot и мощности процессора. Например, если у тебя SSD и слабый проц или же наоборот медленный HDD но проц имеет высокую частоту, то искомый параметр может быть один и тот же, но в первом случае можно вообще не использовать комперссию а во втором и xz будет не так уж и плох.

red

# 7 лет, 2 месяца назад

Темы: 30

Сообщения: 1517

Участник с: 31 августа 2011

nafanja, я так понял этот тест не учитывает работу с диском ?
вернее из 10 тестов, только для первого теста компрессия будет = время чтения с диска + время на компрессию
ну а дальше как повезёт, на сколько переполнена память, задействуется ли своп - и было бы печально если при малом количестве памяти, для последних тестируемых, процессор еще бы начал тратить время на чистку кеша удаляя или перемещая в своп.
В общем для чистоты эксперимента нужно было бы делать чистку памяти между тестами.

для safocl на сколько я понял интересен был бы параметр как [ время загрузки с диска сжатого образа + время на его распаковку ]
А выбор такого оптимально параметра у каждой машины может сильно отличатся, всё зависит от диска где размещается /boot и мощности процессора. Например, если у тебя SSD и слабый проц или же наоборот медленный HDD но проц имеет высокую частоту, то искомый параметр может быть один и тот же, но в первом случае можно вообще не использовать комперссию а во втором и xz будет не так уж и плох.

nafanja	# 7 лет, 2 месяца назад (отредактировано 7 лет, 2 месяца назад)
Темы: 94 Сообщения: 9252 Участник с: 02 июня 2012 заблокирован	red. вообще тест был на скорость алгоритмов сжатия. red вернее из 10 тестов, только для первого теста компрессия будет = время чтения с диска + время на компрессию тут ты прав, самый первый это учитывает. (и то не всегда) red ну а дальше как повезёт, на сколько переполнена память, задействуется ли своп - и было бы печально если при малом количестве памяти, для последних тестируемых, процессор еще бы начал тратить время на чистку кеша удаляя или перемещая в своп. тут далеко до истины, ну может если памяти всего 256 метров.... red В общем для чистоты эксперимента нужно было бы делать чистку памяти между тестами. да, можно было бы. предлагай команду что это делает))) red для safocl на сколько я понял интересен был бы параметр как [ время загрузки с диска сжатого образа + время на его распаковку ] скорость чтения/записи с диска можно посмотреть в доках по накопителю. ~~и прибавить к результату. ;)~~ и наложить на скорость распаковки. оптимальный тот результат, который будет меньше или не на много больше скорости считывания, по сравнению с другими методами сжатия. Псевдографический инсталлятор Arch Linux ver. 3.8.2 Благодарности принимаются на ЯД 410012815723874

nafanja

# 7 лет, 2 месяца назад (отредактировано 7 лет, 2 месяца назад)

Темы: 94

Сообщения: 9252

Участник с: 02 июня 2012

заблокирован

red. вообще тест был на скорость алгоритмов сжатия.

red
вернее из 10 тестов, только для первого теста компрессия будет = время чтения с диска + время на компрессию

тут ты прав, самый первый это учитывает. (и то не всегда)

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

тут далеко до истины, ну может если памяти всего 256 метров....

red
В общем для чистоты эксперимента нужно было бы делать чистку памяти между тестами.

да, можно было бы. предлагай команду что это делает)))

red
для safocl на сколько я понял интересен был бы параметр как [ время загрузки с диска сжатого образа + время на его распаковку ]

скорость чтения/записи с диска можно посмотреть в доках по накопителю. ~~и прибавить к результату. ;)~~ и наложить на скорость распаковки. оптимальный тот результат, который будет меньше или не на много больше скорости считывания, по сравнению с другими методами сжатия.

Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874

Morisson	# 7 лет, 2 месяца назад
Темы: 18 Сообщения: 1421 Участник с: 11 января 2017	А вообще, какой толк от сжатия, кроме экономии места?

safocl	# 7 лет, 2 месяца назад
Темы: 122 Сообщения: 1571 Участник с: 08 октября 2015	nafanja test_compression.py Результат gzip: сжатие 39.121676%, время компр/декомпр 1.6758/0.2535 сек. Результат bzip2: сжатие 37.082033%, время компр/декомпр 3.2800/1.3209 сек. Результат lzma: сжатие 30.072574%, время компр/декомпр 13.4249/0.7492 сек. Результат xz: сжатие 30.057451%, время компр/декомпр 13.4651/0.7148 сек. Результат lzop: сжатие 51.294122%, время компр/декомпр 0.1364/0.2000 сек. Результат lz4: сжатие 52.542953%, время компр/декомпр 0.1928/0.1811 сек. биг спс за скрипт, помог выяснить ентот момент... думаю можно делать решенной

safocl

# 7 лет, 2 месяца назад

Темы: 122

Сообщения: 1571

Участник с: 08 октября 2015

nafanja
test_compression.py

Результат gzip: сжатие 39.121676%, время компр/декомпр 1.6758/0.2535 сек.
Результат bzip2: сжатие 37.082033%, время компр/декомпр 3.2800/1.3209 сек.
Результат lzma: сжатие 30.072574%, время компр/декомпр 13.4249/0.7492 сек.
Результат xz: сжатие 30.057451%, время компр/декомпр 13.4651/0.7148 сек.
Результат lzop: сжатие 51.294122%, время компр/декомпр 0.1364/0.2000 сек.
Результат lz4: сжатие 52.542953%, время компр/декомпр 0.1928/0.1811 сек.

биг спс за скрипт, помог выяснить ентот момент...

думаю можно делать решенной

safocl	# 7 лет, 2 месяца назад
Темы: 122 Сообщения: 1571 Участник с: 08 октября 2015	nafanja gzip и bzip2 такие середнечки. но у gzip скорость распаковки сравнима с lzop и lz4. ага, в общем выгоднее gzip пока что нету...