| |
| 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).
Вовсе не печально.
А у тебя есть альтернативы, которые работают быстрее сабжа и написанные на "правильном" ЯП?
| | |
| |
| |
| 4.19, AnalMal (?), 13:02, 16/12/2021 [^] [^^] [^^^] [ответить]
| +14 +/– |
Да, правильный. Но никто не запрещает писать тебе писать на С++98
| | |
| |
| 5.24, Аноним (-), 14:33, 16/12/2021 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> Но никто не запрещает писать тебе писать на С++98
ты утверждаешь что это write-only язык ?
прочитай что написано в новости - проект на c++20
| | |
|
|
|
| |
| |
| 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. И разработка быстрее, и код читабельнее, и производительность на высоте. А С-луддитам пора выйти из зоны комфорта и выучить, наконец, С++.
| | |
| |
| |
| |
| |
| 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. В-третьих, что за сайт левый такой и только картинка, почему не дать ссылку на оригинал, статью на Хабре? Наверное потому что там уже напихали авторше в панамку по поводу совершенно неправдоподных цифр?
| | |
|
|
|
|
| 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 Только в Си все ос... большой текст свёрнут, показать | | |
| |
| |
| 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.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 [^] [^^] [^^^] [ответить]
| +/– |
 >>печально
Ну перепиши на Питон, и радуйся. С девушкой. Питон предоставит достаточно времени. ;)
| | |
| |
| 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 [^] [^^] [^^^] [ответить]
| +/– |
Только тогда теряется либо совместимость со стандартом, либо типобезопасность.
| | |
| 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... большой текст свёрнут, показать | | |
|
|
|
| 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.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.36, макпыф (ok), 18:06, 16/12/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Интересно, а правильно ли он компонует ? Новые баги добавляет ?
Не знаю, но судя по новости ff chromium и шланг собрались, следовательно работать должен.
| | |
| |
| |
| |
| |
| 6.51, макпыф (ok), 21:39, 16/12/2021 [^] [^^] [^^^] [ответить]
| +/– | |
> У них такая же политика "собралось значит работает".
У меня по другому. Получилось собрать и запустить program --help путем лютейших костылей и не взираю на тысячи ошибок - все норм, все работает
А они патчи не любят
| | |
|
|
|
|
|
| |
| 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 +/– |
Там, где на этапе компоновки заканчиваются муки статических языков, начинаются муки динамических погромистов.
| | |
| |
| |
| 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 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
так вроде бОльшая проблема это сама трансляция сколько сама сборка этих двух гиговых файлов происходит? Там ведь бесконечное дёрганье заголовков подстановка и трансляция их каждый раз
| | |
| |
| |
| 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.127, burjui (ok), 10:39, 20/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
 Это другое. Вот гнили ещё не было. Кстати, ничего так название - rot, осталось только придумать проект.
| | |
|
| 1.33, Андрей (??), 17:31, 16/12/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Зачем было создавать новый проект, если можно было ускорить какой-нибудь старый, тем более что тогда это быстрее принесло плоды. В остальном очень интересует - а не диким ли распараллеливанием выигрыш достигается ? Ведь если так и если остальные компоновщики просто долбят однопоток..., то тогда опять же зачем было изобретать велосипед, если можно было добавить колёс старому ?
| | |
| |
| 2.34, Аноним (7), 17:52, 16/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
Андрей, привет. Трехколесный велосипед медленнее двухколесного. Пока, Андрей.
| | |
| |
| |
| 4.38, Аноним (7), 18:23, 16/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
Думаешь если добавить к ним еще парочку колес, они станут быстрее? Напоминаю, что больше 4 колес обычно имеют всякие грузовики. А в будущем все колеса уберут, потому что машины будут летающими.
| | |
| 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.
| | |
|
| 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.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.
Правильный подход к корпорациям и менеджерской швали :)
| | |
|
