Сжатие исполняемых файлов (Философский вопрос)

[dergachev]

Вот уже давно изобрели идею сжимать исполняемые файлы (ну в смысле elf'ы и пр.) так, чтобы они оставались исполняемыми, и при вызове на лету распаковывались. Это не только экономит место на диске (и, соответственно в кэше), но и ускоряет холодный старт программ (ибо читать с диска дольше, чем распаковывать). Ну вот upx такая софтинка есть, скажем.

Вопрос - а почему бы просто не применить её тупо к /bin и /usr/bin? Никто не пробовал ли случайно? Почему вообще до сих пор все живут с несжатыми программами? Какие минусы у этой технологии?

[Portnov]

upx и другие упаковщики (тысячи их! особенно под винды) работают несколько не так, как вы сказали. Они просто выкидывают из исполнимого файла ненужную/необязательную информацию и переупорядочивают оставшуюся, чтоб файл поменьше был. Ну, например, есть такая штука - выравнивание секций файла. Чтобы ОС/процессору было "удобнее", лучше чтобы все секции elf-файла были по размеру кратны, скажем, 4Кб. Соответственно в файле получается куча нулей. Выравнивание необязательно, upx его убирает. Ну и т.д.

С настоящим сжатием/распаковкой, я думаю, выигрыша не получится - на большинстве файлов выигрыш от ускорения чтения файлов будет съеден затратами на распаковку. Имхо.

[sash-kan]

мы ведь просто размышляем, да?

тогда предлагаю к размышлению такую вводную информацию:
каков средний размер исполняемого файла или библиотеки в двух популярных операционных системах: gnu и win32?

[Warlornhor]

каков средний размер исполняемого файла или библиотеки в двух популярных операционных системах: gnu и win32?

Килобайты и мегабайты? :)
Может оно и не нужно тогда...

[dergachev]

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

Разве? о_О А это тогда что значит? (с оффсайта upx):

The main news in version 3 are:
- optional LZMA compression

каков средний размер исполняемого файла или библиотеки в двух популярных операционных системах: gnu и win32?

Код: Выделить всё

$ ls /usr/bin -s | sort -n | tail
3328 ctest
3364 qmake
4076 gimp-2.6
5620 gs
6028 audacity
7908 mencoder
8124 mplayer
8460 xetex
8904 inkview
8928 inkscape

С настоящим сжатием/распаковкой, я думаю, выигрыша не получится - на большинстве файлов выигрыш от ускорения чтения файлов будет съеден затратами на распаковку. Имхо.

Ну вот разработчики обещают обратное:

It achieves an excellent compression ratio and offers very fast decompression.

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

P.S.

мы ведь просто размышляем, да?

Да-да, можно в флейм, если что

[NickLion]

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

Неправда, они действительно сжимают. Одним переупорядочиванием 40 мб файл до 8 мб не сожмешь (это Photoshop.exe был). Там используется именно сжатие:

The main news in version 3 are:
- optional LZMA compression

А по поводу исходного вопроса: особого смысла нет. Цель упаковщика - экономия места, а не быстрый холодный старт. Загрузка с диска - это ну, может 20% времени, а скорее и того меньше. Основное время занимает собственно инициализация приложения. Думаете OOo грузится так из-за медленного чтения с винта? Или GIMP? Нет, сжатие не ускорит их загрузку.
А что касается экономии места мне под / (х64) хватает 10 гиг (ещё 2 гига свободные - мало ли что поставить понадобится). Так и стоит куча всякой гадости (dev-пакеты, TeX Live, etc).

PS насчёт фотошопа - весь профит был в уменьшении размера. Время запуска не изменилось

[Voral]

а кроме того (раз уж философствуем).

Сжатие исполняемых файлов вещь уже очень старая. Очень актуально было в свое время: когда и система и проекты/игры/иной софт должны были разметситься на одной пятидюймовой дискете.....

Но сколько лет прошло, а это не очень то используется широко. Не думаю, что "все такие глупые" что не применили бы это если бы было действительно выгодно.


Не сталкивался давно, но раньше если исполняемый файл сам по себе маленький то его "сжатие" приводило к его увеличению

[Ali1]

Не думаю, что "все такие глупые"

+1
ЗЫ
Не проще сжимать ФС налету. Но...
JFFS2
DTFS

UPD
BIOS запакована.

[NickLion]

Чего-то подумалось: а если упаковщик внести в линкер, а распаковщик в загрузчик ОС? Просто идейка, сомневаюсь, что это что-то даст

[Ali1]

Чего-то подумалось: а если упаковщик внести в линкер, а распаковщик в загрузчик ОС? Просто идейка, сомневаюсь, что это что-то даст

ИМХО дополнительные смены контекста. И ошибки, разумеется.

[NickLion]

Чего-то подумалось: а если упаковщик внести в линкер, а распаковщик в загрузчик ОС? Просто идейка, сомневаюсь, что это что-то даст

ИМХО дополнительные смены контекста. И ошибки, разумеется.

не, смен контекста не будет - распаковка будет производиться загрузчиком, т.е. в памяти уже будет распакованный исходный образ. А вот ошибки - это да, возможно Просто практика показывает, что чистый код сжимается не очень хорошо.

[diesel]

Код: Выделить всё

diesel@eifel:~$ du -hs /bin/ /usr/bin/ /lib /usr/lib
4.6M    /bin/
126M    /usr/bin/
97M    /lib
1.1G    /usr/lib

было бы чего паковать.

[IMB]

На полноценных PC наверно смысла особого нет, а вот для встраиваемых решений это может иметь смысл.

[Bizdelnick]

1.1G /usr/lib

Ни фига ж себе. У меня

Код: Выделить всё

$ du -hs /bin/ /usr/bin/ /lib /usr/lib
12M     /bin/
249M    /usr/bin/
162M    /lib
280M    /usr/lib

[iglezz]

У упаковки исполняемых файлов есть один (не|)большой минус — повышеное потребление оперативной памяти...

[Frank]

Код: Выделить всё

frank@frank-desktop:~$ du -hs /bin/ /usr/bin/ /lib /usr/lib
6,6M    /bin/
343M    /usr/bin/
496M    /lib
2,8G    /usr/lib

Ну а по теме: лучше сжатие на уровне ФС, причём опциональное. И оно таки есть в этих самых некоторых ФС.

[diesel]

1.1G /usr/lib

Ни фига ж себе. У меня

Код: Выделить всё

$ du -hs /bin/ /usr/bin/ /lib /usr/lib
12M     /bin/
249M    /usr/bin/
162M    /lib
280M    /usr/lib

это debian stable со всеми потрохами метапакета gnome-desktop-environment

[sash-kan]

это debian stable

жму руку.

вот почему так получается?
опытные пользователи ставят stable.
а новички (которых на каждом углу от этого предостерегают), не задумываясь, громоздят себе если не unstable, то вообще какую-нибудь гремучую смесь.
почему?

вопрос риторический.

[IMB]

Ну зачем обобщать?
Я не считаю себя опытным пользователям, но тем не менее всегда использую только stable, да и перехожу на него обычно только после r1-r2.
Если система всем устраивает, то зачем что-то менять?
P.S. Хотя надо признать, что несколько пакетов из backports всё же стоят.
P.P.S. Ответ тоже риторический.

[rm_]

У упаковки исполняемых файлов есть один (не|)большой минус — повышеное потребление оперативной памяти...

Прямо в точку, причём многократно повышенное, и именно поэтому сжатие не получило широкого распространения.
Оно даёт экономию в занимаемом месте на диске, но проигрыш в виде повышенного расхода памяти и в некоторых случаях - времени при запуске файла.
Если несжатый бинарник можно тупо примапить в оперативку (google://memory-mapped file) и начать исполнять, даже не считывая его весь, то сжатый нужно не просто сначала прочитать, но ещё и зарезервировать в ОЗУ место, куда он будет распакован. Соотв-но при последующей нехватке ОЗУ придётся скидывать это в своп, тогда как страницы несжатого файла можно просто сдискардить, т.к. на диске-то они всеравно есть (и являются как бы "read-only продолжением" свопа).

[Ali1]

У упаковки исполняемых файлов есть один (не|)большой минус — повышеное потребление оперативной памяти...

Прямо в точку, причём многократно повышенное, и именно поэтому сжатие не получило широкого распространения.
Оно даёт экономию в занимаемом месте на диске, но проигрыш в виде повышенного расхода памяти и в некоторых случаях - времени при запуске файла.
Если несжатый бинарник можно тупо примапить в оперативку (google://memory-mapped file) и начать исполнять, даже не считывая его весь, то сжатый нужно не просто сначала прочитать, но ещё и зарезервировать в ОЗУ место, куда он будет распакован. Соотв-но при последующей нехватке ОЗУ придётся скидывать это в своп, тогда как страницы несжатого файла можно просто сдискардить, т.к. на диске-то они всеравно есть (и являются как бы "read-only продолжением" свопа).

А теперь считаем такты, переключения контекстов, промахи кешей, сбросы TLB....

[sash-kan]

всегда использую только stable, да и перехожу на него обычно только после r1-r2.

а кто-то только что сказал, что «неопытный» (подмигиваю)

[watashiwa_daredeska]

опытные пользователи ставят stable.
а новички (которых на каждом углу от этого предостерегают), не задумываясь, громоздят себе если не unstable, то вообще какую-нибудь гремучую смесь.

Потому что мне интересно :) Да-да, я неопытный.

[Nazyvaemykh]

Новичков очень часто переполняют (необоснованные) надежды, что вот еще чуть-чуть и Linux перестанет тормозить, глючить, станет всеми любимым и повсюду распространенным. Естественно, все это они ожидают увидеть не в позапрошлых дистрибутивах, а в самых новых.

С опытом надежды тают, баги становятся фичами…

[sash-kan]

Потому что мне интересно

скорее потому, что ты можешь написать баг-репорт мэйнтейнерам.

Да-да, я неопытный.

да-да, мы все в это верим (улыбка)