LINUX.ORG.RU

Статическая компиляция

 , harmful.cat-v.org,


1

5

Статическая компиляция — это отлично, посоны.

1) Это решение dependency hell раз и навсегда, абзац.
2) Компилятор Go умеет автоматически скачивать и вкомпиливать либы с шитхаба, например. Это значит, что не надо будет думать: «а будет ли эта либа в {{.distro_name}}?»

А проблема памяти и жесткого диска давно уже не стоит. Во-первых, тот же Go вкомпиливает в бинарник не всю либу, а только необходимые функции; а во-вторых, с терабайтными винтами как может быть жалко пары лишних мегабайт?

Дискасс.

а во-вторых, с терабайтными винтами как может быть жалко пары лишних мегабайт?

ssd?

l0stparadise ★★★★★
()

LOR лечение игрозависимости, шизофрении и статической компиляции на одном сайте, круглосуточно, бесплатно.

anonymous
()

РМС потирает лапы, наокнец-то мерзкий LGPL перестанет помогать проприетарщикам.

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

Пары-тройки десятков, да на каждое приложение.

Смотря какое приложение, у меня исполняемый файл разрабатываемой софтины чуть больше 4-х метров, ЕМНИП, весит и пока не особо растет. А, например, исполняемый файл acme в Plan 9 весит полмегабайта. Это всяко меньше, чем образ SmallTalk'а. =)

korvin_ ★★★★★
()
Последнее исправление: korvin_ (всего исправлений: 1)

И при каждом обновлении безопасности гигабайтами всё выкачивать :}

Deleted
()

harmful.cat-v.org

Только хотел сказать, мол тебе на http://harmful.cat-v.org, а тут в раз — и в тегах http://harmful.cat-v.org. Получается теперь, если я поставлю ссылку на http://harmful.cat-v.org, это будет сродни тавтологии. Поэтому ссылку на http://harmful.cat-v.org я ставить не буду, ведь ссылка на http://harmful.cat-v.org уже как бы есть. Вот.

P.S. Всё-таки поставлю: http://harmful.cat-v.org

i-rinat ★★★★★
()

Кстати, идея. Когда IPO в LLVM подтянется, делать так: все библиотеки собирать с -O4, а после установки прямо на системе собирать статические бинарники. Пока процесс не завершён, будет работать динамическое связывание. Потом можно будет запускать статически собранный бинарник.

При обновлении библиотеки все зависимые от неё статические бинарники удаляются и пересобираются заново.

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

наконец-то мерзкий LGPL перестанет помогать проприетарщикам.

Для соблюдения лицензии достаточно предоставить возможность пересобрать приложение с другой версией LGPL библиотеки. Набор .o файлов достаточен.

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

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

При обновлении библиотеки все зависимые от неё статические бинарники удаляются и пересобираются заново.

Как говорится, «worst of both worlds». И эти люди дают ссылки на harmful...

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

Этим будут заниматься мейнтейнеры.

rogvold
() автор топика

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

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

Как говорится, «worst of both worlds». И эти люди дают ссылки на harmful...

Прочитал ещё раз. Никак в толк не возьму, что не нравится-то? У гентушников вдобавок к развлечению «пересобери мир» появится развлечение «перелинкуй мир».

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

Никак в толк не возьму, что не нравится-то?

То, что обновление разделяемой библиотеки так же ломает всё, как и при динамической линковке; но при этом потребление памяти - как при статической. Напомни, в чем цель была?

У гентушников вдобавок к развлечению «пересобери мир» появится развлечение «перелинкуй мир».

Ну, как развлекуха гентушнегов - вполне.

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

То, что обновление разделяемой библиотеки так же ломает всё, как и при динамической линковке;

Не ломает. Включает fallback на динамическую линковку. Перелинковка и оптимизация статических бинарников работает фоном. Как готово, заменяет симлинк в /usr/bin, например.

но при этом потребление памяти - как при статической.

Не то чтобы я был апологетом статической линковки, но так ли уж много памяти это займёт? Хотя вот Qt можно бандлом сделать, и динамически линковаться с бандлом. Или инлайнером выдрать из него мелкие функции, воткнуть в бинарник, с остатком линковаться динамически.

Напомни, в чем цель была?

Решить «проблему» обновления библиотек отдельно.

i-rinat ★★★★★
()

1) Это решение dependency hell раз и навсегда, абзац.

gentoo?

2) Компилятор Go умеет автоматически скачивать и вкомпиливать либы с шитхаба, например. Это значит, что не надо будет думать: «а будет ли эта либа в {{.distro_name}}?»

не нужно

u283
()

1) Это решение dependency hell раз и навсегда, абзац.

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

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

обновление разделяемой библиотеки так же ломает всё, как и при динамической линковке;

Не ломает. Включает fallback на динамическую линковку.

Что, по какому критерию и каким образом включает этот «fallback»?

Перелинковка и оптимизация статических бинарников работает фоном. Как готово, заменяет симлинк в /usr/bin, например.

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

Qt можно бандлом сделать, и динамически линковаться с бандлом.

Что такое «бандл» и чем он отличается от динамической библиотеки?

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

Ладно, вопросов больше нет. На вышеприведенные тоже можешь не отвечать.

tailgunner ★★★★★
()

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

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

Хотя вот Qt можно бандлом сделать

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

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

У меня бинарь одного REST API сервачка на хаскеле весит добрых 16 метров.

А ты его слинкуй динамически ;) Суммарный вес еще больше будет. Хаскель же!

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

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

экономия на спичках.

я за бан. Просто потому что так надо.

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

Такое ощущение, что это всё уже кто-то пробовал делать, вышла лажа, и теперь это в учебниках описано. А я просто не знаю.

На вышеприведенные тоже можешь не отвечать.

Мне эта область не сильно интересна, прототипом я заниматься не буду. А обсуждение в таком ключе бессмысленно и неконструктивно.

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

Такое ощущение, что это всё уже кто-то пробовал делать, вышла лажа

То, что ты предлагаешь - просто усложненный варниант динамической линковки. И если ты с этим не согласен, дальнейшее обсуждение (по крайней мере, со мной) в самом деле бессмысленно.

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

Я ждал этого комментария.

В plan9 вкомпиливается не вся либа, а только нужные функции.

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

просто усложненный варниант динамической линковки

Странно было бы считать, будто принципиальный недостаток статической линковки (невозможность обновить общий код, не скачивая всё зависящее от него) можно исправить, не выходя за рамки статической линковки. Разве это не очевидно?

То, что ты предлагаешь

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

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

Разве это не очевидно?

Не очевиден профит от реализации.

обсуждение перешло в жонглирование понятиями «статическая-динамическая» и «плохо-хорошо».

/me молча пожимает плечами

tailgunner ★★★★★
()

2) Компилятор Go умеет автоматически скачивать и вкомпиливать либы с шитхаба, например. Это значит, что не надо будет думать: «а будет ли эта либа в {{.distro_name}}?»

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

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

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

Не очевиден профит от реализации.

В лучшем случае единицы процентов. Все значительные оптимизации уже давно сделаны, поэтому «о! это же ускорит в два раза!» не будет. Так что тут не попробуешь — не узнаешь.

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

На пару процентов в синтетических тестах.

Не доверяю я особо этим синтетическим тестам. На своем коде проверяю, а у меня даже меньше процента получилось.

Но, мой код почти и не вызывает ничего библиотечного.

А так, пожалуй, чем чаще вызывается код из so-шек, тем быстрее будет работать статическая линковка.

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

А так, пожалуй, чем чаще вызывается код из so-шек, тем быстрее будет работать статическая линковка.

Для этого нет никаких причин и у этого нет никаких подтверждений.

tailgunner ★★★★★
()

прикольный сайт. они там перепутали лево с право для vim, perl, mercurial и oss, а так все верно. забукмаркал.

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

Для этого нет никаких причин

Так вызов so-шных функций через таблицы же происходит при динамической линковке. Это как минимум +1 indirection к каждому вызову.

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

Ну это и дает несколько процентов прироста на пустых функциях.

Вот я и говорю, чем меньше вызовов из .so тем меньше деградация в производительности.

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

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

Вот я и говорю, чем меньше вызовов из .so тем меньше деградация в производительности.

А я говорю, что максимум ускорения - единицы процентов и только в специально подобранных случаях.

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

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

i-rinat

При обновлении библиотеки все зависимые от неё статические бинарники удаляются и пересобираются заново.

«пересобирать» звучит очень пессимистично. А вот «перелинковать», для чего гугл и вкладывались в развитие быстрого линковщика gold, уже точнее.

У гентушников вдобавок к развлечению «пересобери мир» появится развлечение «перелинкуй мир»

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

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

но при этом потребление памяти - как при статической. Напомни, в чем цель была?

Разрабатывали KSM (Kernel Samepage Merging) для виртуалок, но как раз замечательно подойдёт в данном случае.

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