The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Первый стабильный релиз компоновщика Mold, развиваемого разработчиком LLVM lld

16.12.2021 10:29

Rui Ueyama, автор компоновщика LLVM lld и компилятора chibicc, представил первый стабильный релиз нового высокопроизводительного компоновщика Mold, заметно опережающего по скорости связывания объектных файлов компоновщики GNU gold и LLVM lld. Проект признан готовым для рабочих внедрений и может применяться в качестве более быстрой прозрачной замены GNU linker на Linux-системах. Из планов на следующий значительный выпуск отмечается доведение до готовности поддержки платформы macOS, после чего начнётся работа по адаптации Mold для Windows.

Mold написан на языке С++ (C++20) и распространяется под лицензией AGPLv3, которая совместима с GPLv3, но не совместима с GPLv2, так как требует открытия изменений при разработке сетевых сервисов. Подобный выбор объясняется желанием получить финансирование разработки - автор готов продать права на код для перелицензирования под разрешительной лицензией, такой как MIT, или предоставить отдельную коммерческую лицензию для тех, кого не устраивает AGPL.

Mold поддерживает все возможности GNU linker и отличается очень высокой производительностью - компоновка выполняется со скоростью, всего в два раза медленнее простого копирования файлов утилитой cp. Например, при сборке Chrome 96 (размером кода 1.89 ГБ) на компоновку исполняемых файлов c debuginfo на 8-ядерном компьютере при использовании GNU gold тратится 53 секунды, LLVM lld - 11.7 секунд, а Mold всего 2.2 секунды (в 26 раз быстрее GNU gold). При компоновке Clang 13 (3.18 ГБ) в GNU gold требуется 64 секунды, в LLVM lld - 5.8 секунд, а в Mold - 2.9 секунды. При компоновке Firefox 89 (1.64 ГБ) в GNU gold необходимо 32.9 секунд, в LLVM lld - 6.8 секунд, а в Mold - 1.4 секунды.

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

Высокая производительность компоновки исполняемого файла из большого числа подготовленных компилятором объектных файлов в Mold достигается использованием более быстрых алгоритмов, активным распараллеливанием операций между доступными ядрам CPU и применением более эффективных структур данных. Например, в Mold реализована техника выполнения интенсивных вычислений одновременно с копированием файлов, упреждающая загрузка объектных файлов в память, использование быстрых хэш-таблиц при разрешении символов, сканирование таблиц перемещений в отдельном потоке и дедупликация повторяющихся в разных файлах объединяемых секций.

  1. Главная ссылка к новости (https://news.ycombinator.com/i...)
  2. OpenNews: Выпуск стандартной Си-библиотеки PicoLibc 1.5
  3. OpenNews: Cosmopolitan - стандартная Си-библиотека и формат кроссплатформенных исполняемых файлов
  4. OpenNews: Apache прекращает разработку stdcxx, стандартной библиотеки C++
  5. OpenNews: Разработчики из Google предложили разработать свою libc для LLVM
  6. OpenNews: Google открыл систему для создания sandbox-окружений для библиотек C/C++
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/56358-linker
Ключевые слова: linker, mold
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (132) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 11:14, 16/12/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –43 +/
    > Mold написан на языке С++ (C++20)

    печально

     
     
  • 2.4, Корец (?), 11:17, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +7 +/
    >при сборке Chrome 96 (размером кода 1.89 ГБ) на компоновку исполняемых файлов c debuginfo на 8-ядерном компьютере при использовании GNU gold тратится 53 секунды, LLVM lld - 11.7 секунд, а Mold всего 2.2 секунды (в 26 раз быстрее GNU gold).

    Вовсе не печально.
    А у тебя есть альтернативы, которые работают быстрее сабжа и написанные на "правильном" ЯП?

     
     
  • 3.9, Аноним (-), 11:48, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • –6 +/
    c++20 это в твоем понимании правильный яп ?
     
     
  • 4.19, AnalMal (?), 13:02, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +14 +/
    Да, правильный. Но никто не запрещает писать тебе писать на С++98
     
     
  • 5.24, Аноним (-), 14:33, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Но никто не запрещает писать тебе писать на С++98

    ты утверждаешь что это write-only язык ?
    прочитай что написано в новости - проект на c++20

     
  • 2.6, Аноним (6), 11:27, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >печально

    Да, жаль, что не на Си.

     
     
  • 3.21, Аноним (1), 13:08, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +8 +/
    да, код на Си намного читабельнее кода на современном C++
     
     
  • 4.46, Аноним (46), 20:49, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Увы, но, современный код на си, даже при том, что читабельный сам по себе, заставляет городить невообразимые тонны нечитаемого бойлерплейта, который ещё и еггог проне. У меня не получается сделать корректно и не превратить либо в лапшу либо в 1000 этажные инлайны с препроцессором. Для высокоуровневых задач плючи всё же намного лучше, кроме того есть уже нормальные стандартные реализации для многих вещей и их обычно достаточно. Особенно современные. Когда хватает самой примитивной работы с байтами, тут да, си вне конкуренции (и то придётся обмазаться расширениями). Интероп опять же намного более годный на мой взгляд тоже в си.
     
     
  • 5.71, Аноним (-), 08:56, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если у тебя "1000 этажные инлайны с препроцессором", то в этом виноват только ты сам. Не умеешь организовывать код. GTK писан на чистом Си, а сам код чётко структурирован как ООП.

    Не умеешь писать в процедурном стеле не лезь.

     
     
  • 6.106, мое правило (?), 00:19, 18/12/2021 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Только чет он так круто организованный, что гномьи авторы придумали vala, только что бы не писать на всратом с.
     
  • 3.65, Аноним (65), 03:06, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Замечательно, что не на С, а на С++20. И разработка быстрее, и код читабельнее, и производительность на высоте. А С-луддитам пора выйти из зоны комфорта и выучить, наконец, С++.

     
     
  • 4.80, Аноним (80), 13:07, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Только какой в этом смысл, если за питон больше платят?
     
     
  • 5.88, Ананас (?), 18:05, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Что, аж две миски?
     
  • 5.89, Аноним (65), 18:06, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Сомневаюсь что-то. Можно пруфлинк?
     
     
  • 6.102, Аноним (80), 21:31, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    https://leonardo.osnova.io/6f458341-e3ff-5373-907e-f19f5a231a17/-/preview/700/
    Не то чтобы сильно больше, но дорасти до большей зп на питоне можно быстрее, так что профита больше учить питон, а не дидовские кресты.
     
     
  • 7.103, Аноним (80), 21:33, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    А если питонщик умеет ещё и на сях лабать, то у него есть хороший шанс стать незаменимым, попадя в правильно место)
     
  • 7.104, Аноним (80), 21:33, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А если питонщик умеет ещё и на сях лабать, то у него есть хороший шанс стать незаменимым, попадя в правильно место)
     
  • 7.114, Аноним (65), 18:12, 18/12/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это что, шутка какая-то? Во-первых, по ссылке зарплата на Python и на С++ абсолютно одинаковая, а не просто "не сильно больше". Во-вторых, цифры неправдоподобные. Зарплата программиста 130 000 рублей? Это одних джунов и студентов опрашивали что ли? Я ожидал увидеть цифры в районе 400 000. В-третьих, что за сайт левый такой и только картинка, почему не дать ссылку на оригинал, статью на Хабре? Наверное потому что там уже напихали авторше в панамку по поводу совершенно неправдоподных цифр?
     
     
  • 8.116, Аноним (80), 20:53, 18/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    На hh ru если выставить фильтр на 400 , вакансий для питонистов 262 находится, а... текст свёрнут, показать
     
     
  • 9.117, Аноним (65), 23:03, 18/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Ну и что, это же не показатель средней зарплаты Если так любишь hh ru, вот тебе... текст свёрнут, показать
     
     
  • 10.119, Аноним (80), 11:55, 19/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Что за агрессия Ты приплюснутый что ли82808 и тебя это задело Средняя зп по ме... текст свёрнут, показать
     
     
  • 11.120, Аноним (65), 19:27, 19/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Просто непонятно как говорить с человеком, который то забывает свои предыдущие... текст свёрнут, показать
     
  • 3.68, n00by (ok), 08:11, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >>печально
    > Да, жаль, что не на Си.

    Ну почему же

    std::string get_realpath(std::string_view path) {
      char buf[8192];
      if (!realpath(std::string(path).c_str(), buf))
        return std::string(path);
      return buf;
    }

     
     
  • 4.93, Аноним (-), 19:08, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну почему же
    > std::string get_realpath(std::string_view path) {
    >   char buf[8192];
    >   return buf;

    Тут "спрятанно" какое-то копирование buf в возвращаемый std::string (которого не будет в си)?

     
     
  • 5.95, Аноним (65), 19:40, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Да, будет копирование. Но его можно было бы избежать, сделав buf изначально типа std::string и передавая buf.data() в realpath().

    Но это всё такое крохоборство походу. В Java и Python строки неизменяемые, там любое изменение строковой переменной это создание нового строкового объекта, ещё дороже получается. Программисты на других языках смотрят на этот подсчёт крох со смехом.

     
     
  • 6.98, Аноним (-), 20:33, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > В Java и Python строки неизменяемые, там любое изменение строковой переменной это создание нового строкового объекта, ещё дороже получается.

    Вообще-то, еще во втором питоне для "объемной" работы со строками были MutableString и StringIO, в Java - тот же StringBuffer.


     
     
  • 7.100, Аноним (65), 21:05, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Это всё так, но мы друг другу не противоречим. MutableString, StringIO и StringBuffer - это не строковые переменные. Это объекты, содержащие массивы байтов. В них надо загонять текстовые данные, копированием, а потом полученные строки в строковые переменные извлекать, тоже копированием. Двойное копирование то бишь. В С++ тоже такое есть, называется std::stringstream.

     
  • 5.96, Аноним (65), 19:52, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > копирование ... которого не будет в си

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

    Это вообще распространённая проблема в С. Ошиблись при работе с памятью, потом из неправильного места в памяти читаем мусор и радостно исполняемся некоторое время, пока проблема не всплывёт вообще в другом месте кода. Трудно дебажить такое. В С++ такие ошибки встречаются гораздо реже.

     
     
  • 6.97, Аноним (-), 20:17, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >> копирование ... которого не будет в си
    > А в С был бы возврат указателя на локальный буфер в функции,
    > где после выхода из функции и вызова парочки других функций,

    Я в курсе, потому и спросил.
    >  Зато без копирования, да.

    Угу, зато есть такие вот неявные кунстштюки, вместо (условного) return str::string(buf).

     
     
  • 7.99, Аноним (65), 20:45, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Такое неявное конструирование объектов очень удобно. И это не является какой-то секретной фичей, это базовая фича, о которой знают все программисты С++. Можно конструировать явно, std::string(buf) является валидной конструкцией. Можно пометить конструктор как explicit, тогда неявное конструирование будет запрещено.

    А в функциональных языках вообще return неявный, возвращается последнее вычисленное выражение, тоже очень удобно, можно писать короткие функции как "a + b", без return.

     
     
  • 8.105, Аноним (-), 22:04, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Не явное удобство явно переоцененно, но это вкусовщина, о которой я не вижу смы... большой текст свёрнут, показать
     
  • 6.109, n00by (ok), 09:18, 18/12/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Смотрим man 3 realpath char realpath const char path, char resolved_pa... большой текст свёрнут, показать
     
     
  • 7.115, Аноним (65), 18:54, 18/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    В таком случае вызывающий get_realpath должен деаллоцировать результат с помощ... большой текст свёрнут, показать
     
     
  • 8.118, n00by (ok), 10:26, 19/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Да Точно так же в Си будет деаллоцирован буфер std string Только в Си все ос... большой текст свёрнут, показать
     
     
  • 9.122, Аноним (65), 20:10, 19/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Хм, так пишешь, как будто это хорошо Явны, значит замусоривают код и заставляют... текст свёрнут, показать
     
     
  • 10.129, n00by (ok), 11:25, 20/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Так там кто-то хотел на Си, значит для него это хорошо Есть же std filesystem ... большой текст свёрнут, показать
     
  • 5.110, n00by (ok), 09:21, 18/12/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Ну почему же
    >> std::string get_realpath(std::string_view path) {
    >>   char buf[8192];
    >>   return buf;
    > Тут "спрятанно" какое-то копирование buf в возвращаемый std::string (которого не будет
    > в си)?

    Тут переполняется стек при "нестандартном" значении PATH_MAX.

     
  • 2.13, Аноним (13), 11:53, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ну возьми да перепиши на раст.
     
     
  • 3.15, x3who (?), 12:27, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Точно, плесень надо писать на ржавчине
     
  • 2.18, Аноним (18), 12:58, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Обрати внимание на исходники GCC, там уже много файликов на С++. Брат жив.
     
     
  • 3.22, Аноним (22), 13:25, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Это говорит только о том, что gcc -- не очень хороший компилятор
     
     
  • 4.25, Аноним (-), 14:35, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > о том, что gcc -- не очень хороший компилятор

    чего именно ? с++ или c ?

     
  • 4.42, Аноним (42), 19:57, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Это говорит только о том, что gcc -- не очень хороший компилятор

    Тебя обманули. gcc это вообще не компилятор! Это коллекция компиляторов.

     
  • 4.74, Аноним (18), 11:52, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    А Шланг*, по этой логике, получается лучше?

    *Шланг весь на C++.

     
  • 2.23, _kp (ok), 14:21, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >>печально

    Ну перепиши на Питон, и радуйся. С девушкой. Питон предоставит достаточно времени. ;)

     
  • 2.30, Аноним (80), 16:24, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Если глянуть исходники, там типичная сишка по сути. Вот например: https://github.com/rui314/mold/blob/main/elf/arch-x86-64.cc
    даже stl не используется.
     
     
  • 3.32, Аноним (32), 16:57, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    ловите питониста, не различает си и си++
     
     
  • 4.52, Аноним (-), 22:11, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    кстати заметьте как ускорено дропают поддержку 32х бит арма
     
     
  • 5.75, Аноним (18), 11:57, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так он микроконтроллерах только и остался.
     
     
  • 6.121, Аноним (-), 19:41, 19/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    это тебе в отделе маркетинга подсказали ?
     
  • 3.60, Аноним (60), 00:27, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > template <>
    > void GotPltSection<X86_64>::copy_buf(Context<X86_64> &ctx) {

    Рили?

     
     
  • 4.61, Аноним (80), 00:42, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    То что обычные сишные процедуры зачем-то в виде шаблонов оформлены, сути не меняет. Там за вечер этот 1% кода выкинуть можно и заменить сишными вызовами процедур и будет 100% сишка. А так пока 99% си 1% си++.
     
     
  • 5.69, n00by (ok), 08:15, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > То что обычные сишные процедуры зачем-то в виде шаблонов оформлены

    Интересно, зачем?

        u8 *loc = base + rel.r_offset;

    /// ...

        auto write8 = [&](u64 val) {
          overflow_check(val, 0, 1 << 8);
          *loc = val;
        };

    /// ...

          write8(S + A);

     
     
  • 6.72, Аноним (80), 08:56, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > auto write8 = [&](u64 val) {

    Легко заменяется на вложенную функцию из GCC C расширения или макрос и дальше можно так же писать
    write8(S + A);

     
     
  • 7.76, Аноним (65), 12:24, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Только тогда теряется либо совместимость со стандартом, либо типобезопасность.
     
     
  • 8.79, Аноним (18), 12:58, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    -stg gnu99... текст свёрнут, показать
     
     
  • 9.90, Аноним (65), 18:08, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вот и я про тоже Нестандартные расширения GNU ... текст свёрнут, показать
     
  • 7.78, n00by (ok), 12:36, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Наверное, я что-то уловил, но зачем там вообще лямбда. Вызывается однократно в теле той же функции, где определена.



        u8 *loc = base + rel.r_offset;

    /// ...

    #ifdef LLL
        auto write8 = [&](u64 val) {
          overflow_check(val, 0, 1 << 8);
          *loc = val;
        };
    #endif

    /// ...

    #ifdef LLL
          write8(S + A);
    #else
          overflow_check(S + A, 0, 1 << 8);
          *loc = S + A;
    #endif



     
     
  • 8.91, Аноним (65), 18:11, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Может раньше неоднократно вызывалась, потом другие вызовы убрали Да много причи... текст свёрнут, показать
     
     
  • 9.92, n00by (ok), 18:36, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Многократно вызывается write32s Там switch и write8 вызывается для R_X86_64_8 ... текст свёрнут, показать
     
  • 6.108, Ordu (ok), 09:17, 18/12/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Интересно, зачем?

    Возможно, просто как способ сделать код более читаемым. Возможно, как способ повысить maintainability кода инкапсуляцией -- операция write8 вынесена отдельно, и если ты хочешь изменить её, то вот она, тебе не надо весь код функции перелопачивать, выясняя где там мы в loc пишем. Кроме того, если ты присмотришься, тут неявно создаётся локальная переменная val инициализируемая значением S+A. Без этой переменной придётся писать S+A дважды, а это прям приглашает наступить будущих мейнтейнеров на грабли, чтоб они поменяли в одном месте S+A на что-нибудь ещё, а в другом месте забыли бы.

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

     
     
  • 7.111, n00by (ok), 09:47, 18/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Неудачно процитировал, лучше весь код смотреть Хотя бы это switch rel r_t... большой текст свёрнут, показать
     
     
  • 8.112, Аноним (80), 15:39, 18/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    И switch так красивее - все case по три строчки Не, красивее было бы вместо rel... текст свёрнут, показать
     
     
  • 9.113, n00by (ok), 16:53, 18/12/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    rel r_type читается из объектника, а указатель откуда возьмётся ... текст свёрнут, показать
     
     
  • 10.123, Crazy Alex (ok), 20:15, 19/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, в принципе если проверку вадиности значения отдельно вынести - можно и по та... текст свёрнут, показать
     
  • 4.101, Аноним (65), 21:18, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > template <>
    > void GotPltSection<X86_64>::copy_buf(Context<X86_64> &ctx) {
    > Рили?

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

     
  • 3.73, Аноним (73), 09:47, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Какой-то трешекод. Вообще ничего не понятно - одни магические константы вхардкожены. У нас бы он код ревью не прошел. 🤣
     
     
  • 4.81, Аноним (80), 13:10, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > ничего не понятно

    У приплюснутых такое в порядке вещей.

     
  • 4.94, Аноним (65), 19:14, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Вообще ничего не понятно

    Так матчасть изучай. GOT с PLT парсить, да релокации осуществлять - это тебе не формы клепать.

    > одни магические константы вхардкожены

    Магические константы аккуратно прокомментированы и локализованы либо в константных массивах, либо в специальных функциях для этих констант. Этот как раз таки противоположность хардкода. А также используются много где исплоьзуются символьные константы типа R_X86_64_RELATIVE. Зря наговариваешь на код в общем.

     

  • 1.2, Аноним (-), 11:16, 16/12/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    > может применяться

    Ну и ладненько. Не хватало еще стопицотзависимого крестового линкера

     
  • 1.3, Аноним (-), 11:17, 16/12/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А парень не промах. Сначала наковырял lld потом сделал mold и вышел в профит. Красавчик.
    Интересно, а правильно ли он компонует ? Новые баги добавляет ?
     
     
  • 2.20, Адмирал Майкл Роджерс (?), 13:08, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Новые баги добавляет ?

    Это конфиденциальная информация.

     
     
  • 3.26, Генерал Пол Накасоне (?), 15:52, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Кем вы себя возомнили?
     
     
  • 4.29, Пал Ко Водетс (?), 16:13, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Директорский состав Каспийского моря. Ваши документы пожалуйста
     
  • 2.36, макпыф (ok), 18:06, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Интересно, а правильно ли он компонует ? Новые баги добавляет ?

    Не знаю, но судя по новости ff chromium и шланг собрались, следовательно работать должен.

     
     
  • 3.45, Аноним (46), 20:36, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Ты случаем не мейнтейнер рача?
     
     
  • 4.47, макпыф (ok), 21:16, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Ты случаем не мейнтейнер рача?

    Нет

     
     
  • 5.48, Аноним (46), 21:24, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Нет

    У них такая же политика "собралось значит работает".

     
     
  • 6.51, макпыф (ok), 21:39, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > У них такая же политика "собралось значит работает".

    У меня по другому. Получилось собрать и запустить program --help путем лютейших костылей и не взираю на тысячи ошибок - все норм, все работает
    А они патчи не любят

     

  • 1.5, Аноним12345 (?), 11:23, 16/12/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Адовы муки статических языков
     
     
  • 2.7, Аноним (7), 11:40, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +12 +/
    программа либо разрабатывается быстро, либо работает быстро. Привыкай, мой юный кодер пробельчиками.
     
     
  • 3.11, Аноним (1), 11:50, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > программа либо разрабатывается быстро, либо работает быстро, но только если разработана с умом

    fixed

     
     
  • 4.62, bergentroll (ok), 01:05, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А если без ума, то и разрабатывается быстро, и работает быстро. Но такая чушь получается!
     
  • 3.67, Простоник (ok), 07:35, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Если бы это было так, мир был бы прекрасен. Но увы мы видим программы, которые разрабатываются за непредсказуемое, часто очень длительное время, многократно превышающее первоначальные планы, медленно работающие,  содержащие массу ошибок, включающие утечки памяти. Здравствуй Rust.
     
  • 2.8, Аноним (8), 11:42, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Там, где на этапе компоновки заканчиваются муки статических языков, начинаются муки динамических погромистов.
     
     
  • 3.54, Аноним (54), 22:46, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Вы давно указатель на null проверяли?
     
     
  • 4.70, n00by (ok), 08:26, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Указатель на Хиндли-Милнера?
     
  • 4.77, Аноним (65), 12:29, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +4 +/
    После проверки на None не забудьте ещё проверить тип переменной
     
  • 4.124, Crazy Alex (ok), 20:23, 19/12/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нахрена мне умный указатель проверять? Он либо содержит то, что должен либо не существует вместе со своим объектом-владельцем. Ну либо код писал идиот, а ревьюили задницей и позволили кому-то писать си-стайл.
     

  • 1.10, Аноним (10), 11:49, 16/12/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    так вроде бОльшая проблема это сама трансляция сколько сама сборка этих двух гиговых файлов происходит? Там ведь бесконечное дёрганье заголовков подстановка и трансляция их каждый раз
     
     
  • 2.14, nobody (??), 12:19, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В C++ это решили (решат) добавлением модулей
     
     
  • 3.86, Аноним (86), 17:50, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Ну отличная новость хотя и спустя 38 лет с момента появления языка. В любом
    случае еще подождем....

    Кстати если взять пионеров, то у многих это уже давно реализовано из коробки:
    cargo, pip, go mod, maven и т.д.

     
  • 2.16, topin89 (ok), 12:27, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Не совсем. На первой сборке очевидно, что на создание объектных файлов уйдёт много времени.
    Потом правится и компилируется один .c/cpp файл в один объектный файл, и это быстро. А потом снова линковка сотен объектных файлов, и это медленно.
     
     
  • 3.85, Аноним (86), 17:47, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Это требует определенной культуры и организации разработки, а так же в целом хорошей работы системы (локального времени) если я правильно помню как там происходит сравнение изменений файлов.
     
  • 2.125, Crazy Alex (ok), 20:26, 19/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Линковка - тоже не сахар, как гентушник говорю :-) на райзене 3700X какой-нибудь хромиум линкуется несколько минут, ну и память жрёт гигабайтами. Тут даже интереснее, удалось ли по памяти эту штуку менее прожорливой сделать
     
     
  • 3.130, n00by (ok), 11:36, 20/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Толку мало от 7го Райзена, когда он в одном потоке линкуется. И это он ещё без lto собирается, в ungoogled-chromium можно оптимизацию включить и сравнить время :-)

    <flag name="optimize-thinlto">Whether to enable ThinLTO optimizations. Turning ThinLTO optimizations on can substantially increase link time and binary size, but they generally also make binaries a fair bit faster.</flag>
    <flag name="thinlto">Build with ThinLTO support. LTO (Link Time Optimization) achieves better runtime performance through whole-program analysis and cross-module optimization (highly recommended).</flag>

     

  • 1.12, Аноним (13), 11:52, 16/12/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    >Mold написан на языке С++ (C++20) и распространяется под лицензией AGPLv3

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

     
     
  • 2.17, x3who (?), 12:29, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Тогда никто не подсядет
     

  • 1.27, Аноним (27), 15:55, 16/12/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    ржавчина, плесень... кишечные паразиты на очереди?
     
     
  • 2.28, Аноним (-), 16:05, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    символично и с издевкой закапывать опенсорс не запретишь
     
  • 2.31, kusb (?), 16:53, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Хероптериксы
     
     
  • 3.39, Хероптерикс (?), 18:32, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Я бы попросил!
     
  • 2.127, burjui (ok), 10:39, 20/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Это другое. Вот гнили ещё не было. Кстати, ничего так название - rot, осталось только придумать проект.
     

  • 1.33, Андрей (??), 17:31, 16/12/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Зачем было создавать новый проект, если можно было ускорить какой-нибудь старый, тем более что тогда это быстрее принесло плоды. В остальном очень интересует - а не диким ли распараллеливанием выигрыш достигается ? Ведь если так и если остальные компоновщики просто долбят однопоток..., то тогда опять же зачем было изобретать велосипед, если можно было добавить колёс старому ?
     
     
  • 2.34, Аноним (7), 17:52, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Андрей, привет. Трехколесный велосипед медленнее двухколесного. Пока, Андрей.
     
     
  • 3.35, Мохнатый пись (?), 18:01, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Почему тогда автомобили на четырёх колёсах в основной массе, а не хотябы трёх?
     
     
  • 4.38, Аноним (7), 18:23, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Думаешь если добавить к ним еще парочку колес, они станут быстрее? Напоминаю, что больше 4 колес обычно имеют всякие грузовики. А в будущем все колеса уберут, потому что машины будут летающими.
     
     
  • 5.43, Аноним (42), 20:00, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    А почему у самолётов и вертолётов не уберут колёса?
     
     
  • 6.82, x3who (?), 14:27, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Нужны для совместимости с автомобилями.
     
  • 4.40, Аноним (-), 19:11, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >Почему тогда автомобили на четырёх колёсах в основной массе, а не хотябы трёх?

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

     
  • 4.44, funny.falcon (?), 20:18, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Мотоцикл можно назвать автомобилем на двух колёсах. И при одинаковой мощности двигателя, мотоцикл обычно быстрее (если сравнивать лучшие модели).

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

     
     
  • 5.59, _ (??), 00:08, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Дополнительные колёса (если употребить всю упаковку сразу) дают чуЙство гениальности :)
    И вот ты уже объясняешь на оппа-нете чем мацатыкал от бибики отличается :)
     
  • 2.66, Ordu (ok), 04:20, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > В остальном очень интересует - а не диким ли распараллеливанием выигрыш достигается ? Ведь если так и если остальные компоновщики просто долбят однопоток..., то тогда опять же зачем было изобретать велосипед, если можно было добавить колёс старому ?

    Если выигрыш достигается диким распараллеливанием, то сам бог велел делать это новым проектом. Распараллелить программу, написанную под однопоток -- это гарантированно получить тысячи memleak'ов, use-after-free, data-races, race-conditions и прочих. Их будет столько, что ты никогда их не одолеешь, годами будешь сидеть отлавливать, и никогда не отловишь все.

     
     
  • 3.128, burjui (ok), 10:44, 20/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Не говоря уж о том, что существующие линкеры поддерживают куда больше архитектур, даже старых и ненужных, и переписывать пришлось бы огромное количество кода. А в mold всего 3, что намного проще для proof-of-concept и первого релиза.
     
  • 2.84, all_glory_to_the_hypnotoad (ok), 15:28, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Часто чтобы просто донести патч до апстрима в СПО проектах нужно ждать несколько лет пока правильно расставишь скобочки, напишешь кучу тестов и сделаешь три раза Ку перед мейнтейнером. А с радикальными переработками процесс вообще может никогда не сойтись.
     
     
  • 3.126, Crazy Alex (ok), 20:29, 19/12/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Насчёт "ку" - такое возникает ровно в двух случаях: либо апстрим мёртв либо ты пытаешься рассказать "как надо" и это с точкой зрения апстрима вообще никак не совпадает.

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

     

  • 1.37, eganru (?), 18:11, 16/12/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Не так давно сталкивался с особенностями работы lld: как оказалось, он в силу однопроходной архитектуры не может работать с r_riscv_align.

    Переключив линкер с lld на gnu ld я обнаружил, что у них немного разный синтаксис.

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

    Страшно если в итоге получим n линковщиков с разными функциональностью и синтаксисом.

     
     
  • 2.49, Аноним (46), 21:30, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я кстати не вижу сравнения с bfd. Gold всегда славился своими дорогостоящими оптимизациями (LTO), для чего он и был придуман изначально, но он мало совместим с современным софтом. Ядро кстати тоже не собирается больше голдом, он давно мёртв, и это финиш. Не могу придумать причин использовать ldd.
     
     
  • 3.50, Аноним (46), 21:30, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >ldd

    lld конечно

     
     
  • 4.57, Аноним (57), 23:39, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    lldilldo
     

  • 1.41, Аноним (41), 19:51, 16/12/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    О да, для сборки хипстерских WebAssembly, где сплошные статические библиотеки линкуются в один мегаэкзешик и уходят на это целые минуты, новый линковщик в замен тормозного lld будет очень кстати!

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

     
     
  • 2.53, Аноним (53), 22:24, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы хромом на десктопе пользуетесь? Вот его сборка в т числе и ускорилась.
     
     
  • 3.55, Аноним (54), 22:48, 16/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    А что, хромом уже нельзя пользоваться, если не собрал сам на своём десктопе?
     
     
  • 4.87, Аноним (53), 17:59, 17/12/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    С таким подходом можно ничем не заниматься. Можно пользоваться уже написанными скомпилированными программами. Зачем развивать языки программирование, ИДЕ и компиляторы?
     

  • 1.56, Аноним (-), 23:00, 16/12/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    С++20 конечно рулит, но такая вещь, как плесень, просто обязана быть на ржавчене, как же иначе?
     
  • 1.58, szt1980 (ok), 00:00, 17/12/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Проект признан готовым для рабочих внедрений и может применяться в качестве более быстрой прозрачной замены GNU linker на Linux-системах

    Точно готов? И поехавшие линкер-скрипты работают? А если проверить?

     
  • 1.63, Аноним (63), 03:03, 17/12/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    И снова не на расте)) лол
     
  • 1.64, Аноним (63), 03:04, 17/12/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Растом то вообще хоть кто-то пользуется?
     
  • 1.83, all_glory_to_the_hypnotoad (ok), 15:24, 17/12/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > GNU gold тратится 53 секунды, LLVM lld - 11.7 секунд, а Mold всего 2.2 секунды ... распространяется под лицензией AGPLv3 ... Подобный выбор объясняется желанием получить финансирование разработки

    Все просто будут использовать lld ибо 3 сек по сравнению с 12 не такой большой профит как 12 с 53.

     
     
  • 2.107, Ordu (ok), 09:10, 18/12/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это _огромный_ бонус, если ты вносишь мелкие правки в сорцы, компилируешь, запускаешь, смотришь что получается, вносишь ещё какие-то правки. Три секунды задержки -- это слегка раздражающая вещь, 12 секунд задержки -- это повод встать и пойти за чаем. 53 секунды -- это просто ппц, это повод менять методологию программирования, снижая частоту пересборок.
     
     
  • 3.132, Аноним (-), 08:43, 23/12/2021 [^] [^^] [^^^] [ответить]  
  • +/
    А с lto оно как работает? А то на lto все тормозят, однако оптимизации крутые, кучу кода удаляет без каких либо побочных эффектов. И компилять с отдельными дебажно девеловскими опциями это фуфу, вылезает иногда нежданчиками.
     

  • 1.131, Аноним (-), 08:41, 23/12/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > автор готов продать права на код для перелицензирования под разрешительной лицензией,
    > такой как MIT, или предоставить отдельную коммерческую лицензию для тех, кого не устраивает AGPL.

    Правильный подход к корпорациям и менеджерской швали :)

     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру