The OpenNET Project / Index page

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



"Первый стабильный релиз компоновщика Mold, развиваемого разработчиком LLVM lld"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Первый стабильный релиз компоновщика Mold, развиваемого разработчиком LLVM lld"  +/
Сообщение от opennews (??), 16-Дек-21, 11:14 
Rui Ueyama, автор компоновщика LLVM lld и компилятора chibicc, представил первый стабильный релиз нового высокопроизводительного компоновщика Mold, заметно опережающего по скорости  связывания объектных файлов компоновщики GNU gold и LLVM lld. Проект признан готовым для рабочих внедрений и может применяться в качестве более быстрой прозрачной замены GNU linker на Linux-системах. Из планов на следующий значительный выпуск отмечается доведение до готовности поддержки платформы macOS, после чего начнётся работа по адаптации Mold для Windows...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=56358

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  –43 +/
Сообщение от Анонимemail (1), 16-Дек-21, 11:14 
> Mold написан на языке С++ (C++20)

печально

Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

9. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  –6 +/
Сообщение от Аноним (-), 16-Дек-21, 11:48 
c++20 это в твоем понимании правильный яп ?
Ответить | Правка | Наверх | Cообщить модератору

19. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +14 +/
Сообщение от AnalMal (?), 16-Дек-21, 13:02 
Да, правильный. Но никто не запрещает писать тебе писать на С++98
Ответить | Правка | Наверх | Cообщить модератору

24. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  –2 +/
Сообщение от Аноним (-), 16-Дек-21, 14:33 
> Но никто не запрещает писать тебе писать на С++98

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

Ответить | Правка | Наверх | Cообщить модератору

6. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +4 +/
Сообщение от Аноним (6), 16-Дек-21, 11:27 
>печально

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

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

21. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +8 +/
Сообщение от Анонимemail (1), 16-Дек-21, 13:08 
да, код на Си намного читабельнее кода на современном C++
Ответить | Правка | Наверх | Cообщить модератору

46. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +3 +/
Сообщение от Аноним (46), 16-Дек-21, 20:49 
Увы, но, современный код на си, даже при том, что читабельный сам по себе, заставляет городить невообразимые тонны нечитаемого бойлерплейта, который ещё и еггог проне. У меня не получается сделать корректно и не превратить либо в лапшу либо в 1000 этажные инлайны с препроцессором. Для высокоуровневых задач плючи всё же намного лучше, кроме того есть уже нормальные стандартные реализации для многих вещей и их обычно достаточно. Особенно современные. Когда хватает самой примитивной работы с байтами, тут да, си вне конкуренции (и то придётся обмазаться расширениями). Интероп опять же намного более годный на мой взгляд тоже в си.
Ответить | Правка | Наверх | Cообщить модератору

71. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  –1 +/
Сообщение от Аноним (-), 17-Дек-21, 08:56 
Если у тебя "1000 этажные инлайны с препроцессором", то в этом виноват только ты сам. Не умеешь организовывать код. GTK писан на чистом Си, а сам код чётко структурирован как ООП.

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

Ответить | Правка | Наверх | Cообщить модератору

106. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +6 +/
Сообщение от мое правило (?), 18-Дек-21, 00:19 
Только чет он так круто организованный, что гномьи авторы придумали vala, только что бы не писать на всратом с.
Ответить | Правка | Наверх | Cообщить модератору

65. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +2 +/
Сообщение от Аноним (65), 17-Дек-21, 03:06 
Замечательно, что не на С, а на С++20. И разработка быстрее, и код читабельнее, и производительность на высоте. А С-луддитам пора выйти из зоны комфорта и выучить, наконец, С++.

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

80. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (80), 17-Дек-21, 13:07 
Только какой в этом смысл, если за питон больше платят?
Ответить | Правка | Наверх | Cообщить модератору

88. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +2 +/
Сообщение от Ананас (?), 17-Дек-21, 18:05 
Что, аж две миски?
Ответить | Правка | Наверх | Cообщить модератору

89. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (65), 17-Дек-21, 18:06 
Сомневаюсь что-то. Можно пруфлинк?
Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

102. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (80), 17-Дек-21, 21:31 
https://leonardo.osnova.io/6f458341-e3ff-5373-907e-f19f5a231.../
Не то чтобы сильно больше, но дорасти до большей зп на питоне можно быстрее, так что профита больше учить питон, а не дидовские кресты.
Ответить | Правка | Наверх | Cообщить модератору

103. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (80), 17-Дек-21, 21:33 
А если питонщик умеет ещё и на сях лабать, то у него есть хороший шанс стать незаменимым, попадя в правильно место)
Ответить | Правка | Наверх | Cообщить модератору

104. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +1 +/
Сообщение от Аноним (80), 17-Дек-21, 21:33 
А если питонщик умеет ещё и на сях лабать, то у него есть хороший шанс стать незаменимым, попадя в правильно место)
Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

114. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +1 +/
Сообщение от Аноним (65), 18-Дек-21, 18:12 
Это что, шутка какая-то? Во-первых, по ссылке зарплата на Python и на С++ абсолютно одинаковая, а не просто "не сильно больше". Во-вторых, цифры неправдоподобные. Зарплата программиста 130 000 рублей? Это одних джунов и студентов опрашивали что ли? Я ожидал увидеть цифры в районе 400 000. В-третьих, что за сайт левый такой и только картинка, почему не дать ссылку на оригинал, статью на Хабре? Наверное потому что там уже напихали авторше в панамку по поводу совершенно неправдоподных цифр?
Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

116. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (80), 18-Дек-21, 20:53 
> Я ожидал увидеть цифры в районе 400 000.

На hh.ru если выставить фильтр на 400+, вакансий для питонистов 262 находится, а для с++ 125.

Ответить | Правка | Наверх | Cообщить модератору

117. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (65), 18-Дек-21, 23:03 
Ну и что, это же не показатель средней зарплаты. Если так любишь hh.ru, вот тебе статья про высокооплачиваемые работы:

https://hh.ru/article/28335

C++ там в первом разделе в топе, а Питон в последнем разделе на последнем месте.

И погоди, а то что ты лажанулся с каким-то там leonardo.osnova.io уже как бы и не считается? Признать своё лажание не хочешь?

Ответить | Правка | Наверх | Cообщить модератору

119. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (80), 19-Дек-21, 11:55 
> ты лажанулся

Что за агрессия? Ты приплюснутый что ли82808 и тебя это задело? Средняя зп по методике расчёта это float, если ты считаешь что из 2х float с одинаковой целой частью один не может быть быть больше, а другой меньше, то у меня для тебя плохие новости.
> C++ там в первом разделе в топе, а Питон в последнем разделе на последнем месте.

И что мне это должно сказать? За "топовую" вакансию на плюсах и 400к не предложили, тогда как на питоне таких по 400+ 262 шт находится.

Ответить | Правка | Наверх | Cообщить модератору

120. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (65), 19-Дек-21, 19:27 
Просто непонятно как говорить с человеком, который то "забывает" свои предыдущие несостоявшиеся аргументы, то передёргивает и сравнивает цифры из разных статей. Наверное никак.
Ответить | Правка | Наверх | Cообщить модератору

68. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от n00by (ok), 17-Дек-21, 08:11 
>>печально
> Да, жаль, что не на Си.

Ну почему же

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;
}

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

93. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (-), 17-Дек-21, 19:08 
> Ну почему же
> std::string get_realpath(std::string_view path) {
>   char buf[8192];
>   return buf;

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

Ответить | Правка | Наверх | Cообщить модератору

95. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (65), 17-Дек-21, 19:40 
Да, будет копирование. Но его можно было бы избежать, сделав buf изначально типа std::string и передавая buf.data() в realpath().

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

Ответить | Правка | Наверх | Cообщить модератору

98. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (-), 17-Дек-21, 20:33 
> В Java и Python строки неизменяемые, там любое изменение строковой переменной это создание нового строкового объекта, ещё дороже получается.

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


Ответить | Правка | Наверх | Cообщить модератору

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

Ответить | Правка | Наверх | Cообщить модератору

96. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (65), 17-Дек-21, 19:52 
> копирование ... которого не будет в си

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

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

Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

97. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (-), 17-Дек-21, 20:17 
>> копирование ... которого не будет в си
> А в С был бы возврат указателя на локальный буфер в функции,
> где после выхода из функции и вызова парочки других функций,

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

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

Ответить | Правка | Наверх | Cообщить модератору

99. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (65), 17-Дек-21, 20:45 
Такое неявное конструирование объектов очень удобно. И это не является какой-то секретной фичей, это базовая фича, о которой знают все программисты С++. Можно конструировать явно, std::string(buf) является валидной конструкцией. Можно пометить конструктор как explicit, тогда неявное конструирование будет запрещено.

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

Ответить | Правка | Наверх | Cообщить модератору

105. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (-), 17-Дек-21, 22:04 
> Такое неявное конструирование объектов очень удобно. И это не является какой-то секретной
> фичей, это базовая фича, о которой знают все программисты С++.

(Не)явное удобство явно переоцененно, но это вкусовщина, о которой я не вижу смысла спорить.

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

Не соглашусь. Это - игра словами (просто потому что нет ключевого слова return).
Основной момент: там, где нет return и возвращается последнее выражение - все вполне себе явно. Тем более, функциональный стиль, сопоставление с образцом и "все есть выражение" (expression), с упрятыванием "не-выражений" с побочными эффектами - куда подальше в монады и ко, (т.е. еще и код структурированн по другому).

Для "императивных" ЯП тут вспоминается "single entry, single exit" из "древнего" "structured programming".

Неявно - это к ЯП, где возможен и явный "return foo" и возврат последнего выражения (например ruby, rust - где есть "типа фунциональщина и сбоку бантик").

Ответить | Правка | Наверх | Cообщить модератору

109. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +1 +/
Сообщение от n00by (ok), 18-Дек-21, 09:18 
>> копирование ... которого не будет в си
> А в С был бы возврат указателя на локальный буфер в функции,

Смотрим man 3 realpath

       char *realpath(const char *path, char *resolved_path);

...

       Получившееся  имя  сохраняется  в  виде  строки (с null на конце) не длиннее чем PATH_MAX байт в
       буфере, указанном в resolved_path. Конечный путь не содержит символьных ссылок и компонентов /./
       или /../.

       Если  значение  resolved_path  равно NULL, то realpath() выделяет буфер размером PATH_MAX байт с
       помощью malloc(3) для хранения полного пути и возвращает указатель  на  этот  буфер.  Вызывающий
       должен освободить буфер с помощью free(3).

Т.е. в Си убрали бы char buf[8192] и вернули указатель на кучу.

Что бы в Си++ не заниматься крохоборством с магическими числами вместо PATH_MAX, можно было конструировать std::string из аллоцированого ф-цией realpath() результата?

Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

115. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (65), 18-Дек-21, 18:54 
> Т.е. в Си убрали бы char buf[8192] и вернули указатель на кучу.

В таком случае вызывающий get_realpath() должен деаллоцировать результат с помощью free(). А что если get_realpath() вернёт не результат realpath(), a path, полученный параметром? Он то вообще непонятно где находится и как аллоцирован. Тогда мы имеем или double free, или попытку сделать free() на указатель на стеке. С сопутствующими проблемами безопасности. Значит нельзя просто возвращать path, а надо сделать ему strdup(), получается одно копирование заменили на другое. Ты можешь сказать, ну тогда надо менять всю функцию, чтоб копирования не было. Или вообще её убрать и те 2-4 строчки в вызывающий код вписать. Но тогда можно и на С++ тоже функцию полностью переписать "по правильному". И вообще теряется весь предмет разговора.

> Что бы в Си++ не заниматься крохоборством с магическими числами вместо PATH_MAX, можно было конструировать std::string из аллоцированого ф-цией realpath() результата?

Да, запросто.

Ответить | Правка | Наверх | Cообщить модератору

118. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от n00by (ok), 19-Дек-21, 10:26 
>> Т.е. в Си убрали бы char buf[8192] и вернули указатель на кучу.
> В таком случае вызывающий get_realpath() должен деаллоцировать результат с помощью free().

Да. Точно так же в Си++ будет деаллоцирован буфер std:string. Только в Си все освобождения явны.

> А что если get_realpath() вернёт не результат realpath(), a path, полученный
> параметром? Он то вообще непонятно где находится и как аллоцирован. Тогда
> мы имеем или double free, или попытку сделать free() на указатель
> на стеке. С сопутствующими проблемами безопасности. Значит нельзя просто возвращать path,
> а надо сделать ему strdup(), получается одно копирование заменили на другое.
> Ты можешь сказать, ну тогда надо менять всю функцию, чтоб копирования
> не было. Или вообще её убрать и те 2-4 строчки в
> вызывающий код вписать.

Ну да, в Си эта обёртка вроде как совсем не нужна.

> Но тогда можно и на С++ тоже функцию
> полностью переписать "по правильному". И вообще теряется весь предмет разговора.

Так и я о том. Вроде как переписали на Си++, но наполовину, в итоге там потенциально буфер переполняется.

>> Что бы в Си++ не заниматься крохоборством с магическими числами вместо PATH_MAX, можно было конструировать std::string из аллоцированого ф-цией realpath() результата?
> Да, запросто.

В общем, непонятна экономия. Если есть имя файла, значит его будут читать, а это всю "оптимизацию" с кучей перевесит.

Ответить | Правка | Наверх | Cообщить модератору

122. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (65), 19-Дек-21, 20:10 
> Только в Си все освобождения явны.

Хм, так пишешь, как будто это хорошо. Явны, значит замусоривают код и заставляют программиста всё деаллоцировать вручную, т.е. лишают автоматизации, заставляют следить чтобы и не забыть про деаллокацию, и чтобы она больше одного раза не произошла.

> Вроде как переписали на Си++, но наполовину,
> в итоге там потенциально буфер переполняется.

Да, не очень хорошо получилось. Но код на стыке языков часто таким бывает. Я не про потенциальное переполнение буфера, а просто про элегантность. Да и get_realpath() - это по сути С++ wrapper вокруг сишного API realpath(), а к врапперам требования по элегантности снижены, врапперы как раз и призваны локализовать неэлегантность в себе, предоставляя удобное API наружу.

Ответить | Правка | Наверх | Cообщить модератору

129. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от n00by (ok), 20-Дек-21, 11:25 
>> Только в Си все освобождения явны.
> Хм, так пишешь, как будто это хорошо. Явны, значит замусоривают код и
> заставляют программиста всё деаллоцировать вручную, т.е. лишают автоматизации, заставляют
> следить чтобы и не забыть про деаллокацию, и чтобы она больше
> одного раза не произошла.

Так там кто-то хотел на Си, значит для него это хорошо.

>> Вроде как переписали на Си++, но наполовину,
>> в итоге там потенциально буфер переполняется.
> Да, не очень хорошо получилось. Но код на стыке языков часто таким
> бывает. Я не про потенциальное переполнение буфера, а просто про элегантность.
> Да и get_realpath() - это по сути С++ wrapper вокруг сишного
> API realpath(), а к врапперам требования по элегантности снижены, врапперы как
> раз и призваны локализовать неэлегантность в себе, предоставляя удобное API наружу.

Есть же std::filesystem::canonical().

Ответить | Правка | Наверх | Cообщить модератору

110. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +1 +/
Сообщение от n00by (ok), 18-Дек-21, 09:21 
>> Ну почему же
>> std::string get_realpath(std::string_view path) {
>>   char buf[8192];
>>   return buf;
> Тут "спрятанно" какое-то копирование buf в возвращаемый std::string (которого не будет
> в си)?

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

Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

13. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  –2 +/
Сообщение от Аноним (13), 16-Дек-21, 11:53 
Ну возьми да перепиши на раст.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

15. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +8 +/
Сообщение от x3who (?), 16-Дек-21, 12:27 
Точно, плесень надо писать на ржавчине
Ответить | Правка | Наверх | Cообщить модератору

18. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +1 +/
Сообщение от Аноним (18), 16-Дек-21, 12:58 
Обрати внимание на исходники GCC, там уже много файликов на С++. Брат жив.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

22. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  –3 +/
Сообщение от Аноним (22), 16-Дек-21, 13:25 
Это говорит только о том, что gcc -- не очень хороший компилятор
Ответить | Правка | Наверх | Cообщить модератору

25. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (-), 16-Дек-21, 14:35 
> о том, что gcc -- не очень хороший компилятор

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

Ответить | Правка | Наверх | Cообщить модератору

42. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +3 +/
Сообщение от Аноним (42), 16-Дек-21, 19:57 
> Это говорит только о том, что gcc -- не очень хороший компилятор

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

Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

74. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (18), 17-Дек-21, 11:52 
А Шланг*, по этой логике, получается лучше?

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

Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

23. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от _kp (ok), 16-Дек-21, 14:21 
>>печально

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

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

30. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  –3 +/
Сообщение от Аноним (80), 16-Дек-21, 16:24 
Если глянуть исходники, там типичная сишка по сути. Вот например: https://github.com/rui314/mold/blob/main/elf/arch-x86-64.cc
даже stl не используется.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

32. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +2 +/
Сообщение от Аноним (32), 16-Дек-21, 16:57 
ловите питониста, не различает си и си++
Ответить | Правка | Наверх | Cообщить модератору

52. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (-), 16-Дек-21, 22:11 
кстати заметьте как ускорено дропают поддержку 32х бит арма
Ответить | Правка | Наверх | Cообщить модератору

75. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +1 +/
Сообщение от Аноним (18), 17-Дек-21, 11:57 
Так он микроконтроллерах только и остался.
Ответить | Правка | Наверх | Cообщить модератору

121. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (-), 19-Дек-21, 19:41 
это тебе в отделе маркетинга подсказали ?
Ответить | Правка | Наверх | Cообщить модератору

60. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (60), 17-Дек-21, 00:27 
> template <>
> void GotPltSection<X86_64>::copy_buf(Context<X86_64> &ctx) {

Рили?

Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

61. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (80), 17-Дек-21, 00:42 
То что обычные сишные процедуры зачем-то в виде шаблонов оформлены, сути не меняет. Там за вечер этот 1% кода выкинуть можно и заменить сишными вызовами процедур и будет 100% сишка. А так пока 99% си 1% си++.
Ответить | Правка | Наверх | Cообщить модератору

69. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от n00by (ok), 17-Дек-21, 08:15 
> То что обычные сишные процедуры зачем-то в виде шаблонов оформлены

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

    u8 *loc = base + rel.r_offset;

/// ...

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

/// ...

      write8(S + A);

Ответить | Правка | Наверх | Cообщить модератору

72. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (80), 17-Дек-21, 08:56 
> auto write8 = [&](u64 val) {

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

Ответить | Правка | Наверх | Cообщить модератору

76. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (65), 17-Дек-21, 12:24 
Только тогда теряется либо совместимость со стандартом, либо типобезопасность.
Ответить | Правка | Наверх | Cообщить модератору

79. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (18), 17-Дек-21, 12:58 
-stg=gnu99
Ответить | Правка | Наверх | Cообщить модератору

90. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +2 +/
Сообщение от Аноним (65), 17-Дек-21, 18:08 
Вот и я про тоже. Нестандартные расширения GNU.
Ответить | Правка | Наверх | Cообщить модератору

78. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от n00by (ok), 17-Дек-21, 12:36 
Наверное, я что-то уловил, но зачем там вообще лямбда. Вызывается однократно в теле той же функции, где определена.

    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


Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

91. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (65), 17-Дек-21, 18:11 
Может раньше неоднократно вызывалась, потом другие вызовы убрали. Да много причин может быть
Ответить | Правка | Наверх | Cообщить модератору

92. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от n00by (ok), 17-Дек-21, 18:36 
Многократно вызывается write32s. Там switch и write8 вызывается для R_X86_64_8. Больше, вроде, нет подходящих типов релоков. Далее идут прямые записи вида *(u64 *)loc = S + A; Вероятно, изначально хотел единообразие, но потом устал эти лямбды писать на каждый чих.
Ответить | Правка | Наверх | Cообщить модератору

108. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +1 +/
Сообщение от Ordu (ok), 18-Дек-21, 09:17 
> Интересно, зачем?

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

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

Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

111. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от n00by (ok), 18-Дек-21, 09:47 
Неудачно процитировал, лучше весь код смотреть. Хотя бы это:

    switch (rel.r_type) {
    case R_X86_64_8:
      write8(S + A);
      continue;
    case R_X86_64_16:
      write16(S + A);
      continue;
    case R_X86_64_32:
      write32(S + A);
      continue;
    case R_X86_64_32S:
      write32s(S + A);
      continue;
    case R_X86_64_64:
      *(u64 *)loc = S + A;
      continue;
    case R_X86_64_PC8:
      write8s(S + A - P);
      continue;
    case R_X86_64_PC16:
      write16s(S + A - P);
      continue;
    case R_X86_64_PC32:
      write32s(S + A - P);
      continue;
    case R_X86_64_PC64:
      *(u64 *)loc = S + A - P;
      continue;
    case R_X86_64_PLT32:
      write32s(S + A - P);
      continue;
    case R_X86_64_GOT32:
      write32s(G + A);
      continue;
    case R_X86_64_GOT64:
      *(u64 *)loc = G + A;
      continue;

На остальное автор перестал писать лямбды. Наверное, устал мотать экран туда-сюда. :)
write8, насколько понимаю формат, негде больше переиспольовать.

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

Вариант. И switch так красивее - все case по три строчки.

Ответить | Правка | Наверх | Cообщить модератору

112. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (80), 18-Дек-21, 15:39 
И switch так красивее - все case по три строчки.
Не, красивее было бы вместо rel.r_type передать указатель на функцию соответствующего write...() и свитч не нужен был бы.
Ответить | Правка | Наверх | Cообщить модератору

113. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +1 +/
Сообщение от n00by (ok), 18-Дек-21, 16:53 
rel.r_type читается из объектника, а указатель откуда возьмётся?
Ответить | Правка | Наверх | Cообщить модератору

123. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Crazy Alex (ok), 19-Дек-21, 20:15 
Ну, в принципе если проверку вадиности значения отдельно вынести - можно и по табличке сделать, но подозреваю, что кода будет больше, маинтайнить станет менее удобно, а толку - никакого, этот свитч, скорее всего, во что-то подобное компилятором и будет преобразован
Ответить | Правка | Наверх | Cообщить модератору

101. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +1 +/
Сообщение от Аноним (65), 17-Дек-21, 21:18 
> template <>
> void GotPltSection<X86_64>::copy_buf(Context<X86_64> &ctx) {
> Рили?

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

Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

73. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (73), 17-Дек-21, 09:47 
Какой-то трешекод. Вообще ничего не понятно - одни магические константы вхардкожены. У нас бы он код ревью не прошел. 🤣
Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

81. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  –2 +/
Сообщение от Аноним (80), 17-Дек-21, 13:10 
> ничего не понятно

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

Ответить | Правка | Наверх | Cообщить модератору

94. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (65), 17-Дек-21, 19:14 
> Вообще ничего не понятно

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

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

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

Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

2. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  –4 +/
Сообщение от Аноним (-), 16-Дек-21, 11:16 
> может применяться

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

Ответить | Правка | Наверх | Cообщить модератору

3. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (-), 16-Дек-21, 11:17 
А парень не промах. Сначала наковырял lld потом сделал mold и вышел в профит. Красавчик.
Интересно, а правильно ли он компонует ? Новые баги добавляет ?
Ответить | Правка | Наверх | Cообщить модератору

20. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Адмирал Майкл Роджерс (?), 16-Дек-21, 13:08 
> Новые баги добавляет ?

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

Ответить | Правка | Наверх | Cообщить модератору

26. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Генерал Пол Накасоне (?), 16-Дек-21, 15:52 
Кем вы себя возомнили?
Ответить | Правка | Наверх | Cообщить модератору

29. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +2 +/
Сообщение от Пал Ко Водетс (?), 16-Дек-21, 16:13 
Директорский состав Каспийского моря. Ваши документы пожалуйста
Ответить | Правка | Наверх | Cообщить модератору

36. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +1 +/
Сообщение от макпыф (ok), 16-Дек-21, 18:06 
> Интересно, а правильно ли он компонует ? Новые баги добавляет ?

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

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

45. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (46), 16-Дек-21, 20:36 
Ты случаем не мейнтейнер рача?
Ответить | Правка | Наверх | Cообщить модератору

47. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от макпыф (ok), 16-Дек-21, 21:16 
> Ты случаем не мейнтейнер рача?

Нет

Ответить | Правка | Наверх | Cообщить модератору

48. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (46), 16-Дек-21, 21:24 
> Нет

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

Ответить | Правка | Наверх | Cообщить модератору

51. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от макпыф (ok), 16-Дек-21, 21:39 
> У них такая же политика "собралось значит работает".

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

Ответить | Правка | Наверх | Cообщить модератору

5. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  –5 +/
Сообщение от Аноним12345 (?), 16-Дек-21, 11:23 
Адовы муки статических языков
Ответить | Правка | Наверх | Cообщить модератору

7. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +12 +/
Сообщение от Аноним (7), 16-Дек-21, 11:40 
программа либо разрабатывается быстро, либо работает быстро. Привыкай, мой юный кодер пробельчиками.
Ответить | Правка | Наверх | Cообщить модератору

11. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +1 +/
Сообщение от Анонимemail (1), 16-Дек-21, 11:50 
> программа либо разрабатывается быстро, либо работает быстро, но только если разработана с умом

fixed

Ответить | Правка | Наверх | Cообщить модератору

62. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +3 +/
Сообщение от bergentroll (ok), 17-Дек-21, 01:05 
А если без ума, то и разрабатывается быстро, и работает быстро. Но такая чушь получается!
Ответить | Правка | Наверх | Cообщить модератору

67. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Простоникemail (ok), 17-Дек-21, 07:35 
Если бы это было так, мир был бы прекрасен. Но увы мы видим программы, которые разрабатываются за непредсказуемое, часто очень длительное время, многократно превышающее первоначальные планы, медленно работающие,  содержащие массу ошибок, включающие утечки памяти. Здравствуй Rust.
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

8. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +7 +/
Сообщение от Аноним (8), 16-Дек-21, 11:42 
Там, где на этапе компоновки заканчиваются муки статических языков, начинаются муки динамических погромистов.
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

54. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (54), 16-Дек-21, 22:46 
Вы давно указатель на null проверяли?
Ответить | Правка | Наверх | Cообщить модератору

70. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от n00by (ok), 17-Дек-21, 08:26 
Указатель на Хиндли-Милнера?
Ответить | Правка | Наверх | Cообщить модератору

77. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +4 +/
Сообщение от Аноним (65), 17-Дек-21, 12:29 
После проверки на None не забудьте ещё проверить тип переменной
Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

124. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +1 +/
Сообщение от Crazy Alex (ok), 19-Дек-21, 20:23 
Нахрена мне умный указатель проверять? Он либо содержит то, что должен либо не существует вместе со своим объектом-владельцем. Ну либо код писал идиот, а ревьюили задницей и позволили кому-то писать си-стайл.
Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

10. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (10), 16-Дек-21, 11:49 
так вроде бОльшая проблема это сама трансляция сколько сама сборка этих двух гиговых файлов происходит? Там ведь бесконечное дёрганье заголовков подстановка и трансляция их каждый раз
Ответить | Правка | Наверх | Cообщить модератору

14. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +2 +/
Сообщение от nobody (??), 16-Дек-21, 12:19 
В C++ это решили (решат) добавлением модулей
Ответить | Правка | Наверх | Cообщить модератору

86. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (86), 17-Дек-21, 17:50 
Ну отличная новость хотя и спустя 38 лет с момента появления языка. В любом
случае еще подождем....

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

Ответить | Правка | Наверх | Cообщить модератору

16. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +4 +/
Сообщение от topin89 (ok), 16-Дек-21, 12:27 
Не совсем. На первой сборке очевидно, что на создание объектных файлов уйдёт много времени.
Потом правится и компилируется один .c/cpp файл в один объектный файл, и это быстро. А потом снова линковка сотен объектных файлов, и это медленно.
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

85. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (86), 17-Дек-21, 17:47 
Это требует определенной культуры и организации разработки, а так же в целом хорошей работы системы (локального времени) если я правильно помню как там происходит сравнение изменений файлов.
Ответить | Правка | Наверх | Cообщить модератору

125. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Crazy Alex (ok), 19-Дек-21, 20:26 
Линковка - тоже не сахар, как гентушник говорю :-) на райзене 3700X какой-нибудь хромиум линкуется несколько минут, ну и память жрёт гигабайтами. Тут даже интереснее, удалось ли по памяти эту штуку менее прожорливой сделать
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

130. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от n00by (ok), 20-Дек-21, 11:36 
Толку мало от 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>

Ответить | Правка | Наверх | Cообщить модератору

12. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  –2 +/
Сообщение от Аноним (13), 16-Дек-21, 11:52 
>Mold написан на языке С++ (C++20) и распространяется под лицензией AGPLv3

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

Ответить | Правка | Наверх | Cообщить модератору

17. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от x3who (?), 16-Дек-21, 12:29 
Тогда никто не подсядет
Ответить | Правка | Наверх | Cообщить модератору

27. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +2 +/
Сообщение от Аноним (27), 16-Дек-21, 15:55 
ржавчина, плесень... кишечные паразиты на очереди?
Ответить | Правка | Наверх | Cообщить модератору

28. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (-), 16-Дек-21, 16:05 
символично и с издевкой закапывать опенсорс не запретишь
Ответить | Правка | Наверх | Cообщить модератору

31. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от kusb (?), 16-Дек-21, 16:53 
Хероптериксы
Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

39. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Хероптерикс (?), 16-Дек-21, 18:32 
Я бы попросил!
Ответить | Правка | Наверх | Cообщить модератору

127. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от burjui (ok), 20-Дек-21, 10:39 
Это другое. Вот гнили ещё не было. Кстати, ничего так название - rot, осталось только придумать проект.
Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

33. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Андрей (??), 16-Дек-21, 17:31 
Зачем было создавать новый проект, если можно было ускорить какой-нибудь старый, тем более что тогда это быстрее принесло плоды. В остальном очень интересует - а не диким ли распараллеливанием выигрыш достигается ? Ведь если так и если остальные компоновщики просто долбят однопоток..., то тогда опять же зачем было изобретать велосипед, если можно было добавить колёс старому ?
Ответить | Правка | Наверх | Cообщить модератору

34. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (7), 16-Дек-21, 17:52 
Андрей, привет. Трехколесный велосипед медленнее двухколесного. Пока, Андрей.
Ответить | Правка | Наверх | Cообщить модератору

35. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Мохнатый пись (?), 16-Дек-21, 18:01 
Почему тогда автомобили на четырёх колёсах в основной массе, а не хотябы трёх?
Ответить | Правка | Наверх | Cообщить модератору

38. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (7), 16-Дек-21, 18:23 
Думаешь если добавить к ним еще парочку колес, они станут быстрее? Напоминаю, что больше 4 колес обычно имеют всякие грузовики. А в будущем все колеса уберут, потому что машины будут летающими.
Ответить | Правка | Наверх | Cообщить модератору

43. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (42), 16-Дек-21, 20:00 
А почему у самолётов и вертолётов не уберут колёса?
Ответить | Правка | Наверх | Cообщить модератору

82. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от x3who (?), 17-Дек-21, 14:27 
Нужны для совместимости с автомобилями.
Ответить | Правка | Наверх | Cообщить модератору

40. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (-), 16-Дек-21, 19:11 
>Почему тогда автомобили на четырёх колёсах в основной массе, а не хотябы трёх?

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

Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

44. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от funny.falcon (?), 16-Дек-21, 20:18 
Мотоцикл можно назвать автомобилем на двух колёсах. И при одинаковой мощности двигателя, мотоцикл обычно быстрее (если сравнивать лучшие модели).

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

Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

59. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от _ (??), 17-Дек-21, 00:08 
Дополнительные колёса (если употребить всю упаковку сразу) дают чуЙство гениальности :)
И вот ты уже объясняешь на оппа-нете чем мацатыкал от бибики отличается :)
Ответить | Правка | Наверх | Cообщить модератору

66. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +3 +/
Сообщение от Ordu (ok), 17-Дек-21, 04:20 
> В остальном очень интересует - а не диким ли распараллеливанием выигрыш достигается ? Ведь если так и если остальные компоновщики просто долбят однопоток..., то тогда опять же зачем было изобретать велосипед, если можно было добавить колёс старому ?

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

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

128. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от burjui (ok), 20-Дек-21, 10:44 
Не говоря уж о том, что существующие линкеры поддерживают куда больше архитектур, даже старых и ненужных, и переписывать пришлось бы огромное количество кода. А в mold всего 3, что намного проще для proof-of-concept и первого релиза.
Ответить | Правка | Наверх | Cообщить модератору

84. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok), 17-Дек-21, 15:28 
Часто чтобы просто донести патч до апстрима в СПО проектах нужно ждать несколько лет пока правильно расставишь скобочки, напишешь кучу тестов и сделаешь три раза Ку перед мейнтейнером. А с радикальными переработками процесс вообще может никогда не сойтись.
Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

126. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +1 +/
Сообщение от Crazy Alex (ok), 19-Дек-21, 20:29 
Насчёт "ку" - такое возникает ровно в двух случаях: либо апстрим мёртв либо ты пытаешься рассказать "как надо" и это с точкой зрения апстрима вообще никак не совпадает.

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

Ответить | Правка | Наверх | Cообщить модератору

37. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +1 +/
Сообщение от eganru (?), 16-Дек-21, 18:11 
Не так давно сталкивался с особенностями работы lld: как оказалось, он в силу однопроходной архитектуры не может работать с r_riscv_align.

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

49. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +1 +/
Сообщение от Аноним (46), 16-Дек-21, 21:30 
Я кстати не вижу сравнения с bfd. Gold всегда славился своими дорогостоящими оптимизациями (LTO), для чего он и был придуман изначально, но он мало совместим с современным софтом. Ядро кстати тоже не собирается больше голдом, он давно мёртв, и это финиш. Не могу придумать причин использовать ldd.
Ответить | Правка | Наверх | Cообщить модератору

50. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (46), 16-Дек-21, 21:30 
>ldd

lld конечно

Ответить | Правка | Наверх | Cообщить модератору

57. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (57), 16-Дек-21, 23:39 
lldilldo
Ответить | Правка | Наверх | Cообщить модератору

41. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  –2 +/
Сообщение от Аноним (41), 16-Дек-21, 19:51 
О да, для сборки хипстерских WebAssembly, где сплошные статические библиотеки линкуются в один мегаэкзешик и уходят на это целые минуты, новый линковщик в замен тормозного lld будет очень кстати!

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

Ответить | Правка | Наверх | Cообщить модератору

53. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +1 +/
Сообщение от Аноним (53), 16-Дек-21, 22:24 
Вы хромом на десктопе пользуетесь? Вот его сборка в т числе и ускорилась.
Ответить | Правка | Наверх | Cообщить модератору

55. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (54), 16-Дек-21, 22:48 
А что, хромом уже нельзя пользоваться, если не собрал сам на своём десктопе?
Ответить | Правка | Наверх | Cообщить модератору

87. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +1 +/
Сообщение от Аноним (53), 17-Дек-21, 17:59 
С таким подходом можно ничем не заниматься. Можно пользоваться уже написанными скомпилированными программами. Зачем развивать языки программирование, ИДЕ и компиляторы?
Ответить | Правка | Наверх | Cообщить модератору

56. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (-), 16-Дек-21, 23:00 
С++20 конечно рулит, но такая вещь, как плесень, просто обязана быть на ржавчене, как же иначе?
Ответить | Правка | Наверх | Cообщить модератору

58. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от szt1980 (ok), 17-Дек-21, 00:00 
>Проект признан готовым для рабочих внедрений и может применяться в качестве более быстрой прозрачной замены GNU linker на Linux-системах

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

Ответить | Правка | Наверх | Cообщить модератору

63. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (63), 17-Дек-21, 03:03 
И снова не на расте)) лол
Ответить | Правка | Наверх | Cообщить модератору

64. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (63), 17-Дек-21, 03:04 
Растом то вообще хоть кто-то пользуется?
Ответить | Правка | Наверх | Cообщить модератору

83. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok), 17-Дек-21, 15:24 
> GNU gold тратится 53 секунды, LLVM lld - 11.7 секунд, а Mold всего 2.2 секунды ... распространяется под лицензией AGPLv3 ... Подобный выбор объясняется желанием получить финансирование разработки

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

Ответить | Правка | Наверх | Cообщить модератору

107. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +2 +/
Сообщение от Ordu (ok), 18-Дек-21, 09:10 
Это _огромный_ бонус, если ты вносишь мелкие правки в сорцы, компилируешь, запускаешь, смотришь что получается, вносишь ещё какие-то правки. Три секунды задержки -- это слегка раздражающая вещь, 12 секунд задержки -- это повод встать и пойти за чаем. 53 секунды -- это просто ппц, это повод менять методологию программирования, снижая частоту пересборок.
Ответить | Правка | Наверх | Cообщить модератору

132. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (-), 23-Дек-21, 08:43 
А с lto оно как работает? А то на lto все тормозят, однако оптимизации крутые, кучу кода удаляет без каких либо побочных эффектов. И компилять с отдельными дебажно девеловскими опциями это фуфу, вылезает иногда нежданчиками.
Ответить | Правка | Наверх | Cообщить модератору

131. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (-), 23-Дек-21, 08:41 
> автор готов продать права на код для перелицензирования под разрешительной лицензией,
> такой как MIT, или предоставить отдельную коммерческую лицензию для тех, кого не устраивает AGPL.

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

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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