Существует огромное и постоянно увеличивающееся количество систем, в которых экстремальный уровень статического связывания может иметь огромное положительное влияние на приложения и производительность системы.
Я имею в виду то, что часто называют «встроенными системами», многие из которых сейчас все чаще используют универсальные операционные системы, и эти системы используются для всего, что только можно вообразить.
Чрезвычайно распространенный пример - устройства, использующие системы GNU / Linux, использующие Busybox. Я довел это до крайности с помощью NetBSD, создав загрузочный образ системы i386 (32-разрядный), который включает в себя как ядро, так и его корневую файловую систему, последняя содержит единственный статически связанный (crunchgen) двоичный файл с жесткими ссылками на все программы, который сам содержит все (ну, по крайней мере, 274) из стандартные полнофункциональные системные программы (большинство, кроме набора инструментов), и его размер составляет менее 20 мегабайт (и, вероятно, он очень комфортно работает в системе только с 64 МБ памяти (даже с корневой файловой системой несжатый и полностью в ОЗУ), хотя мне не удалось найти такой маленький, чтобы протестировать его).
В более ранних сообщениях упоминалось, что время запуска двоичных файлов с статической связью быстрее (и может быть намного быстрее), но это только часть картины, особенно когда все объектный код связан с одним и тем же файлом, особенно когда операционная система поддерживает подкачку кода по запросу непосредственно из исполняемого файла. В этом идеальном сценарии время запуска программ буквально незначительно, поскольку почти все страницы кода уже находятся в памяти и используются оболочкой (и init любыми другими фоновыми процессами, которые могут выполняться) , даже если запрошенная программа никогда не запускалась с момента загрузки, поскольку, возможно, требуется загрузить только одну страницу памяти, чтобы выполнить требования программы во время выполнения.
Однако это еще не все. Я также обычно создаю и использую установки операционной системы NetBSD для своих полных систем разработки путем статической компоновки всех двоичных файлов. Несмотря на то, что для этого требуется гораздо больше дискового пространства (всего ~ 6,6 ГБ для x86_64 со всем, включая инструментальную цепочку и статическую привязку X11) (особенно если сохранить полные таблицы символов отладки, доступные для всех программ, еще ~ 2,5 ГБ), результат все равно в целом работает быстрее, а для некоторых задач даже использует меньше памяти, чем типичная система с динамической компоновкой, предназначенная для совместного использования кодовых страниц библиотеки. Диск дешевый (даже быстрый диск), и память для кеширования часто используемых файлов на диске также относительно дешевая, но циклы ЦП на самом деле не такие, и оплата ld.so начальных затрат за каждый процесс, который запускается каждый раз, когда он Запуск будет отнимать часы и часы циклов ЦП от задач, требующих запуска многих процессов, особенно когда одни и те же программы используются снова и снова, например, компиляторы в системе разработки. Статически связанные программы инструментальной цепочки могут сократить время сборки всей многоархитектурной ОС для моих систем на часов. Мне еще предстоит встроить инструментальную цепочку в свой единственный crunchgen бинарный файл, но я подозреваю, что когда я это сделаю, время сборки будет сэкономлено больше благодаря выигрышу для кэша ЦП.
person
Greg A. Woods
schedule
28.07.2017
