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
> Mold написан на языке С++ (C++20)печально
>при сборке Chrome 96 (размером кода 1.89 ГБ) на компоновку исполняемых файлов c debuginfo на 8-ядерном компьютере при использовании GNU gold тратится 53 секунды, LLVM lld - 11.7 секунд, а Mold всего 2.2 секунды (в 26 раз быстрее GNU gold).Вовсе не печально.
А у тебя есть альтернативы, которые работают быстрее сабжа и написанные на "правильном" ЯП?
c++20 это в твоем понимании правильный яп ?
Да, правильный. Но никто не запрещает писать тебе писать на С++98
> Но никто не запрещает писать тебе писать на С++98ты утверждаешь что это write-only язык ?
прочитай что написано в новости - проект на c++20
>печальноДа, жаль, что не на Си.
да, код на Си намного читабельнее кода на современном C++
Увы, но, современный код на си, даже при том, что читабельный сам по себе, заставляет городить невообразимые тонны нечитаемого бойлерплейта, который ещё и еггог проне. У меня не получается сделать корректно и не превратить либо в лапшу либо в 1000 этажные инлайны с препроцессором. Для высокоуровневых задач плючи всё же намного лучше, кроме того есть уже нормальные стандартные реализации для многих вещей и их обычно достаточно. Особенно современные. Когда хватает самой примитивной работы с байтами, тут да, си вне конкуренции (и то придётся обмазаться расширениями). Интероп опять же намного более годный на мой взгляд тоже в си.
Если у тебя "1000 этажные инлайны с препроцессором", то в этом виноват только ты сам. Не умеешь организовывать код. GTK писан на чистом Си, а сам код чётко структурирован как ООП.Не умеешь писать в процедурном стеле не лезь.
Только чет он так круто организованный, что гномьи авторы придумали vala, только что бы не писать на всратом с.
Замечательно, что не на С, а на С++20. И разработка быстрее, и код читабельнее, и производительность на высоте. А С-луддитам пора выйти из зоны комфорта и выучить, наконец, С++.
Только какой в этом смысл, если за питон больше платят?
Что, аж две миски?
Сомневаюсь что-то. Можно пруфлинк?
https://leonardo.osnova.io/6f458341-e3ff-5373-907e-f19f5a231.../
Не то чтобы сильно больше, но дорасти до большей зп на питоне можно быстрее, так что профита больше учить питон, а не дидовские кресты.
А если питонщик умеет ещё и на сях лабать, то у него есть хороший шанс стать незаменимым, попадя в правильно место)
А если питонщик умеет ещё и на сях лабать, то у него есть хороший шанс стать незаменимым, попадя в правильно место)
Это что, шутка какая-то? Во-первых, по ссылке зарплата на Python и на С++ абсолютно одинаковая, а не просто "не сильно больше". Во-вторых, цифры неправдоподобные. Зарплата программиста 130 000 рублей? Это одних джунов и студентов опрашивали что ли? Я ожидал увидеть цифры в районе 400 000. В-третьих, что за сайт левый такой и только картинка, почему не дать ссылку на оригинал, статью на Хабре? Наверное потому что там уже напихали авторше в панамку по поводу совершенно неправдоподных цифр?
> Я ожидал увидеть цифры в районе 400 000.На hh.ru если выставить фильтр на 400+, вакансий для питонистов 262 находится, а для с++ 125.
Ну и что, это же не показатель средней зарплаты. Если так любишь hh.ru, вот тебе статья про высокооплачиваемые работы:C++ там в первом разделе в топе, а Питон в последнем разделе на последнем месте.
И погоди, а то что ты лажанулся с каким-то там leonardo.osnova.io уже как бы и не считается? Признать своё лажание не хочешь?
> ты лажанулсяЧто за агрессия? Ты приплюснутый что ли82808 и тебя это задело? Средняя зп по методике расчёта это float, если ты считаешь что из 2х float с одинаковой целой частью один не может быть быть больше, а другой меньше, то у меня для тебя плохие новости.
> C++ там в первом разделе в топе, а Питон в последнем разделе на последнем месте.И что мне это должно сказать? За "топовую" вакансию на плюсах и 400к не предложили, тогда как на питоне таких по 400+ 262 шт находится.
Просто непонятно как говорить с человеком, который то "забывает" свои предыдущие несостоявшиеся аргументы, то передёргивает и сравнивает цифры из разных статей. Наверное никак.
>>печально
> Да, жаль, что не на Си.Ну почему же
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;
}
> Ну почему же
> std::string get_realpath(std::string_view path) {
> char buf[8192];
> return buf;Тут "спрятанно" какое-то копирование buf в возвращаемый std::string (которого не будет в си)?
Да, будет копирование. Но его можно было бы избежать, сделав buf изначально типа std::string и передавая buf.data() в realpath().Но это всё такое крохоборство походу. В Java и Python строки неизменяемые, там любое изменение строковой переменной это создание нового строкового объекта, ещё дороже получается. Программисты на других языках смотрят на этот подсчёт крох со смехом.
> В Java и Python строки неизменяемые, там любое изменение строковой переменной это создание нового строкового объекта, ещё дороже получается.Вообще-то, еще во втором питоне для "объемной" работы со строками были MutableString и StringIO, в Java - тот же StringBuffer.
Это всё так, но мы друг другу не противоречим. MutableString, StringIO и StringBuffer - это не строковые переменные. Это объекты, содержащие массивы байтов. В них надо загонять текстовые данные, копированием, а потом полученные строки в строковые переменные извлекать, тоже копированием. Двойное копирование то бишь. В С++ тоже такое есть, называется std::stringstream.
> копирование ... которого не будет в сиА в С был бы возврат указателя на локальный буфер в функции, где после выхода из функции и вызова парочки других функций, любой мусор оказаться может. Зато без копирования, да.
Это вообще распространённая проблема в С. Ошиблись при работе с памятью, потом из неправильного места в памяти читаем мусор и радостно исполняемся некоторое время, пока проблема не всплывёт вообще в другом месте кода. Трудно дебажить такое. В С++ такие ошибки встречаются гораздо реже.
>> копирование ... которого не будет в си
> А в С был бы возврат указателя на локальный буфер в функции,
> где после выхода из функции и вызова парочки других функций,Я в курсе, потому и спросил.
> Зато без копирования, да.Угу, зато есть такие вот неявные кунстштюки, вместо (условного) return str::string(buf).
Такое неявное конструирование объектов очень удобно. И это не является какой-то секретной фичей, это базовая фича, о которой знают все программисты С++. Можно конструировать явно, std::string(buf) является валидной конструкцией. Можно пометить конструктор как explicit, тогда неявное конструирование будет запрещено.А в функциональных языках вообще return неявный, возвращается последнее вычисленное выражение, тоже очень удобно, можно писать короткие функции как "a + b", без return.
> Такое неявное конструирование объектов очень удобно. И это не является какой-то секретной
> фичей, это базовая фича, о которой знают все программисты С++.(Не)явное удобство явно переоцененно, но это вкусовщина, о которой я не вижу смысла спорить.
> А в функциональных языках вообще return неявный, возвращается последнее вычисленное выражение,
Не соглашусь. Это - игра словами (просто потому что нет ключевого слова return).
Основной момент: там, где нет return и возвращается последнее выражение - все вполне себе явно. Тем более, функциональный стиль, сопоставление с образцом и "все есть выражение" (expression), с упрятыванием "не-выражений" с побочными эффектами - куда подальше в монады и ко, (т.е. еще и код структурированн по другому).Для "императивных" ЯП тут вспоминается "single entry, single exit" из "древнего" "structured programming".
Неявно - это к ЯП, где возможен и явный "return foo" и возврат последнего выражения (например ruby, rust - где есть "типа фунциональщина и сбоку бантик").
>> копирование ... которого не будет в си
> А в С был бы возврат указателя на локальный буфер в функции,Смотрим 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() результата?
> Т.е. в Си убрали бы char buf[8192] и вернули указатель на кучу.В таком случае вызывающий get_realpath() должен деаллоцировать результат с помощью free(). А что если get_realpath() вернёт не результат realpath(), a path, полученный параметром? Он то вообще непонятно где находится и как аллоцирован. Тогда мы имеем или double free, или попытку сделать free() на указатель на стеке. С сопутствующими проблемами безопасности. Значит нельзя просто возвращать path, а надо сделать ему strdup(), получается одно копирование заменили на другое. Ты можешь сказать, ну тогда надо менять всю функцию, чтоб копирования не было. Или вообще её убрать и те 2-4 строчки в вызывающий код вписать. Но тогда можно и на С++ тоже функцию полностью переписать "по правильному". И вообще теряется весь предмет разговора.
> Что бы в Си++ не заниматься крохоборством с магическими числами вместо PATH_MAX, можно было конструировать std::string из аллоцированого ф-цией realpath() результата?
Да, запросто.
>> Т.е. в Си убрали бы 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() результата?
> Да, запросто.В общем, непонятна экономия. Если есть имя файла, значит его будут читать, а это всю "оптимизацию" с кучей перевесит.
> Только в Си все освобождения явны.Хм, так пишешь, как будто это хорошо. Явны, значит замусоривают код и заставляют программиста всё деаллоцировать вручную, т.е. лишают автоматизации, заставляют следить чтобы и не забыть про деаллокацию, и чтобы она больше одного раза не произошла.
> Вроде как переписали на Си++, но наполовину,
> в итоге там потенциально буфер переполняется.Да, не очень хорошо получилось. Но код на стыке языков часто таким бывает. Я не про потенциальное переполнение буфера, а просто про элегантность. Да и get_realpath() - это по сути С++ wrapper вокруг сишного API realpath(), а к врапперам требования по элегантности снижены, врапперы как раз и призваны локализовать неэлегантность в себе, предоставляя удобное API наружу.
>> Только в Си все освобождения явны.
> Хм, так пишешь, как будто это хорошо. Явны, значит замусоривают код и
> заставляют программиста всё деаллоцировать вручную, т.е. лишают автоматизации, заставляют
> следить чтобы и не забыть про деаллокацию, и чтобы она больше
> одного раза не произошла.Так там кто-то хотел на Си, значит для него это хорошо.
>> Вроде как переписали на Си++, но наполовину,
>> в итоге там потенциально буфер переполняется.
> Да, не очень хорошо получилось. Но код на стыке языков часто таким
> бывает. Я не про потенциальное переполнение буфера, а просто про элегантность.
> Да и get_realpath() - это по сути С++ wrapper вокруг сишного
> API realpath(), а к врапперам требования по элегантности снижены, врапперы как
> раз и призваны локализовать неэлегантность в себе, предоставляя удобное API наружу.Есть же std::filesystem::canonical().
>> Ну почему же
>> std::string get_realpath(std::string_view path) {
>> char buf[8192];
>> return buf;
> Тут "спрятанно" какое-то копирование buf в возвращаемый std::string (которого не будет
> в си)?Тут переполняется стек при "нестандартном" значении PATH_MAX.
Ну возьми да перепиши на раст.
Точно, плесень надо писать на ржавчине
Обрати внимание на исходники GCC, там уже много файликов на С++. Брат жив.
Это говорит только о том, что gcc -- не очень хороший компилятор
> о том, что gcc -- не очень хороший компиляторчего именно ? с++ или c ?
> Это говорит только о том, что gcc -- не очень хороший компиляторТебя обманули. gcc это вообще не компилятор! Это коллекция компиляторов.
А Шланг*, по этой логике, получается лучше?*Шланг весь на C++.
>>печальноНу перепиши на Питон, и радуйся. С девушкой. Питон предоставит достаточно времени. ;)
Если глянуть исходники, там типичная сишка по сути. Вот например: https://github.com/rui314/mold/blob/main/elf/arch-x86-64.cc
даже stl не используется.
ловите питониста, не различает си и си++
кстати заметьте как ускорено дропают поддержку 32х бит арма
Так он микроконтроллерах только и остался.
это тебе в отделе маркетинга подсказали ?
> template <>
> void GotPltSection<X86_64>::copy_buf(Context<X86_64> &ctx) {Рили?
То что обычные сишные процедуры зачем-то в виде шаблонов оформлены, сути не меняет. Там за вечер этот 1% кода выкинуть можно и заменить сишными вызовами процедур и будет 100% сишка. А так пока 99% си 1% си++.
> То что обычные сишные процедуры зачем-то в виде шаблонов оформленыИнтересно, зачем?
u8 *loc = base + rel.r_offset;
/// ...
auto write8 = [&](u64 val) {
overflow_check(val, 0, 1 << 8);
*loc = val;
};/// ...
write8(S + A);
> auto write8 = [&](u64 val) {Легко заменяется на вложенную функцию из GCC C расширения или макрос и дальше можно так же писать
write8(S + A);
Только тогда теряется либо совместимость со стандартом, либо типобезопасность.
-stg=gnu99
Вот и я про тоже. Нестандартные расширения GNU.
Наверное, я что-то уловил, но зачем там вообще лямбда. Вызывается однократно в теле той же функции, где определена.
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
Может раньше неоднократно вызывалась, потом другие вызовы убрали. Да много причин может быть
Многократно вызывается write32s. Там switch и write8 вызывается для R_X86_64_8. Больше, вроде, нет подходящих типов релоков. Далее идут прямые записи вида *(u64 *)loc = S + A; Вероятно, изначально хотел единообразие, но потом устал эти лямбды писать на каждый чих.
> Интересно, зачем?Возможно, просто как способ сделать код более читаемым. Возможно, как способ повысить maintainability кода инкапсуляцией -- операция write8 вынесена отдельно, и если ты хочешь изменить её, то вот она, тебе не надо весь код функции перелопачивать, выясняя где там мы в loc пишем. Кроме того, если ты присмотришься, тут неявно создаётся локальная переменная val инициализируемая значением S+A. Без этой переменной придётся писать S+A дважды, а это прям приглашает наступить будущих мейнтейнеров на грабли, чтоб они поменяли в одном месте S+A на что-нибудь ещё, а в другом месте забыли бы.
А может, как писали выше, задумка была в том, что таких операций будет много, и может их было когда-то много, а потом стало мало, но это же не повод удалять столь удачную функцию?
Неудачно процитировал, лучше весь код смотреть. Хотя бы это: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 по три строчки.
И switch так красивее - все case по три строчки.
Не, красивее было бы вместо rel.r_type передать указатель на функцию соответствующего write...() и свитч не нужен был бы.
rel.r_type читается из объектника, а указатель откуда возьмётся?
Ну, в принципе если проверку вадиности значения отдельно вынести - можно и по табличке сделать, но подозреваю, что кода будет больше, маинтайнить станет менее удобно, а толку - никакого, этот свитч, скорее всего, во что-то подобное компилятором и будет преобразован
> template <>
> void GotPltSection<X86_64>::copy_buf(Context<X86_64> &ctx) {
> Рили?Подозреваю, что причина использование темплейтов в том, что линкер похожим образом обрабатывает ELF-файлы разных архитектур. Похожим образом, но не абсолютно одинаковым. То есть многие функции обработки выглядят одинаково, но не все. Те, которые разные - реализованы в виде специализации темплейта для конкретной архитектуры, например X86_64, что мы и наблюдаем в этом файле.
Какой-то трешекод. Вообще ничего не понятно - одни магические константы вхардкожены. У нас бы он код ревью не прошел. 🤣
> ничего не понятноУ приплюснутых такое в порядке вещей.
> Вообще ничего не понятноТак матчасть изучай. GOT с PLT парсить, да релокации осуществлять - это тебе не формы клепать.
> одни магические константы вхардкожены
Магические константы аккуратно прокомментированы и локализованы либо в константных массивах, либо в специальных функциях для этих констант. Этот как раз таки противоположность хардкода. А также используются много где исплоьзуются символьные константы типа R_X86_64_RELATIVE. Зря наговариваешь на код в общем.
> может применятьсяНу и ладненько. Не хватало еще стопицотзависимого крестового линкера
А парень не промах. Сначала наковырял lld потом сделал mold и вышел в профит. Красавчик.
Интересно, а правильно ли он компонует ? Новые баги добавляет ?
> Новые баги добавляет ?Это конфиденциальная информация.
Кем вы себя возомнили?
Директорский состав Каспийского моря. Ваши документы пожалуйста
> Интересно, а правильно ли он компонует ? Новые баги добавляет ?Не знаю, но судя по новости ff chromium и шланг собрались, следовательно работать должен.
Ты случаем не мейнтейнер рача?
> Ты случаем не мейнтейнер рача?Нет
> НетУ них такая же политика "собралось значит работает".
> У них такая же политика "собралось значит работает".У меня по другому. Получилось собрать и запустить program --help путем лютейших костылей и не взираю на тысячи ошибок - все норм, все работает
А они патчи не любят
Адовы муки статических языков
программа либо разрабатывается быстро, либо работает быстро. Привыкай, мой юный кодер пробельчиками.
> программа либо разрабатывается быстро, либо работает быстро, но только если разработана с умомfixed
А если без ума, то и разрабатывается быстро, и работает быстро. Но такая чушь получается!
Если бы это было так, мир был бы прекрасен. Но увы мы видим программы, которые разрабатываются за непредсказуемое, часто очень длительное время, многократно превышающее первоначальные планы, медленно работающие, содержащие массу ошибок, включающие утечки памяти. Здравствуй Rust.
Там, где на этапе компоновки заканчиваются муки статических языков, начинаются муки динамических погромистов.
Вы давно указатель на null проверяли?
Указатель на Хиндли-Милнера?
После проверки на None не забудьте ещё проверить тип переменной
Нахрена мне умный указатель проверять? Он либо содержит то, что должен либо не существует вместе со своим объектом-владельцем. Ну либо код писал идиот, а ревьюили задницей и позволили кому-то писать си-стайл.
так вроде бОльшая проблема это сама трансляция сколько сама сборка этих двух гиговых файлов происходит? Там ведь бесконечное дёрганье заголовков подстановка и трансляция их каждый раз
В C++ это решили (решат) добавлением модулей
Ну отличная новость хотя и спустя 38 лет с момента появления языка. В любом
случае еще подождем....Кстати если взять пионеров, то у многих это уже давно реализовано из коробки:
cargo, pip, go mod, maven и т.д.
Не совсем. На первой сборке очевидно, что на создание объектных файлов уйдёт много времени.
Потом правится и компилируется один .c/cpp файл в один объектный файл, и это быстро. А потом снова линковка сотен объектных файлов, и это медленно.
Это требует определенной культуры и организации разработки, а так же в целом хорошей работы системы (локального времени) если я правильно помню как там происходит сравнение изменений файлов.
Линковка - тоже не сахар, как гентушник говорю :-) на райзене 3700X какой-нибудь хромиум линкуется несколько минут, ну и память жрёт гигабайтами. Тут даже интереснее, удалось ли по памяти эту штуку менее прожорливой сделать
Толку мало от 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>
>Mold написан на языке С++ (C++20) и распространяется под лицензией AGPLv3Лучше бы тогда уж под проприетарной, раз в копирастию поиграть хочется.
Тогда никто не подсядет
ржавчина, плесень... кишечные паразиты на очереди?
символично и с издевкой закапывать опенсорс не запретишь
Хероптериксы
Я бы попросил!
Это другое. Вот гнили ещё не было. Кстати, ничего так название - rot, осталось только придумать проект.
Зачем было создавать новый проект, если можно было ускорить какой-нибудь старый, тем более что тогда это быстрее принесло плоды. В остальном очень интересует - а не диким ли распараллеливанием выигрыш достигается ? Ведь если так и если остальные компоновщики просто долбят однопоток..., то тогда опять же зачем было изобретать велосипед, если можно было добавить колёс старому ?
Андрей, привет. Трехколесный велосипед медленнее двухколесного. Пока, Андрей.
Почему тогда автомобили на четырёх колёсах в основной массе, а не хотябы трёх?
Думаешь если добавить к ним еще парочку колес, они станут быстрее? Напоминаю, что больше 4 колес обычно имеют всякие грузовики. А в будущем все колеса уберут, потому что машины будут летающими.
А почему у самолётов и вертолётов не уберут колёса?
Нужны для совместимости с автомобилями.
>Почему тогда автомобили на четырёх колёсах в основной массе, а не хотябы трёх?А почему телеги и кареты на четырёх колёсах? А почему коляски и колесницы на двух колёсах? Наверно потому-что так рационально.
Мотоцикл можно назвать автомобилем на двух колёсах. И при одинаковой мощности двигателя, мотоцикл обычно быстрее (если сравнивать лучшие модели).Дополнительные колёса дают не скорость, а удобство, безопасность и грузоподъемность.
Дополнительные колёса (если употребить всю упаковку сразу) дают чуЙство гениальности :)
И вот ты уже объясняешь на оппа-нете чем мацатыкал от бибики отличается :)
> В остальном очень интересует - а не диким ли распараллеливанием выигрыш достигается ? Ведь если так и если остальные компоновщики просто долбят однопоток..., то тогда опять же зачем было изобретать велосипед, если можно было добавить колёс старому ?Если выигрыш достигается диким распараллеливанием, то сам бог велел делать это новым проектом. Распараллелить программу, написанную под однопоток -- это гарантированно получить тысячи memleak'ов, use-after-free, data-races, race-conditions и прочих. Их будет столько, что ты никогда их не одолеешь, годами будешь сидеть отлавливать, и никогда не отловишь все.
Не говоря уж о том, что существующие линкеры поддерживают куда больше архитектур, даже старых и ненужных, и переписывать пришлось бы огромное количество кода. А в mold всего 3, что намного проще для proof-of-concept и первого релиза.
Часто чтобы просто донести патч до апстрима в СПО проектах нужно ждать несколько лет пока правильно расставишь скобочки, напишешь кучу тестов и сделаешь три раза Ку перед мейнтейнером. А с радикальными переработками процесс вообще может никогда не сойтись.
Насчёт "ку" - такое возникает ровно в двух случаях: либо апстрим мёртв либо ты пытаешься рассказать "как надо" и это с точкой зрения апстрима вообще никак не совпадает.А правильно расставить скобочки и написать тесты придётся в любом случае, если, конечно, говнокод не устраивает
Не так давно сталкивался с особенностями работы lld: как оказалось, он в силу однопроходной архитектуры не может работать с r_riscv_align.Переключив линкер с lld на gnu ld я обнаружил, что у них немного разный синтаксис.
Исследуя этот вопрос добрые люди скинули ссылки на несколько статей, однако из них не следовало, что в ближайшее время ситуация как-то изменится.
Страшно если в итоге получим n линковщиков с разными функциональностью и синтаксисом.
Я кстати не вижу сравнения с bfd. Gold всегда славился своими дорогостоящими оптимизациями (LTO), для чего он и был придуман изначально, но он мало совместим с современным софтом. Ядро кстати тоже не собирается больше голдом, он давно мёртв, и это финиш. Не могу придумать причин использовать ldd.
>lddlld конечно
lldilldo
О да, для сборки хипстерских WebAssembly, где сплошные статические библиотеки линкуются в один мегаэкзешик и уходят на это целые минуты, новый линковщик в замен тормозного lld будет очень кстати!На десктопе такой ерундой нет смысла заниматься - с динамическими библиотеками таких проблем не замечается...
Вы хромом на десктопе пользуетесь? Вот его сборка в т числе и ускорилась.
А что, хромом уже нельзя пользоваться, если не собрал сам на своём десктопе?
С таким подходом можно ничем не заниматься. Можно пользоваться уже написанными скомпилированными программами. Зачем развивать языки программирование, ИДЕ и компиляторы?
С++20 конечно рулит, но такая вещь, как плесень, просто обязана быть на ржавчене, как же иначе?
>Проект признан готовым для рабочих внедрений и может применяться в качестве более быстрой прозрачной замены GNU linker на Linux-системахТочно готов? И поехавшие линкер-скрипты работают? А если проверить?
И снова не на расте)) лол
Растом то вообще хоть кто-то пользуется?
> GNU gold тратится 53 секунды, LLVM lld - 11.7 секунд, а Mold всего 2.2 секунды ... распространяется под лицензией AGPLv3 ... Подобный выбор объясняется желанием получить финансирование разработкиВсе просто будут использовать lld ибо 3 сек по сравнению с 12 не такой большой профит как 12 с 53.
Это _огромный_ бонус, если ты вносишь мелкие правки в сорцы, компилируешь, запускаешь, смотришь что получается, вносишь ещё какие-то правки. Три секунды задержки -- это слегка раздражающая вещь, 12 секунд задержки -- это повод встать и пойти за чаем. 53 секунды -- это просто ппц, это повод менять методологию программирования, снижая частоту пересборок.
А с lto оно как работает? А то на lto все тормозят, однако оптимизации крутые, кучу кода удаляет без каких либо побочных эффектов. И компилять с отдельными дебажно девеловскими опциями это фуфу, вылезает иногда нежданчиками.
> автор готов продать права на код для перелицензирования под разрешительной лицензией,
> такой как MIT, или предоставить отдельную коммерческую лицензию для тех, кого не устраивает AGPL.Правильный подход к корпорациям и менеджерской швали :)