Что такое золотой линкер?
Прочитав два ответа от @Kusalananda и @ikkachu, кажется, я понял. В окне -1 оболочка ожидает чего-то, чтобы одновременно открыть конец записи канала и затем закрыть его. Как только конец записи открыт, оболочка в окне -1 печатает приглашение. Как только конец записи закрывается, оболочка получает EOF и умирает.
На стороне окна -2 у нас есть две ситуации, описанные в моем вопросе :в первой ситуации с echo ls > f, нет файлового дескриптора 3, поэтому у нас есть echoнерест, и его stdinи stdoutвыглядят так:
0 --> tty
1 --> f
Затем echoзавершается, и оболочка закрывает оба дескриптора. Поскольку файловый дескриптор 1 закрыт и ссылается на f, конец записи fзакрывается, и это приводит к EOF для окна -1.
Во второй ситуации мы запускаем exec 3>fв нашей оболочке, заставляя оболочку принять эту среду:
bash:
0 --> tty
1 --> tty
2 --> tty
3 --> f
Теперь мы запускаем echo ls >& 3, и оболочка выделяет файловые дескрипторы для echoследующим образом:
echo:
0 --> tty
1 --> f # because 3 points to f
2 --> tty
Затем оболочка закрывает три приведенных выше дескриптора, включая f, но fпо-прежнему имеет ссылку на него из самой оболочки. Это важное отличие. Закрытие дескриптора 3 с помощью exec 3>&-закроет последнюю открытую ссылку и вызовет EOF для окна -1, как отметил @Kusalananda.
Линкер goldбыл разработан как линкер, специфичный для ELF -, с намерением создать более удобный и быстрый линкер, чем BFD ld(, «традиционный» линкер GNU binutils ). В качестве побочного -эффекта он действительно способен связывать очень большие программы, используя меньше памяти, чем BFD ld, по-видимому, из-за меньшего количества уровней абстракции, с которыми приходится иметь дело, и потому что структуры данных компоновщика более непосредственно отображаются в ELF. формат.
Я не уверен, что есть много документации, в которой конкретно рассматриваются различия в конструкции между двумя компоновщиками и их влияние на использование памяти. Существует очень интересная серия статей о компоновщиках Яна Лэнса Тейлора, автора различных компоновщиков GNU, в которой объясняются многие проектные решения, приведшие к gold. Он пишет , что
The linker I am now working, called gold, on will be my third. It is exclusively an ELF linker. Once again, the goal is speed, in this case being faster than my second linker. That linker has been significantly slowed down over the years by adding support for ELF and for shared libraries. This support was patched in rather than being designed in.
(Второй линкер представляет собой BFD ld.)
Золотой линкер был написан, чтобы значительно ускорить процесс линковки.Согласно золотому автору Яну Лэнсу Тейлору
At the moment gold has only one significant advantage over the existing linker: it is faster. On large C++ programs, I have measured it as running five times faster.
Он сравнивает производительность золотого линкера с традиционным линкером GNU. gold (в отличие от компоновщика GNU )не использует библиотеку BFD для обработки объектных файлов.
Ограничение gold заключается в том, что (в отличие от компоновщика GNU, который может обрабатывать многие типы объектных файлов, )он может связывать только объектные файлы формата ELF.
Что касается проблем, с которыми вы столкнулись при использовании компоновщика GNU, вот интересный ответ на аналогичный вопрос о SO от Майкла Адама:
The gold linker even found some dependency problems in our code, since it seems to be more correct than the classical one with respect to some details. See, e.g. this Samba commit.
goldпо сравнению с ldэталоном
Я опубликовал конкретный синтетический бенчмарк ld по сравнению с золотом на:https://stackoverflow.com/questions/3476093/replacing-ld-with-gold-any-experience/53921263#53921263
Краткое изложение результатов :золото было в 2-3 раза быстрее, чем ld.
Этот выигрыш во времени может сильно изменить правила игры в сложных проектах на C++ без -из -управляющих шаблонов и генерации кода, потому что этап компоновки включает все файлы из проекта и, в отличие от компиляции, он должен быть делается всегда, даже если вы изменяете только один файл.cpp.
Таким образом, медленное время соединения делает цикл разработки невыносимым и, вероятно, является основной причиной, по которой Google вложил в него ресурсы. Только представьте себе преимущества ожидания 10 секунд вместо 30 секунд для каждого тривиального изменения файла.
Выигрыш синтетического теста также совпал с фактическим выигрышем, который я получил в сложном реальном проекте (gem5 ), как также упоминалось в этом ответе.
В современных системах GNU/Linux доступно три компоновщика:
- ld , поддерживается GNU binutils,
- золото , поддерживается GNU binutils, «все еще находится в стадии бета-тестирования»,
- lld , разработанный в рамках проекта LLVM.
Тесты скорости см. в:https://www.phoronix.com/scan.php?page=article&item=lld4-linux-tests&num=2TL, DR:lldсамый быстрый, за ним следует gold, за ним следуетld
Некоторые источники говорят, что золотой проект находится в стагнации , и структура пакета в Fedora отражает это.