LINUX.ORG.RU

GNU Gold Linker объявлен устаревшим и исключён из поставки binutils по умолчанию

 , , , ,


0

4

В недавно вышедшем релизе GNU binutils 2.44 произошло знаковое изменение. Альтернативный основному компоновщику GNU Gold Linker объявлен устаревшим и исключён из поставки binutils по умолчанию. Его код пока ещё не исключён из общего репозитория binutils-gdb и вместо основного тарбола binutils он доступен в binutils-with-gold-2.44.tar.*. Однако в одном из будущих релизов binutils планируется полностью удалить код GNU Gold Linker.

Gold Linker был изначально создан инженерами компании Google более двух десятилетий назад исключительно для ELF формата. Основная мотивация его создания была — создать более быстрый компоновщик. И действительно, линковка ELF объектных файлов при помощи Gold Linker работает быстрее, чем у основного компоновщика GNU, однако активность разработки Gold Linker была довольно низкой в последние несколько лет. Одна из причин снижения активности заключается в том, что Google сменил приоритет в сторону тулчейна LLVM со своим компоновщиком. Компоновщик из этого LLVM-тулчейна уже сейчас превосходит в производительности оба компоновщика GNU.

>>> Официальный анонса GNU binutils 2.44

>>> Подробности



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

Компоновщик из этого LLVM-тулчейна уже сейчас превосходит в производительности оба компоновщика GNU.

Наглядное сравнение эффективности двух лицензий. Ну ты понял ;)

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

А «закладки» прочих корпораций, щедро насабмитивших в Linux?

Та пускай. Главное чтоб до FreeBSD не добрались)

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

Та пускай.

Южный говор слышу я.

Главное чтоб до FreeBSD не добрались)

Так ведь уже добрались. Там как раз этот самый LLVM+clang.

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

А можно линковать llvm-ным линкером скомпилированное gcc? Вроде форматы одинаковые. Ну если всякие там lto не использовать.

vbr ★★★★★
()

Google сменил приоритет

никогда такого не было и вот опять

bender ★★★★★
()

Компоновщик из этого LLVM-тулчейна уже сейчас превосходит в производительности оба компоновщика GNU

Наконец-то, давно ждал, невозможные тормоза были, теперь заживём

buddhist ★★★★★
()

Компоновщик из этого LLVM-тулчейна уже сейчас превосходит в производительности оба компоновщика GNU.

А с mold как? Кто обгоняет?

imul ★★★★★
()
Ответ на: комментарий от imul
Program (linker output size)GNU ldGNU goldLLVM lldmold
MySQL 8.3 (0.47 GiB)10.84s7.47s1.64s0.46s
Clang 19 (1.56 GiB)42.07s33.13s5.20s1.35s
Chromium 124 (1.35 GiB)N/A27.40s6.10s1.52s

mold is so fast that it is only 2x slower than the cp command on the same machine. If you find that mold is not faster than other linkers, feel free to file a bug report.

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

Круто, не знал о таком, надо будет попробовать его в деле

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

Интересная цитата из LFS

--enable-default-hash-style=gnu

By default, the linker would generate both the GNU-style hash table and the classic ELF hash table for shared libraries and dynamically linked executables. The hash tables are only intended for a dynamic linker to perform symbol lookup. On LFS the dynamic linker (provided by the Glibc package) will always use the GNU-style hash table which is faster to query. So the classic ELF hash table is completely useless. This makes the linker only generate the GNU-style hash table by default, so we can avoid wasting time to generate the classic ELF hash table when we build the packages, or wasting disk space to store it.

Интересно, использовали ли они это когда сравнивали?

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

Лохи, сэр. Надо было на ассемблере писать.

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

Это глянуть на гитхабе молда я и сам умею.

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

А этот mold оптимизирующий линкер? Или тупенький?

Вряд ли автор mold что-то упустил, он же раньше и LLD написал.

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

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

Не лень же было людям заморачиваться оптимизировать…

unDEFER ★★★★★
()

Gentoo. sys-devel/binutils по умолчанию собираются с USE="-gold".

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

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

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

То, что осталось в основном тарболе.

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

А что толку, если они не поддерживают лто, инкрементальную линковку и линкер скрипты? Последний еще и всего 1 архитектуру поддерживает. Не серьезно.

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

не поддерживают лто,

mold умеет, насколько я в курсе.

инкрементальную линковку

Инкрементальная линковка - костыль ради ускорения процесса.
С их скоростями это не особо и важно.

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

Почему, инкрементальная линковка - замена ar по сути. Для нормальной системы сбрки не особо нужно, но если сборка сделана на мейке по рекурсивному принципу, то там каждый подкаталог наверх выдавал ar архив, и вот это можно заменить на инкремениальную линковку. Ну либо систему сборки заменить, но 1е обычно проще. :)

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

Скорее демонстрации игры в одни ворота. Почему-то обычный линковщик не был объявлен устаревшим, хотя

Компоновщик из этого LLVM-тулчейна уже сейчас превосходит в производительности оба компоновщика GNU.

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

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

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

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

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

У них там возможно stable api nonsense как в ядре.
Оставить код в проекте означает что нужно согласовывать изменения с этим кодом и проверять, что ничего не сломалось. По той же причине из mesa повыкидывали старые драйвера - они просто блокировали рефакторинг общего кода в mesa т.к чтобы тестировать их нужно древнее оборудование

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

Ну и что? Голд же работает.

А что он умеет такого, чего не умеет лд или ллд?

Не понимаю такой подход.

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

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

У них там возможно stable api nonsense как в ядре.

Вроде бы нет: насколько я знаю, голд не использует либбфд, а всё велосипедит сам.

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