LINUX.ORG.RU
ФорумTalks

Динамическая линковка не нужна!

 ,


0

6

В соседнем разделе бурно идет обсуждение, как выразился Evgueni, стюардессы, которую опять откопали: в Убунте придумывают очередной способ создания пакетов без внешних зависимостей.

И вот, уже пошли мнения о том, что «проще все линковать статически» и «может, вообще тогда отказаться от .so»?

Что это, очередные закидоны ЛОРовцев или реальная идея? За советами мы решили обратиться к самым старперным специалистам в глобальной компьютерной сети «Интернет». Вот что они пишут (выдержки/сокращения):

Rob Pike (один из разработчиков Unix, Plan 9, нескольких языков программирования и не только), 2008

В первом докладе Sun Microsystems о том, как они реализовали в своей ОС динамические библиотеки, сообщалось, что система получилась больше и медленее. Места на диске экономилось совсем мало. Тесты проводились на Xlib, и заключение было таково: преимуществ нет, одни недостатки.

Да, все современные ОС их поддерживают, но это не значит, что это хорошая мысль. В Plan 9 мы пытались избавиться хотя бы от некоторых необоснованных вещей, которые «все делают».


Geoff Collyer, 2002

Нет, у нас [в Plan 9] не вся библиотека C в каждой программе. В каждой программе содержится только копия каждой вызываемой (прямо или косвенно) функции.

Разделение (sharing) кода производится на уровне секций кода (text segments), как в Unix V6 или V7. При форке процесса потомок будет пользоваться тем же кодом, что и родитель, за счет соответствующего маппинга страниц памяти. Если несколько раз запустить одну и ту же программу с помощью exec, все эти процессы разделят код.

С учетом такого разделения и низких цен на RAM (...) я не вижу нужды в разделяемых библиотеках. Вспомним, что в Unix их реализовали, в первую очередь, из-за громоздких и страшных библиотек X11, а большинству наших пользователей сего дара Божьего удалось избежать.

Отметим, что безо всяких разделяемых библиотек утилиты в Plan 9 при аналогичных возможностях обычно меньше по размеру, чем программы из FreeBSD.


Не пойми кто

<btdn> Я никак, ну вот хоть убей, никак не могу понять, зачем люди используют динамическое связывание.
<aiju> btdn: Потому же, почему верят в Бога.


Roman Shaposhnikov, 2007

Что общего между разделяемыми библиотеками и коммунизмом? Очень просто: и то, и другое в теории выглядит прекрасно, а в реальности провалилось с треском. (...) Поищите файлы .so в любом коммерческом или бесплатном, но большом пакете. Не удивляйтесь, если там даже специальные версии glibc попадутся.



Ссылочки (источники и не только):
http://harmful.cat-v.org/software/dynamic-linking/
http://harmful.cat-v.org/software/dynamic-linking/versioned-symbols
https://blogs.oracle.com/rvs/entry/what_does_dynamic_linking_and
http://port70.net/~nsz/32_dynlink.html

★★★★★

Последнее исправление: cetjs2 (всего исправлений: 7)

Ответ на: комментарий от tailgunner

А я не призывал, я констатировал свершившийся факт.

i-rinat ★★★★★
()
Ответ на: комментарий от tailgunner

А как возможно выполнить LTO между приложением и линкуемой библиотекой, если она линкуется динамически?

Вполне очевидно, что никак.

Кстати, clang умеет класть IR в объектные файлы и при линковке делать LTO. То есть можно держать IR рядом с native в библиотеках и делать LTO либо при запуске, либо при установке программ (сохраняя получившийся мегабинарник).

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

То есть можно держать IR рядом с native в библиотеках и делать LTO либо при запуске, либо при установке программ (сохраняя получившийся мегабинарник)

Теоретически - можно, но на практике - нет. Да и выигрыш от этого сомнителен - разумно спроектированная библиотека самодостаточна, откуда там потенциал для оптимизации при линковке с приложением?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

разумно спроектированная библиотека самодостаточна

Такие бывают, да?

потенциал для оптимизации

Хэш-таблицы, списки и деревья из glib сильно выиграют от инлайнинга. Функции там мелкие, накладные расходы на вызов на этом фоне большие.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

разумно спроектированная библиотека самодостаточна

Такие бывают, да?

Бывают не такие?

Хэш-таблицы, списки и деревья из glib сильно выиграют от инлайнинга.

Не думаю, что современные компиляторы настолько умны. Впрочем, glib - вырожденный случай, попытка сделать из Си пародию на Си++.

tailgunner ★★★★★
()
Ответ на: комментарий от KivApple

Все проблемы от ленивых девелоперов, которые не хотят обновлять вовремя приложения под новые ABI библиотек.

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

Napilnik ★★★★★
()

и как, простите, делать апдейты библиотек в таком случае? обновил либу - переконпелял пол мира?

x0r ★★★★★
()
Ответ на: комментарий от tailgunner

Не думаю, что современные компиляторы настолько умны.

Ну думаю, что там нужны особо сложные алгоритмы.

Впрочем, glib - вырожденный случай, попытка сделать из Си пародию на Си++.

А как быть, если на Си понадобились ассоциативные массивы?

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Не думаю, что современные компиляторы настолько умны.

Ну думаю, что там нужны особо сложные алгоритмы.

https://developer.gnome.org/glib/2.36/glib-Balanced-Binary-Trees.html

Думаю, от компилятора нужны очень нехилые усилия, чтобы bykfqybnm эту мешанину, вызываемую по указателю.

И это еще не рассматриваем, что делать с получившимся машкодом...

А как быть, если на Си понадобились ассоциативные массивы?

Макросы куячить же и static-функции в заголовочных файлах. А не хочешь макросов - Си++ к твоим услугам.

tailgunner ★★★★★
()
Ответ на: комментарий от x0r

и как, простите, делать апдейты библиотек в таком случае? обновил либу - переконпелял пол мира?

Перелинковал пол-мира. ld или gold, чай, не gcc, работает значительно быстрее.

А в случае бинарных дистров — скачал патч и пропатчил пол-мира.

proud_anon ★★★★★
() автор топика
Ответ на: комментарий от Napilnik

А не надо думать о дистрибутиве X. Пусть его мейнтейнеры придержут обновление этой программы до того, как соберутся обновить и библиотеку.

KivApple ★★★★★
()
Ответ на: комментарий от KivApple

Когда они обновят свою библиотеку то она будет опять не той версии что поддерживается программой.

Napilnik ★★★★★
()
Ответ на: комментарий от true_admin

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

В случае статических либ тебе вряд ли придется сразу выкачивать пол-системы. Вряд ли все майнтайнеры/разработчики так быстро внесут изменения.

another ★★★★★
()

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

u283
()
Ответ на: комментарий от u283

хм, стоп, я ничего не понимаю, да, собирать надо будет ведь один раз? но при обновлениях либы все равно придется заного собирать программы пользующиеся этой либой.

u283
()
Ответ на: комментарий от Dark_SavanT

В 18 веке вообще компьютерами не пользовались и ничего, всем хватало.

Deleted
()
Ответ на: комментарий от gag

А вот тут можно было бы применить KSM

KSM работает постранично — слишком грубо для этого. Вот совсем не факт что оно тут может помочь. Впрочем, я не мерял.

true_admin ★★★★★
()
Ответ на: комментарий от another

В случае статических либ тебе вряд ли придется сразу выкачивать пол-системы. Вряд ли все майнтайнеры/разработчики так быстро внесут изменения.

И это ещё один существенный недостаток.

Кстати, интересно, а нельзя ли совместить два способа линковки сразу: либы лежат отдельно, бинари отдельно. Всё это при обновлении системы на хосте линкуется и кэшируется типа dalvik cache. При обновлении либы все зависимости перелинковываются с новой версией. Фазу компиляции можно опустить.

true_admin ★★★★★
()
Ответ на: комментарий от note173

Не понял мысли. У нас есть tradeoff: линковать все динамически и иметь проблемы с зависимостями, линковать все статически и иметь проблемы с увеличением потребления оперативной памяти (и временем холодной загрузки бинаря). Я же предлагаю линковать все статически, но при этом находить одинаковые блоки (втч заранее формировать бинари так, чтобы они появлялись) и не грузить их дважды.

Есть еще юзкейс динамической линковки как предоставление API. Но эту задачу лучше решать через IPC.

snizovtsev ★★★★★
()
Ответ на: комментарий от snizovtsev

100 мб оперативной памяти (есть ли такие библиотеки?) — копейки. Здесь высказывают более важные опасения — невозможность разом закрыть дырки в безопасности.

note173 ★★★★★
()
Ответ на: комментарий от note173

Это легко может превратиться в 100мб на каждый виджет на панели или еще какую-нибудь фигню. Плюс загрузка с диска этих 100мб дело не быстрое.

snizovtsev ★★★★★
()
Ответ на: комментарий от quantum-troll

В этом вина исключительно разработчика, что он не сделал клиент-сервер для таких задач.

Каждый виджет - клиент-серверный бинарь? Или все виджеты в одном клиент-серверном бинаре? А напомни, за что идет борьба.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

В случае панели, можно и один виджет — один процесс, почему нет?
В случае тулкита, можно часть реализовать в библиотеке, часть как сервис.
На самом деле, не так много библиотек требуют чего-то подобного.

quantum-troll ★★★★★
()
Последнее исправление: quantum-troll (всего исправлений: 1)
Ответ на: комментарий от quantum-troll

В случае панели, можно и один виджет — один процесс, почему нет?

Да можно, конечно. По одному толстому статически слинкованному бинарю на виджет. Еще раз - за что борьба идет? Или это просто борьба против динамической линковки?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

От кастомизируемых виджетов на панели больше вреда, чем пользы. Значит не нужно ☺

PolarFox ★★★★★
()

В своё время у меня на PalmOS была всего одна динамически линкуемая либа — mathlib. В остальном приложениям хватало API операционной системы.

PolarFox ★★★★★
()
Ответ на: комментарий от tailgunner

По одному толстому статически слинкованному бинарю

Почему толстому-то? Массивными действиями занимаются процессы, а не библиотеки же.
Даже вместо библиотеки http может использоваться webfs.

quantum-troll ★★★★★
()
Ответ на: комментарий от quantum-troll

По одному толстому статически слинкованному бинарю

Почему толстому-то?

Потому что он статический.

Даже вместо библиотеки http может использоваться webfs.

Ну то есть вместо библиотеки делается специальная ФС? И кто-то думает, что это будет быстрее lib*.so?

tailgunner ★★★★★
()

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

Но вот что:
1) трафик в инете вырастит - факт
2) необходимость иметь больше винты - факт
____а) больше места на сами программы
____б) больше места на большие бэкапы от увеличенных программ
3) мотивация делать хорошо - отпадёт, и большинство софта будет гнить и быть уязвимыми местами системы
4) теперь нужно будет большее количество ресурсов, на сопровождение и развитие качественного софта: раньше только аби меняли, но либа ставала безопасней, её фиксили и улучшали; а тут нужно будет дэвам следить за всеми багтрекерами и релизами всех библиотек, что бы если что - затянуть к себе новую версию, и под неё переделать всё; много ли будет этим страдать?

Spirit_of_Stallman ★★★
()
Ответ на: комментарий от Spirit_of_Stallman

трафик в инете вырастит - факт

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

PolarFox ★★★★★
()
Ответ на: комментарий от PolarFox

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

Я об этом не подумал.
Спасибо, важное замечание.

Spirit_of_Stallman ★★★
()
Ответ на: комментарий от tailgunner

Потому что он статический.

«Динамический — маленький, статический — большой». Ну-ку.
http://9fans.net/archive/2002/02/21
---
A quick sampling suggests that Plan 9 programs are
typically smaller than FreeBSD/386 programs even with shared
libraries. Here are some FreeBSD sizes:

: unix; size /bin/cat /bin/ed /usr/bin/awk /usr/X11/bin/sam
text data bss dec hex filename
54188 4324 9760 68272 10ab0 /bin/cat
122835 8772 81920 213527 34217 /bin/ed
135761 4772 15756 156289 26281 /usr/bin/awk
52525 1412 53448 107385 1a379 /usr/X11/bin/sam

Of those, awk and sam use shared libraries. The corresponding Plan 9
sizes are:

; cd /bin; size cat ed awk sam
15996t + 2208d + 944b = 19148 cat
45964t + 4212d + 41232b = 91408 ed
114731t + 35660d + 12040b = 162431 awk
86574t + 7800d + 66240b = 160614 sam

and the Plan 9 programs cope with Unicode and UTF.
---

Ну то есть вместо библиотеки делается специальная ФС?

В некотором смысле. Конечно, так делается далеко не для всего, но в случае webfs это очень удобно — например, hget это всего лишь скрипт на rc shell.

И кто-то думает, что это будет быстрее lib*.so?

В плане подобные вещи обходятся дёшево, в линуксах же наверняка будет люто тормозить.

И да, такой подход очень гибок: можно использовать другую реализацию и можно легко добавить промежуточный слой.

quantum-troll ★★★★★
()
Ответ на: комментарий от quantum-troll

A quick sampling suggests that Plan 9 programs are

ed, awk, cat, sam

Да ты издеваешься.

И кто-то думает, что это будет быстрее lib*.so?

В плане подобные вещи обходятся дёшево, в линуксах же наверняка будет люто тормозить.

Утипути. Что, в Plan9 не происходит переключения контекста? Или там переключение контекста ничего не стоит?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Переключения контекста не всегда критичны, а в тех случаях, где они критичны, можно собрать и статически.
Никакого «десятки бинарников по 100 МБ» всё равно не выходит.

Да ты издеваешься.

Зато они есть в каждом юниксе (за исключением sam).

quantum-troll ★★★★★
()

Есть и диругие языки кроме сишечки. Или что программа на питоне будет поставлять свой собственный питон слинкованый с нативом левых либ использованных в программе?

Это не смешно короче.

r ★★★★★
()
Ответ на: комментарий от quantum-troll

Переключения контекста не всегда критичны

Подумай хоть немножко о сравнительной стоимости RPC и локального вызова.

а в тех случаях, где они критичны, можно собрать и статически.

Вот и сравнивай полностью статическую систему с в основном динамической, не отвлекаясь на волшебные свойства Plan9.

«десятки бинарников по 100 МБ» всё равно не выходит.

Десятки бинарей по нескольку мегабайт каждый (графический тулкит как раз столько весит).

Зато они есть в каждом юниксе (за исключением sam).

В Unix и Plan9 у них даже исходники разные, собраны они разными компиляторами, и после этого кто-то сравнивает размер бинарей? cat-v.org - это однозначно диагноз.

P.S. http://gcc.gnu.org/ml/gcc/2004-06/msg01956.html

tailgunner ★★★★★
()
Ответ на: комментарий от quantum-troll

Но как только дело доходит до fork, всё печально: http://9fans.net/archive/2009/02/422

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

tailgunner ★★★★★
()
24 июля 2013 г.
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.