Mold 1.0

Быстро он в своих рассуждениях до жидомасонов и заговоров доходит

Где?

Конкретно к содержимому статьи по ссылке претензии какие-то есть?

Претензий нет, все по делу сказал. Хехе. :)

У него есть зависимость на libxxhash которой нету в моем дистре. Посмотрел код - вызывается в двух местах чтобы посчитать хеш XXH3. Просто заменил на std::hash, все работает. Это что, прямо самое узкое место с каким-то, возможно, более быстрым хешем чтобы либу тащить ниочем?

Сам хеш действительно быстрый https://github.com/Cyan4973/xxHash. Но быстро побенчить в сравнении с std::hash не могу, там бенч на С, можно наверное плюсами собрать, но я не заморачивался

Там же по сути объектники те же самые только с заголовком или нет?

Нет.

hobbit прав, там не будет многих дубликатов функций, которые до этого были в разных объектниках. И линкеру не нужно проверять все объектники на нарушение ODR…

Если интересно узнать про модули, то есть видео: https://youtu.be/9OWGgkuyFV8

Пичалька. С другой стороны если позиционировать mold для разработки (edit-build-test), то lto наверное не нужен.

Да и bottleneck в этом случае в оптимизаторе…

Нет, как раз в случае LTO боттлнек именно в компоновщике. Компоновка может занимать время, сравнимое с компиляцией в объектные файлы. Поэтому я надеялся что этот компоновщик сможет исправить эту ситуацию. Но судя по всему пока нет.

не просто гентушника, я ещё gentooLTO использую

А ты посмотри, какие процессы работают во время линковки.

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

я ещё gentooLTO использую

Я про это и говорю (:

Mold (a modern linker)

тут какая-то хитрость? не получается составить из слов «a modern linker» слово «mold»

Точно также, как gold = Google linker.

уже ответили ранее по треду: Mold 1.0 (комментарий)
олдовые юниксвейщики любили утилиты парой букв называть, поэтому никакого удивления нейминг не вызывает

У C/C++ проблемы быстродействия линковки это не проблемы линкера как такового, а проблемы отсутствия модулей как единиц языка. Из-за чего сначала компилятор генерирует кучу плохо структурированного дерьмища, а потом компоновщику приходится в этом дерьмище разбираться по именам, которые в общем случае ссылаются ХЗ куда.

вообще на эту тему советую почитать книжку «linkers and loaders». там последовательно пишут линкер на перле в текстовых файлах, как сквозной проект. и разбирают разные форматы исполняемых бинарей и объектных файлов.

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

или наоборот: почему несмотря на весь прогресс разных ЯП, такую штуку как объектно-ориентированный линкер, компилятор, тулчейн встретишь не всегда и везде?

вот например, A2 на активном обероне. взяли и написали на обероне ассемблер, дизассемблер, свой линкер. объектно/модульно ориентированный, ога.

вдобавок к «своему» формату .exe файлов : несколько своих разных .obx, .obw, .oba, .Abx, .obj.

это совсем не не дроиды, которых вы ищете самые .obj, это другие. вдобавок, есть текстовый .sym с метаинформацией модуля (примерно совпадает со спефификацией модуля без тела реализации).

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

в каком-нибудь sml или окамле – сигнатура модуля примерно это же самое.

в каком-нибудь lua или питоне – просто dict / хешмап экспортированных символов(функций).

вообще, пример с A2 и Active Oberon показывает, что linker может быть на удивление простым, и loader не сильно сложнее – если не замыкаться на форматы типовых .o/.elf или там .obj/pe exe а придумать свой, с нормальными метаданными.

и компилятор сишки в духе 6c/6l из Plan9 – тоже.

в этом смысле, сравнивая A2/Active Oberon с Blackbox/Component Pascal есть некоторый прогресс (более привычно в стиле обычных консольных утилит, проще скриптуемо). сравнивая обероны все с той же адой и запускалкой сборки проектов типа gprbuild для сборок или gnat для компилятора/линкера (где обычный gcc с необычными патчами) – пример, как такой тулчейн может выглядеть более традиционно.

вообще с этим вашим с++ странная история. сначала придумывают свой хрупкий типа ABI и манглинг как костыль к cfront генерации через сишку в духе той же вала или nim, темплейты и прочие генераторы бойлерплейта – а потом удивляются, что какое-нибудь KDE со сборкой Qt объектов или там хромой линкуется минут по пять.

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

вместо нормальной модульности, сделанной правильно – на уровне языка, линкера, формата бинарных файлов и библиотек.

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

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

Можно закапывать.

Нет, в компиляторе. Просто при lto компилятор вызывается линковщиком второй раз.

Xxhash в gdb используется, чё там у тебя за говнодистр?

но лицензия это же почти единственная его фича…

Вот модули из C++20 как раз по идее могли бы эту проблему решить…

Я уточнил на всякий случай у Кэмерона, что модули действительно ускоряют линковку:

https://imgur.com/a/EAdyOVI

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

Будут что-то про свободу ещё говорить.

Попробовал для начала только gnutls, че-то даже даже со включенным sccache разница не поняла. Видимо надо линковать что-то жирное и одно.

Я правильно понимаю, что все эти наработки в LLVM lld автор встроить уже не мог?

Если бы мог, то форкнул бы lld, а не стал писать новый линкер с нуля

Будут

Кто?

Ты на основании заявления автора одного конкретного проекта (очень похожего на троллинг, к слову), кажется, решил какие-то глобальные выводы сделать?

А можно пример проекта на обероне, сравнимого по размеру с chrome или kde, который линкуется быстро?

Судопоцман, ты‐то сам здоров?

При чём тут я?

А я?

Тебе лишь бы вопросом на вопрос ответить?

Да.