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

"Выпуск компоновщика Mold 3.0, развиваемого разработчиком LLVM lld"	+/–
Сообщение от opennews (??), 05-Окт-26, 22:25
Опубликован выпуск компоновщика Mold 3.0, который может применяться в качестве более быстрой прозрачной замены GNU linker на Linux-системах. Проект развивает Rui Ueyama, автор компоновщика LLVM lld.  Ключевой особенностью Mold является очень высокая скорость связывания объектных файлов, заметно опережающая  компоновщики GNU gold и LLVM lld (компоновка в Mold выполняется со скоростью, всего в два раза медленнее простого копирования файлов утилитой cp). Код написан на языке Rust и распространяется под лицензией MIT... Подробнее: https://www.opennet.me/opennews/art.shtml?num=66406
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 05-Окт-26, 22:25	+1 +/–
lto проблемный процесс, сабж позволяет его ускорить?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #14, #19, #39

2. Сообщение от Аноним (1), 05-Окт-26, 22:26	+1 +/–
и что там с потреблением памяти, обычный лто уже привычно 10 гб на 1 процесс
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

3. Сообщение от Аноним (3), 05-Окт-26, 22:49	–7 +/–
Это очень хорошая новость!
Ответить | Правка | Наверх | Cообщить модератору

6. Сообщение от Аноним (6), 05-Окт-26, 23:03	+/–
>>вариант на Rust останавливает работу на этапе проверки границ Что мешало сделать проверки на C++ ?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #15, #16, #17, #60, #192

7. Сообщение от Аноним (6), 05-Окт-26, 23:05	–2 +/–
>>Мотивом к созданию Mold стало раздражение от необходимости ждать завершения компоновки после каждого внесения изменения в код Надуманная проблема
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #20, #43

8. Сообщение от Bottle (?), 05-Окт-26, 23:16	+/–
Ирония проекта в том, что он сам компилироваться будет ещё медленнее. Но, с другой стороны, лучше так, чем никак.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9, #21

9. Сообщение от жявамэн (ok), 05-Окт-26, 23:22	+4 +/–
Ты из тех кто пересобирает файрфокс перед каждым заходом на опеннет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #162

11. Сообщение от Аноним9000 (?), 05-Окт-26, 23:29	+/–
Да что же такое, снова несуществующий реальный продукт на раст!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #13, #44

12. Сообщение от Инопланетянин (?), 05-Окт-26, 23:30	+2 +/–
> Переход на Rust позволил... Кто это у нас там в контрибьюторах на 2-ом месте
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #22

13. Сообщение от Аноним (13), 05-Окт-26, 23:35	+/–
Ты посмотри в список контрибьютеров, это нейрослоп (почти)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

14. Сообщение от Аноним (14), 05-Окт-26, 23:44	–7 +/–
растовики только переписывают, как показала тенденция не без помощи ЫЫ, так, что вы там говорили про LTO? Видать там ускорение получено за счет выпиливания того самого LTO :)))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #113

15. Сообщение от GNU Overlord (ok), 05-Окт-26, 23:52	+2 +/–
"сделать" Собстенно, это и мешало - их делать нужно, а не просто на комплиятор повесить. Причем делать нормально, а не так, чтобы потом сегфолты летели.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #46

16. Сообщение от morphe (?), 06-Окт-26, 00:04	+/–
Потому что при разборе объектных файлов концепция parse, don't validate в случае плюсов невероятно сложная, поскольку zero-copy это надо следить за временем жизни кучи span/string_view, в то время как в Rust за временем жизни следит компилятор
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #42, #181

17. Сообщение от Васян Айтишник (?), 06-Окт-26, 00:18	+/–
Так-то наверное можно и на Бейсике писать и проверки сделать :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

18. Сообщение от Ivan_83 (ok), 06-Окт-26, 00:20	–3 +/–
> Ветка Mold 3.0 примечательна переписыванием кодовой базы с C++ (C++20) на язык Rust. Бесполезный компоновщик стал х10 бесполезнее. Тем кто смотрит в его сторону: не тратьте время. 1. LTO оно не умеет. 2. без LTO линковка даже обычными линковщиками не особо то и заметна  на фоне процесса компиляции. Возможно есть очень-очень редкие юзкейсы когда оно имеет смысл, например вы уже скомпилили нечто тяжёлое типа хрома, потом поредактили пару файлов и вам только их перекомпилить и перелинковать. Ну вот тогда оно секунд 5 сэкономит. При обычном процессе хром всё равно компилится часы и линкуется минуты, от того что результат будет получен на 1-2 минуты раньше легче не станет.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #25, #27, #29, #38, #204

19. Сообщение от Ivan_83 (ok), 06-Окт-26, 00:22	–1 +/–
Нет, там ни слова нет про LTO.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

20. Сообщение от Ivan_83 (ok), 06-Окт-26, 00:24	+2 +/–
Ну автор холерик, не мог ждать ещё дополнительно 16 секунд после 4 часов компеляции хрома пока тот слинкуется :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #23, #72

21. Сообщение от Ivan_83 (ok), 06-Окт-26, 00:28	+1 +/–
Ирония в том, что этот проект вообще существует и каждый раз его здесь продают с такой помпой, как будто это чудо какое то и мастхэв. И никто тут не читает даже readmi.md проекта и не осознаёт его полную бесмысленность. И я не прочитал и полез эту фигню пробовать. А потом узнал что LTO там только через плагин = подключается llvm и разницы в скорости 0. А для случаев когда LTO не нужно - разницы особой нет, ну типа мне что 5 что 15 секунд линковки для проекта который собирался пол часа - как то пофик.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #24, #37

22. Сообщение от Аноним (22), 06-Окт-26, 00:58	+/–
ИИшечка
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

23. Сообщение от An2 (?), 06-Окт-26, 01:13	+1 +/–
Точно секунд, а не минут?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #28

24. Сообщение от An2 (?), 06-Окт-26, 01:14	+/–
> что 5 что 15 секунд линковки для проекта который собирался пол часа А если туда нужно вносить изменения, одно за другим. Компиляция - 2 секунды, а линковка на порядок дольше?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #30

25. Сообщение от An2 (?), 06-Окт-26, 01:17	+/–
> типа хрома Да, без mold поиграться с каким-то изменениями в Firefox или Chromium не реально.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #26

26. Сообщение от Ivan_83 (ok), 06-Окт-26, 02:09	+/–
Угу, целых 16 секунд (по данным бенчей молд) ждать, вместо 1,6.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #56

27. Сообщение от Аноним (39), 06-Окт-26, 02:10	+/–
> потом поредактили пару файлов и вам только их перекомпилить и перелинковать Он буквально для этого и создан, гений.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #31

28. Сообщение от Ivan_83 (ok), 06-Окт-26, 02:17	+2 +/–
Так сходите на сайт, там автор честно бенчи выложил, настолько честно что даже не включал LTO.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

29. Сообщение от SanityEclipse (ok), 06-Окт-26, 02:19	+3 +/–
Ну да, компилируют проекты же только юзеры, а разработчики постоянно проект начистую собирают. Действительно, редкий юзкейс. Как и инкрементальная компиляция, наверное
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #32, #35

30. Сообщение от Ivan_83 (ok), 06-Окт-26, 02:20	+1 +/–
А юзкейс у этого какой? Я знаю 2 воркфлоу: 1. меинтейнер/пользователь: скачал, собрал, пользуется. 2. программист: поменял-собрал-запустил тесты-поменял...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #82

31. Сообщение от Ivan_83 (ok), 06-Окт-26, 02:22	–1 +/–
Так время работы обычного линковщика даже на хроме не мешается - пренебрежимо мало, а на мелких проектах и подавно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #33

32. Сообщение от Ivan_83 (ok), 06-Окт-26, 02:28	–3 +/–
Вам, как разработчику, есть ли большая разница если время линковки будет не 3 секунды а 0,3 при общем времени сборки в районе 40 секунд? Из всех бенчей что выложил автор, только TensorFlow линкуется заметно долго 9/50 секунд и только потому что там видимо крестовый нейрослоп на 9гб в один бинарник лезет. Да и то 9 секунд для релиза не очень то заметно, вот для дебага 50 сек наверное не комфортно уже. И это ещё хз сколько времени там занимает обход всех исходников сборочной системой и работа компилятора даже для самого маленького файла.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #34, #36, #45

33. Сообщение от Аноним (39), 06-Окт-26, 04:06	+1 +/–
> Так время работы обычного линковщика даже на хроме не мешается Вот именно что мешается, да откуда мастеру хэллоувордов об этом знать, да? Когда ты работаешь над большим проектом, где финальный бинарь размером с десяток мегабайт, компиляция отдельного CPP после правки может занимать доли секунды, а линковка бинаря при этом все равно занимает в десятки раз дольше, что невероятно бесит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #59, #104

34. Сообщение от Аноним (39), 06-Окт-26, 04:08	+2 +/–
>> инкрементальная компиляция > при общем времени сборки в районе 40 секунд? Да иди ж ты уже прочитай, что такое инкрементальная компиляция.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #105

35. Сообщение от Аноним (39), 06-Окт-26, 04:17	+3 +/–
> Как и инкрементальная компиляция, наверное Чтобы ты понимал, этот Ваня 83 недавно хвастался, что компилирует свои хэллоувороды шелл-портянкой вместо использования нормальной билд-системы или хотя бы make. А когда в связи с этим упомянули про инкрементальные билды, персонаж сделал удаленные глаза мол "хз, что это и зачем оно мне надо". Зато, как видишь, теперь экспертно вещает о ненужности mold.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #108

36. Сообщение от Slowpoke (?), 06-Окт-26, 04:32	+/–
> Вам, как разработчику, есть ли большая разница если время линковки будет не 3 секунды а 0,3 при общем времени сборки в районе 40 секунд? Странный тейк, как будто в быстрых программа есть что-то плохое. Компилятор можно тоже обновить и получить время сборки меньше условных 40 секунд, на этом фоне доля ускорения процесса линковки будет существенее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #106

37. Сообщение от Аноним (39), 06-Окт-26, 04:50	+2 +/–
> А потом узнал что LTO там только через плагин Вообще-то любой линковщик работает через плагин компилятора. Ибо ту самую оптимизацию выполняет именно компилятор, а не линковщик. Но опеннетный Ванька думает, что раз "link-time" - значит это про "linker", и гордо срывает покровы с mold, лол.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #102, #116

38. Сообщение от Аноним (39), 06-Окт-26, 04:52	+1 +/–
> LTO оно не умеет. Вообще-то умеет. Мог бы хотя бы ченджлог прочитать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #51, #109

39. Сообщение от Аноним (39), 06-Окт-26, 05:13	+3 +/–
> lto проблемный процесс, сабж позволяет его ускорить? Нет, ибо LTO, внезапно, выполняется компилятором, а не линковщиком.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #53, #137

42. Сообщение от Вечный странник (?), 06-Окт-26, 06:22	–1 +/–
Это за тебя сделает нормальный компилятор и language server/нормальные правила в clang-tidy
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

43. Сообщение от Аноним (43), 06-Окт-26, 06:27	+1 +/–
Zig (компилятор) уже сделал. Но есть один нюанс. Полученный бинарник считает не то, что нужно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

44. Сообщение от Аноним (43), 06-Окт-26, 06:28	+1 +/–
> несуществующий реальный продукт Так несуществующий или реальный?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

45. Сообщение от User (??), 06-Окт-26, 06:42	+1 +/–
Ну, если ускорение "бесплатное" или близко к тому - почему бы и нет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #107

46. Сообщение от Смузихеб забывший пароль (?), 06-Окт-26, 07:53	+1 +/–
> в ситуациях, когда версия на С++ аварийно завершалась > из-за обращения к областям памяти за пределами буфера, > вариант на Rust останавливает работу на этапе проверки границ Чуваак, похоже, и то и то вылетает. Только одно - безопасТно )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #50

47. Сообщение от Метрика (?), 06-Окт-26, 08:26	+/–
Как только появилась новость о том что штатный компновщик LLVM стал мочь в многопоток, разрабы mold тут же ришили попиарится и показать свою нетакусесть, исход у таких проектов один, через год проект исчезнет из новостей, через два затеряется в тысячях репозиториев гитхаба, а на третий помрет
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #173

48. Сообщение от Метрика (?), 06-Окт-26, 08:30	–3 +/–
Забавно, что переписавание на раст занимаются те кто предложить ничего не может, была новость что штаный компоновщик llvm теперь умеет в многопоток, после этого предложить mold больше нечего, кроме как переписывания с одного яп на другой в попытке выделится и удержаться на плаву
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #52, #65

49. Сообщение от Метрика (?), 06-Окт-26, 08:33	+3 +/–
Кстати есть показательный пример использования rust как конкурентного преимущества, это история с движком servo в огнелисе, итог этой истории успеха падением доли на рынке с ~30% до ~3%
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #55, #61, #62

50. Сообщение от Аноним (50), 06-Окт-26, 08:36	+5 +/–
> Чуваак, похоже, и то и то вылетает. Раст "вылетает" при попытке выйти за пределы буфера. Ну как вылетает... кидает панику с описанием что где вплоть до строчки где произошла ошибка. А с++ вылетает на совсем другом объекте, когда память уже попорчена. И информации о то что произошло практически не предоставляет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #99

51. Сообщение от Аноним (50), 06-Окт-26, 08:37	+/–
> Мог бы хотя бы ченджлог прочитать. Зачем читать если можно писать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

52. Сообщение от Аноним (52), 06-Окт-26, 08:42	+2 +/–
Во первых он переписал, то что изначально написал сам! Во вторых, учитывая тенденцию того как в ubuntu внедряют утилиты на rust, то стратегия весьма неплохая, чтобы стать линковщиком по умолчанию, для начала в той же ubuntu. Так что разработчик прекрасно понимает куда ветер дует
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #58, #115

53. Сообщение от Аноним (1), 06-Окт-26, 09:14	+/–
Ускорить то можно, вон гцц 14 в 5 раз дольше собирается с лто. Гцц 16 всего раза в 2 дольше -- видимо, есть поле для оптимизаций.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #57

55. Сообщение от Мемоним (?), 06-Окт-26, 09:15	–1 +/–
Но ведь в лисе оставили Gecko. Именно на этом кривом крестовом поделии доля и падала.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

56. Сообщение от пох.. (?), 06-Окт-26, 09:20	–1 +/–
через всего лишь час после того как оно начнет и закончит собственно компилять (я ж правильно кстати помню что тяпляперы собравшие винигрет из трех полуработающих автоматизаций сборки - в частичную компиляцию не шмагли и при изменении одного файлика фуфлофокс пересобирается весь целиком?) в общем, отличный линкер для хеловрота, которому и lto никакая не нужна. одно надо бы уточнить - llvm весь такими авторами написан или этот - уникум? (вспоминая что тот десять лет тратил чужое время на неотключаемые сборки сотни неведомых и толком даже неработающих targets, и то что в freebsd их сейчас отключает - 3d party патч не признанный апстримом?)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #103

57. Сообщение от Аноним (1), 06-Окт-26, 09:23	+/–
У шланга, к слову, была схожая проблема в прошлых версиях. Вечная-вечная обработка лто, часами на каждом файле, и в текущих версиях так не зависает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53

58. Сообщение от пох.. (?), 06-Окт-26, 09:25	+/–
может скажем ему? Ну что в бабуинту может и включат, бабуины - они не очень умные. Но не настолько, не настолько. В смысле - денег ему - хрен они дадут. Так что зря тратил токены, не окупится. (разбираться сам ли он написал или там и изначально автор claude haiku - оставляю внимательным читателям)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

59. Сообщение от пох.. (?), 06-Окт-26, 09:28	–2 +/–
жаль что наш мастер нехеловротов не в курсе, что у таких проектов обычно "./mach" без возможности вмешаться в механику. И никакой отдельной компиляцией там и близко не пахнет. Вероятно твои нехеловроты были исключительно голосами у тебя в голове. В десятки дольше - это натурально вот 20 секунд вместо 2.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #121

60. Сообщение от Аноним (60), 06-Окт-26, 09:30	+1 +/–
много мест, везде ручками проверять. зачем, если раст сам это делает?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

61. Сообщение от Аноним (61), 06-Окт-26, 09:32	+1 +/–
Да, дело точно в движке. Массовый потребитель прямо так и прочитал, что лис перешёл на движок на расте и ушёл в стоковый гуглохром
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #70

62. Сообщение от Аноним (62), 06-Окт-26, 09:43	+/–
> это история с движком servo в огнелисе, итог этой истории успеха > падением доли на рынке с ~30% до ~3% О... в очереной раз начинается песня про провал лисы)) Раньше ныли что во всем виноват дроп ХУЛя, а теперь из-за раста. Первые раст компоненты были добавлены летом 2016 года. Самые важные компоненты в начале растификации лисы - encoding_rs и Stylo CSS - были добавлены в конце 2017 года в Firefox 56 и 57 соответственно. Хром обогнал лису еще в 2013м. В 2014 ФФ уже потерял около 50% своей аудитории и стал менее популярным чем Сафари. В конце 2017 global market share был около 12%. Т.е. падение с 33% в топе до 12% еще до того как раст попал юзверям. Из этого можно сделать вывод что РАЗУМЕЕТСЯ во всем виноват раст)))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #63, #64

63. Сообщение от Аноним (63), 06-Окт-26, 09:56	+1 +/–
потратили кучу времени на раст
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

64. Сообщение от Аноним (13), 06-Окт-26, 10:22	+1 +/–
Ну дык такая переусложненная вундервафля, как раст, не за один же год появилась. А значит её разрабатывать начали сильно заранее, а значит потеряли и время и деньги, вот хром и обогнал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #112

65. Сообщение от devl547 (ok), 06-Окт-26, 10:24	+/–
>штаный компоновщик llvm >Проект развивает Rui Ueyama, автор компоновщика LLVM lld. Что он там предложить не может-то?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #80

66. Сообщение от Гаврош (?), 06-Окт-26, 10:25	–1 +/–
> обезопасить проект от потенциальных проблем при обработке повреждённых объектных файлов Господи, ну и ахинея!!! Т.е. вы сменили ЦЕЛЫЙ ЯЗЫК только ради того, чтобы... проверить длину файла??? Избави меня от таких вайбкодеров!!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #68, #76

68. Сообщение от Аноним (70), 06-Окт-26, 10:29	–1 +/–
> Господи, ну и ахинея!!! Т.е. вы сменили ЦЕЛЫЙ ЯЗЫК только ради того, чтобы... проверить длину файла??? А те кто не сменил, получают в Груб2 ситуацию "нажал 28 раз бекспейс - зашел без пароля")) > Избави меня от таких вайбкодеров!! Типа ты что-то решаешь)))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66

70. Сообщение от Аноним (70), 06-Окт-26, 10:32	+/–
А потом гугля в хроме выкидывает Сишные либы и заменяет на растовые. УжасТное коварство! Наверняка это заговор!!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61

71. Сообщение от Аноним (71), 06-Окт-26, 10:52	+1 +/–
я молд не советую и знать про него ни чего не хочу опыт не удачный собирал фирефокс 153 не так давно по тесту спидометр 3.1 было 11.2  стало 9.5 потесту спидометр  2.1 было 166   стало 149 вернулся обратно на линкер bfd gold из clang 22.1.8 и производительность по тестам вернулась обратно есть подозрения что и другие бинарники в системе потеряли в производительности и в игорях подсел фпс после пересборки мира система gentoo ядро 7.2.9-зен fx-9590 ddr3-2133-16gb лису собирал с пго и лто clang и rust -03 СКАЖЕМ дружно ОНО не нужно ну ее эту заливную рыбу.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #74, #79, #117

72. Сообщение от Аноним1234 (?), 06-Окт-26, 11:04	+1 +/–
ccache усокрить 4 часа компиляции хрома сделав их 5 минутами. А вот линковку Хрома сделать из 5 минут в 1  минуту сможет это поделка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #100

74. Сообщение от Аноним (1), 06-Окт-26, 11:30	+1 +/–
Ты лучше гцц жырнолис собери, там в попугаеметрах хороший прирост был. Ток регулярно отваливались то патчи для сборки гцц, то пго.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #83

75. Сообщение от Celcion (ok), 06-Окт-26, 11:34	+/–
Мне вот даже интересно - они специально выбирали такое отвратительное имя (mold -> плесень), причём нарочито с маленькой буквы, чтобы подчеркнуть сущность всяких таких поделий на расте?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #84, #85, #90

76. Сообщение от пох.. (?), 06-Окт-26, 11:41	+/–
> чтобы... проверить длину файла чтобы не проверять жеж! И падать unwrap через unwrap - совершенно безопастным образом! отдельно прекрасно что это вообще-то - по задумке - ТВОИ файлы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66

79. Сообщение от пох.. (?), 06-Окт-26, 11:48	+/–
бгг... может скажем ему? Ну что gold - он немного не совсем "из clang"? Причем таки да - во многих проектах исторически именно он в комплекте шланга как дефолтный штатный компоновщик. Почему? Аааакаквыдумаити?! ;-) поэтому афтырь аналогов не имеющего lld и занялся переписыванием переписанного. С собственно приличным линкером у него что-то за предыдущие 15 лет не очень сложилось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #86

80. Сообщение от пох.. (?), 06-Окт-26, 11:51	+1 +/–
линкер он нормальный предложить не может. Зато может на хрусте (попросить ыы) переписать. Как ты думаешь, почему когда сам clang был уже лет так с десяток основным компилятором в FreeBSD - в качестве линкера все равно использовали gnu ld? И да, за десять лет не смочь даже в полноценный аналог gnu ld (я даже не про gold с его оптимизациями), пока рабы эпла успели целиком компилятор - это достижение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

82. Сообщение от Loki13 (ok), 06-Окт-26, 12:10	+1 +/–
>2. программист: поменял-собрал-запустил тесты-поменял... Чем не юзкейс? А вообще, у меня гента, так вот я как-то заметил, что у меня линковка реально много времени занимает, иногда больше компиляции на некоторых пакетах. Вот тогда и заменил на сабж. Не помню какое ускорение, но оно было точно и выражалось в минутах для всего апдейта ежедневного. А учитывая что это бесплатное ускорение, то почему бы и нет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #101

83. Сообщение от Аноним (71), 06-Окт-26, 12:18	+/–
посмотрим давно так не делал попробую лису собрать gcc-16.2.1-20261003 linker-bfd попугаи в спидометрах 2.1 и 3.1 замерю вечером может отпишусь сюды если хамить не будеш. Но прошлый раз помню года полтора назад собирал gcc попугаи сильно приседали процнтов на 35 по сравнению с clang А потом мозильщики сами то лису собирают с clang-ом и тестят у них же это вроде основной компилятор. Да и  binutils я знаю что это такое не надо меня учить про линкеры.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74

84. Сообщение от Аноним (84), 06-Окт-26, 12:29	+/–
Ну а что, ржавчина, плесень - всё к одному. Ещё вот можно какой-нибудь отладчик на Расте назвать гнилью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75

85. Сообщение от пох.. (?), 06-Окт-26, 12:31	+/–
у кого чего болит? Для меня mold - это форма для литья, а про плесень я вспомню с третьей попытки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #96

86. Сообщение от Аноним (1), 06-Окт-26, 12:31	+/–
Когда-то голд лучше оптимизировал, у bfd были определённые сложности. Но те времена прошли и без проблем он ничего собрать не может уже давно. После вот этого лично я окончательно перестал с ним возиться, и вправду слишком много времени уходило на замену линкеров на рабочие https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79 Ответы: #92

87. Сообщение от Аноним (98), 06-Окт-26, 12:37	+1 +/–
Когда уже гну си компилер перепишут на раст, сил моих больше нет терпеть это! Хочется уже безопастности как у более развитой части человечества в нпм или пупи.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #91, #178

90. Сообщение от Аноним (90), 06-Окт-26, 12:51	+1 +/–
> Мне вот даже интересно - они специально выбирали такое отвратительное имя (mold -> плесень), причём нарочито с маленькой буквы, чтобы подчеркнуть сущность всяких таких поделий на ... C++20, внезапно. Первоначальный проект писался на плюсах, так что возможно твои фантазии по поводу отвратительного имени валидны. Хотя С++20 был супер свеж (1.0 вышла в 2021 году), хотя в то темное время был заражен ГНУ-раком, который сменил на свободный МИТ. Но для людей не настолько страдающих СПГС, mold - это изложница, инструмент позволяющий выплавлять слитки металлов. Что в общем-то подходит по смыслу: из смеси ингредиентов получается монолитный результат.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #97, #98

91. Сообщение от Аноним (90), 06-Окт-26, 12:54	–3 +/–
А зачем переписывать компилятор для всякой ГнуСи? Есть человеческий clang, под свободной лицензией, а не под запретительной. Который применяется в куче СПО проектов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #95

92. Сообщение от пох.. (?), 06-Окт-26, 12:56	+/–
там кажись авторов осталось - полтора старика, баги исправлять некому. gnuтыши его не любили потому что nih, и при этом унижал и доминировал (у них с оптимизациями таки да, не очень получалось в те годы). так что можно начать переписывать на хруст с помощью llm. Возможно даже получится что-то работающее, если тебе токенов не жалко.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86

95. Сообщение от Аноним (84), 06-Окт-26, 13:07	+/–
Ну так его ещё на Раст не переписали. Вот когда перепишут, тогда и поговорим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91

96. Сообщение от Celcion (ok), 06-Окт-26, 13:11	+/–
> у кого чего болит? Для меня mold - это форма для литья, а про плесень я вспомню с третьей попытки. Mold без уточнения к чему именно в плане формы оно относится - обычно означает именно плесень. Даже гугль, если не уточнять, в качестве первого варианта именно плесень и выводит. И википедия. Так что про боли - это не ко мне, а лучше сразу к врачу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85

97. Сообщение от Celcion (ok), 06-Окт-26, 13:13	+1 +/–
> Но для людей не настолько страдающих СПГС, mold - это изложница, инструмент позволяющий выплавлять слитки металлов. Это если уточнять, типа "metal mold", а без уточнения, вне контекста и в одно слово - это обычно означает плесень.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90

98. Сообщение от Аноним (98), 06-Окт-26, 13:18	+/–
В таких изложницах чаще всякие резиновые изделия делают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90

99. Сообщение от Проходил мимо (?), 06-Окт-26, 13:42	+1 +/–
И Rust и, внезапно, Си++ позволяют обрабатывать такие ситуации вообще без каких-либо спецэффектов, надо просто писать код правильно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #118, #130

100. Сообщение от Ivan_83 (ok), 06-Окт-26, 13:50	+1 +/–
С ccache "компиляция" занимает явно больше 5 минут, уже не помню точно, или 10 или 30. А линковка по данным автора молд 16 секунд всего, а с его поделкой 1,6. Как бы на фоне десятка минут это несущественно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72

101. Сообщение от Ivan_83 (ok), 06-Окт-26, 13:51	+2 +/–
Ну да, всего то было у тебя LTO а теперь его нет. :) Хоть бы бенчи автора почитал с его гитхуба.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #182

102. Сообщение от Ivan_83 (ok), 06-Окт-26, 13:55	+/–
Типа молд без lto делает всё сам. Но поскольку автор тактично умолчал что lto делается через плагины компилятора то люди которым тема особенностей сборки не сильно интереса подумали что это чудо ускорение будет всегда, а оно оказалось не так. Я то вообще не думаю про это, меня язык и его инструменты интересуют время от времени, а заботят меня больше технологии которые на этих языках описаны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #120

103. Сообщение от Ivan_83 (ok), 06-Окт-26, 14:01	+/–
Насчёт сборки фурифокса - хз, там же теперь месиво из крестов и гнили. На фре ненужно таргеты или сразу отключены или через src.conf отключаются чуть ли не с самого начала втаскивания llvm. Единственная проблема которая была последние годы - один "уникум" решил попилить llvm на либы чтобы он стал меньше на диске занимать, а учитывая PIE и ASLR и то что эти либы весят десятки-сотни мб то запуск компелятора стал занимать х10-х20 времени, очень хорошо было видно на портах на стадии cinfigure - оно прям совсем медленно чекало.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #111

104. Сообщение от Ivan_83 (ok), 06-Окт-26, 14:06	–1 +/–
Об этом знают все кто осилил пролистать таблицу с бенчами на гитхубе проекта. Если вы там что то такое отлаживаете - зачем вам LTO? - по другому долгое время линковки проекта всего то на пару мегабайт бинаря не объяснить, разве что у вас линковка идёт на каком то пень3 или дохлом арм.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #123

105. Сообщение от Ivan_83 (ok), 06-Окт-26, 14:09	–2 +/–
Покажите ка мне эту вашу инкрементальную компиляцию на проектах размером с llvm, chrome - где только make система будет все эти ваши исходники обходить и чекать на необходимость перекомпиляции по паре минут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #126

106. Сообщение от Ivan_83 (ok), 06-Окт-26, 14:14	+/–
Да можно, можно, но не бесплатно. Тейк в том, что молд это трата времени ибо в 99% проектов линковка на фоне любой сборки пренебрежимо мало занимает. И потом, вот слинковали вы нечто, дальше опять правите и пересобираете? Или у вас папйп предполагает запуск тестов или хотя бы запуск самой проги и оценку работоспособности? Если куда и смотреть - то надо было бить девляпсов за CI/CD, которая каждый раз с нуля ставит ОС и все зависимости для сборки хэловрота, и 99% времени занимает как раз разворачивание сборочного сетапа а не работа билдсистемы внутри.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

107. Сообщение от Ivan_83 (ok), 06-Окт-26, 14:17	+/–
Потому что возня с молд не бесплатная, его надо прикрутить, отладить и поддерживать, притом что для большинства проектов и воркфлоу разница в 1-10 секунд это будет совсем никак не заметно. Я веду к тому что эта оптимизация бесмысленна и не строит потраченых усилий. У автора в таблице бенчей скорее всего только один проект, который линкуется 50 сек, имеет хоть какой то практический смысл.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

108. Сообщение от Ivan_83 (ok), 06-Окт-26, 14:27	–1 +/–
А зачем оно надо? Как раз недавно я своей билд системой на шелл скрипте стал собирать libtls (та что из состава libressl), так вот полная пересборка с нуля занимает менее 2 секунд (1.60s real        3.21s user        0.94s sys) (15 .c файлов если что). Полная - это: configure + compile + link. Ну типа я знаю как там сделать инкрементальную пересборку, только зачем? Ну вот реально ЗАЧЕМ!? Оно даже в контексте програмиста не мешается, а вообще то оно было больше про дистрибуцию, где инкрементальность никому и даром не нужна, максимум ccache захотят, да и то не все. Опять же учитывая время сборки ccache тут тоже пустая трата ресурсов. И молд из той же серии: тратить время на его установку и прикручивание и поддержку никогда не окупится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #127

109. Сообщение от Ivan_83 (ok), 06-Окт-26, 14:29	–2 +/–
LTO оно УСКОРЯТЬ не умеет. Поэтому в реадми автор стыдливо про LTO ни разу не упоминает вообще. В отличии от многих я mold пробовал лично использовать в качестве линковщика в системе и пришёл к выводу что это бесполезное поделие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #129

111. Сообщение от пох.. (?), 06-Окт-26, 14:34	+/–
> На фре ненужно таргеты или сразу отключены или через src.conf отключаются чуть ли не с > самого начала втаскивания llvm. нет, ни разу. Начало 10 (или даже 9?), WITHOUT_LLVM_TARGET_ научили в 11. и это вроде бы до сих пор не принятое официально изменение
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103 Ответы: #160

112. Сообщение от Ivan_83 (ok), 06-Окт-26, 14:35	+/–
Тут всё же не раст виноват. Хотя может если бы эти ресурсы были пущены в правильный моркетинг и всякие антимонопольные тяжбы, то результат и был бы другим. Так то гугол долго крутил у себя в поисковике: "ваш браузер устарел, установите современный бизапасный хром".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #114

113. Сообщение от Аноним (113), 06-Окт-26, 14:37	+5 +/–
>> Проект развивает Rui Ueyama, автор компоновщика LLVM lld. > растовики только переписывают, как показала тенденция не без помощи ЫЫ, так, что > вы там говорили про LTO? Опять воители супротив раста дальше заголовка не читали (некогда им - Ржа наступает!)? > Видать там ускорение получено за счет выпиливания того самого LTO :))) Да и в предметной области разбираются - как одно парнокопытное в апельсинах 🤣
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #122

114. Сообщение от Аноним (13), 06-Окт-26, 14:40	+/–
>  Тут всё же не раст виноват. А он как всегда ни в чем не виноват. Подозрительно, не правда ли?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #177

115. Сообщение от Ivan_83 (ok), 06-Окт-26, 14:54	+1 +/–
Ну конечно, бубунту это общемировой меинстрим и остриё прогресса, так ведь? :) Внедрение утилит на расте - звучит как попилинг в чистом виде, прямо как замена бордюров в мск каждый сезон.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #140

116. Сообщение от Аноним (14), 06-Окт-26, 14:55	–1 +/–
> Но опеннетный Ванька думает, что раз "link-time" - значит это про "linker", и гордо срывает покровы с mold, лол. В том же LLVM лто тесно связано с линкером, оптимизатор там как отдельная либа к линкеру, в который передается инфа от линкера (все происходит на стадии линковки). //llvm.org/docs/LinkTimeOptimization.html > Ибо ту самую оптимизацию выполняет именно компилятор """ libLTO is a shared object that is part of the LLVM tools, and is intended for use by a linker. libLTO provides an abstract C interface to use the LLVM interprocedural optimizer without exposing details of LLVM’s internals. The intention is to keep the interface as stable as possible even when the LLVM optimizer continues to evolve. It should even be possible for a completely different compilation technology to provide a different libLTO that works with their object files and the standard linker tool. """ Отдельная либа используемая линковщиком на стадии линковки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #119

117. Сообщение от Ivan_83 (ok), 06-Окт-26, 14:59	+1 +/–
Ну всё же, mold он не про ускорение бинарника а про скорение его получения. Вот вы не заметили, а фурифокс у вас собрался не за один час в пакет а всего то за 59 минут 59 секунд, это же так существенно! :) Хотя учитывая финальную разницу в тестах выглядит как будто по пути LTO отвалилось, так что собралось ещё быстрее :) Я из более практических сообжений его хэётю: ускорение сборки не стоит возни с ним.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71

118. Сообщение от Аноним (118), 06-Окт-26, 15:24	+/–
> И Rust и, внезапно, Си++ позволяют обрабатывать такие ситуации > вообще без каких-либо спецэффектов, надо просто писать код правильно. В расте из коробки нормальное решение. Можно и лучше, но для дефолтного решения более чем достаточно. А в с++ любое решение нужно делать и в 99% случаев это не делается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #128

119. Сообщение от Аноним (39), 06-Окт-26, 15:37	+1 +/–
> В том же LLVM лто тесно связано с линкером, > Отдельная либа используемая линковщиком на стадии линковки. Чел, ты в состоянии прочитать ссылки, текст из которых приводишь? Он не "связан тесно" с линкером - линкер вызывает плагин компилятора (в данном случае libLTO), к которому никак не привязан. В GCC тот же подход.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116 Ответы: #124

120. Сообщение от Аноним (39), 06-Окт-26, 15:40	+1 +/–
> автор тактично умолчал что lto делается через плагины компилятора то люди которым тема особенностей сборки не сильно интереса подумали что это чудо ускорение будет всегда, а оно оказалось не так. А ты не заметил, что эти "люди" состоят из  одного-единственного опеннетного Ваньки? Которому не хватило ума разобраться в вопросе - вместо этого он рванул позориться и срывать покровы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #125

121. Сообщение от Аноним (39), 06-Окт-26, 15:43	+/–
> жаль что наш мастер нехеловротов не в курсе, что у таких проектов обычно "./mach" без возможности вмешаться в механику. > И никакой отдельной компиляцией там и близко не пахнет. Опеннетный пох держит марку: сам приплел левое соломенное чучело - сам его и уничтожил. 👍 Жаль, что по теме обсуждения ты сказать как всегда ничего не сможешь...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

122. Сообщение от Аноним (14), 06-Окт-26, 15:43	–2 +/–
> Да и в предметной области разбираются - как одно парнокопытное в апельсинах Пройдись по ссылке, и тем самым докажешь, что не очередной нейрослоупок! //llvm.org/docs/LinkTimeOptimization.html
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113 Ответы: #133

123. Сообщение от Аноним (39), 06-Окт-26, 15:46	+/–
> Об этом знают все кто осилил пролистать таблицу с бенчами на гитхубе проекта. Ну вот ты не знаешь и продолжаешь делать удивленные глаза, недоумевая, зачем нужен сабж. >> бинарь размером с десяток мегабайт > всего то на пару мегабайт бинаря Ваня, ты хоть читай, что тебе пишут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104 Ответы: #142

124. Сообщение от Аноним (14), 06-Окт-26, 15:48	–2 +/–
> Он не "связан тесно" с линкером - линкер вызывает плагин компилятора (в данном случае libLTO), к которому никак не привязан. Чувак, а ты попробуй использовать этот libLTO без линкера. То что он подключается к линкеру не делает его независимым от линкера, с логикой у тебя все в порядке? Это не просто отдельная стадия оптимизации, которая идет после стадии линковки, это оптимизация часть стадии линковки, опциональная - не обязательная. Оптимизация это часть той или иной стадии, ибо весь процесс поделен на стадии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119 Ответы: #132

125. Сообщение от Аноним (14), 06-Окт-26, 15:50	+/–
> Которому не хватило ума разобраться в вопросе - вместо этого он рванул позориться и срывать покровы. Чувак из новости LTO ускорил? Вот когда ускорит, пусть тогда и срывает покровы!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120 Ответы: #131

126. Сообщение от Аноним (39), 06-Окт-26, 15:52	+2 +/–
Ты продолжаешь героически накладывать себе в штаны. Впрочем, как и всегда. > компиляцию на проектах размером с llvm, chrome - где только make система будет все эти ваши исходники обходить и чекать на необходимость перекомпиляции по паре минут. По паре минут? А чего не паре часов? Мы же на опеннете: набрасывать так набрасывать! В реальности, Ваня, для больших проектов существует ninja, которая зависимости обрабатывает молниеносно. Буквально вот для Хрома была создана. Но даже обычный дубовый Make в нашем проекте отрабатывает за 4-5 секунд (хотя и это сильно бесит), а в Хроме в свое время было 10-20.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #139, #171

127. Сообщение от Аноним (39), 06-Окт-26, 15:56	+/–
Ваня, и ускорение инкрементальной сборки, и линковки нужно РАЗРАБОТЧИКАМ. А не таким, как ты. Тебе что-то объяснять бессмысленно - это уже давно понятно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108 Ответы: #135

128. Сообщение от Проходил мимо (?), 06-Окт-26, 16:00	+/–
//  Коробочное решение на Си++ #include <iostream> #include <vector> #define VEC_SIZE    4 int main( int argc, char* argv[] ) {     //  породим вектора на 10 элементов     std::vector<size_t> v(VEC_SIZE);     std::cout << "Обработка выхода за границы в Си++" << std::endl;     try     {         for(size_t idx = 0; idx <= VEC_SIZE*2; idx++)         {             std::cout << "Запись в вектор по индексу " << idx << std::endl;             std::cout.flush();             //  Оно самое             v.at(idx) = idx;         }         std::cout << "OK" << std::endl;     }     catch( const std::out_of_range& oor )     {         std::cerr << "Выход за границы вектора!" << std::endl;     }     return  0; }
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118 Ответы: #167

129. Сообщение от Аноним (39), 06-Окт-26, 16:01	+1 +/–
> LTO оно УСКОРЯТЬ не умеет. > Поэтому в реадми автор стыдливо про LTO ни разу не упоминает вообще. Автор не упоминает LTO в ридми, потому что в отличии от тебя, воинствующего невежды, прекрасно понимает, что линковщик не имеет никакого отношения к оптимизации во время LTO.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109 Ответы: #134, #153

130. Сообщение от Аноним (39), 06-Окт-26, 16:04	+/–
> Си++ позволяют > надо просто писать код правильно. О, вот и подъехало знаменитое, "чтобы не было ошибок - просто не делайте ошибок!".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #201

131. Сообщение от Аноним (39), 06-Окт-26, 16:06	+/–
> Чувак из новости LTO ускорил? А у чувака из новости была такая задача? Ты о чем вообще?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125 Ответы: #138, #145

132. Сообщение от Аноним (39), 06-Окт-26, 16:11	+1 +/–
> То что он подключается к линкеру не делает его независимым от линкера, с логикой у тебя все в порядке? Буквально делает. Ибо использовать плагин компилятора (та самая обертка над libLTO) ты можешь с любым линковщиком, который поддерживает интерфейс плагинов. Вот с тем же mold из новости. Или с гнутым gold. Поразительно, как местные персонажи рьяно спорят в темах, в которых ничего не шарят. Это болезнь какая-то, или что?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124 Ответы: #143, #151

133. Сообщение от Аноним (113), 06-Окт-26, 16:14    Скрыто ботом-модератором	+2 +/–
>> Да и в предметной области разбираются - как одно парнокопытное в апельсинах > Пройдись по ссылке, и тем самым докажешь, что не очередной нейрослоупок! > //llvm.org/docs/LinkTimeOptimization.html Ты же в курсе, что читать желательно все же чуть дальше заголока? И что "link time" совсем не означает, что это делает сам линковщик? И что сабж (который писал автор того самого lld), как и _предыдущие_ версии mold (на _плюсах_) умеет в lto (ЧСХ - и в связке с gcc)? Вот так вы, опеннетные кексперты по апельсинам и палитесь ...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122 Ответы: #136, #154

134. Сообщение от Ivan_83 (ok), 06-Окт-26, 16:15	–2 +/–
Ээээ Я то думал что LTO = Link Time Optimisation, действительно, причём тут линковщик.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129 Ответы: #148

135. Сообщение от Ivan_83 (ok), 06-Окт-26, 16:16	+/–
Каким таким разработчикам то? Ты объясни зачем ускорять то что менее 2 секунд занимает?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127 Ответы: #146

136. Сообщение от Аноним (14), 06-Окт-26, 16:19	–1 +/–
> Ты же в курсе, что читать желательно все же чуть дальше заголока? Повторяю, он лто ускорил?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133 Ответы: #175

137. Сообщение от Аноним (14), 06-Окт-26, 16:21	–4 +/–
> Нет, ибо LTO, внезапно, выполняется компилятором, а не линковщиком. бред, оптимизация это часть той или иной стадии, ЛТО это оптимизация на стадии линковки!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

138. Сообщение от Аноним (14), 06-Окт-26, 16:22	+/–
> А у чувака из новости была такая задача? Ты о чем вообще? Проехали, тогда, ты комент начальный прочти, речь за лто. Когда ускорит лто, тогда и пиши в новостях об этом!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131 Ответы: #141

139. Сообщение от Ivan_83 (ok), 06-Окт-26, 16:26	–2 +/–
> молниеносно это сколько? > а в Хроме в свое время было 10-20 Когда было то? При царе горохе? Хром как то при очередном обновлении стал компелять не 20+к файлов а 30к+, а сейчас все 55к+ файлов компелячит. > обычный дубовый Make в нашем проекте отрабатывает за 4-5 секунд (хотя и это сильно бесит) Вам нервы лечить надо или воркфлоу менять раз для вас это так заметно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126 Ответы: #144

140. Сообщение от Аноним (140), 06-Окт-26, 16:26	+/–
> бубунту это общемировой меинстрим и остриё прогресса Да. Как и любая корпорация они ищут новые возможности. Они пробуют разные решения. Некоторые удачные, некоторые нет. А кто у тебя на острие? Дебиан окаменевший? Сорта г̶о̶в̶ ненужно-БЗДей которыми пользуются или фрики, или полторы корпы которые на свою голову связались с этими поделками?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115 Ответы: #150

141. Сообщение от Аноним (39), 06-Окт-26, 16:29	+/–
> Проехали, тогда, ты комент начальный прочти, речь за лто. В начальном комменте этой ветке обсуждения вообще не упоминается LTO. Ты о чем вообще?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138 Ответы: #147

142. Сообщение от Ivan_83 (ok), 06-Окт-26, 16:31	+/–
Что читать то? У автора mold самый худьший результат обычным линковщиком 50 секунд, такой проект там один. Остальные меньше 20 секунд (кроме хрома) - в пределах 6 секунд обычным линковщиком. Вот объясните мне почему вам лично эти секунды так важны? У вас там разработка методом брутфорса чтоли?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123

143. Сообщение от Аноним (14), 06-Окт-26, 16:33	–2 +/–
> Буквально делает. Ибо использовать плагин компилятора (та самая обертка над libLTO) ты > можешь с любым линковщиком, который поддерживает интерфейс плагинов. Вот с тем > же mold из новости. Или с гнутым gold. А чем еще должна быть шаренная библиотека как не подключаемым интерфейсом? Без информации от линкера эта библиотека не нужна никакой другой стадии процесса компиляции. Повторяю, у тебя с логикой все в порядке? > Поразительно, как местные персонажи рьяно спорят в темах, в которых ничего не > шарят. Это болезнь какая-то, или что? Повторяю альтернативно одаренным, автор новости LTO ускорил? Нет - проходи мимо! Ибо хоть и опциональна оптимизация, на той или иной стадии компиляции, от нее и зависит вся скорость компиляции конечной программы, а не от переписывания с помощью ЫЫ обычного кода конкатенации файлов. Как там говорится - экономия на спичках?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132 Ответы: #157

144. Сообщение от Аноним (39), 06-Окт-26, 16:37	+/–
>> молниеносно > это сколько? Меньше секунды. >> а в Хроме в свое время было 10-20 > Когда было то? При царе горохе? Это было во времена, когда в Хроме юзался make. Научись читать, что тебе пишут. >> обычный дубовый Make в нашем проекте отрабатывает за 4-5 секунд (хотя и это сильно бесит) > Вам нервы лечить надо или воркфлоу менять раз для вас это так заметно. Да, сейчас ванька-хэллоуворлдщик, не понимающий, что такое инкоементальная сборка, расскажет мне о правильном воркфлоу. Господи...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139 Ответы: #155

145. Сообщение от Ivan_83 (ok), 06-Окт-26, 16:38	+/–
Проект выглядит как скам. 1. великий автор пиливший LLVM решили запилить свой линковщик х100 - почему? Почему это не взяли в llvm если оно такое хорошее? 2. Нигде не упомянуто что LTO не ускоряется. Те где то мелким текстом на какомнить иссуе или в глубине документации. Между тем это прямо мастхэв фича очень часто сейчас. Зато бенчей с ускорением в разы обычной не LTO сборки полно. 3. Куча каких то непонятных спонсоров которым якобы это надо. Притом что никто не может объяснить что делать с ускорением в х2-х10 стадии которая занимает 0,0001% от всего воркфлоу. (если оно применимо без LTO)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131 Ответы: #149

146. Сообщение от Аноним (39), 06-Окт-26, 16:38	+/–
> Ты объясни зачем ускорять то что менее 2 секунд занимает? Тебе - незачем. Я, по-моему, ясно написал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135 Ответы: #156

147. Сообщение от Аноним (14), 06-Окт-26, 16:42	+/–
читай этот 2.21, Ivan_83 (ok), 00:28, 06/10/2026
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141

148. Сообщение от Аноним (39), 06-Окт-26, 16:44	+/–
> Я то думал что LTO = Link Time Optimisation, действительно, причём тут линковщик. Вот именно, Ваня, вот именно. Увидел совпадение по первому слову - и "дальше все как в тумане". Подумать, почему там именно "link time" (ключевое слово time) а не, например, "linkage/linker", почитать статьи по теме, разобраться - это все не про тебя.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134 Ответы: #158

149. Сообщение от Аноним (14), 06-Окт-26, 16:47	+/–
> Притом что никто не может объяснить что делать с ускорением в х2-х10 стадии которая занимает 0,0001% от всего воркфлоу. (если оно применимо без LTO) Беда не в этом, альтернативно одаренные думают, что оптимизация это некая отдельная фаза (стадии) компиляции, хотя понятия не имеют, что оптимизация это часть процесса той или иной фазы компиляции. Собственно LTO это часть фазы линковки, и непосредственно хоть и опционально является частью линковщика, а не отдельным независимым компонентом (фазой, стадией). А конкретно в том же LLVM эту часть сделали в виде шаренной библиотеки лишь потому, чтобы можно было его прицепить к любому линковщику, и от этого эта шаренная библиотека не становиться независимой, она часть линкера буквально!!!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145 Ответы: #152

150. Сообщение от Ivan_83 (ok), 06-Окт-26, 16:48	+/–
Нету уже острия, OpenBSD и само ядро Linux ещё как то трепыхаются, остальное уже давно в стадии поддержки и никаких прорывных и просто интересных инноваций нет. Все теперь тащат друг у друга фичи которых ещё нет. В остальном оно как электрики: электрификация страны завершена, теперь только поддержка нужна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140

151. Сообщение от Аноним (14), 06-Окт-26, 16:50	+/–
если шаренная библиотека подключается к любой программе, она становится частью программы? libLTO подключенная к линкеру mold является частью mold? Нет? Можешь не отвечать, тогда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132

152. Сообщение от Ivan_83 (ok), 06-Окт-26, 16:54	+/–
Честно говоря большинству эта информация бесполезна, как оно там работает под капотом компилятора и линкера. Просто тут бегают какие то странные которые считают что нужно идеальное знание и языка и компилятора и линкера и все тонкости с UB и пр. А на практике это нужно совсем редко-почти никогда, а знать надо как работают штуки написанные на всяком разном.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149 Ответы: #159

153. Сообщение от Аноним (14), 06-Окт-26, 16:54	–4 +/–
> Автор не упоминает LTO в ридми, потому что в отличии от тебя, воинствующего невежды, прекрасно понимает, что линковщик не имеет никакого отношения к оптимизации во время LTO. Повторяю, оптимизация это часть того или иного процесса (фазы, стадии), и LTO это оптимизация на стадии линковки, то есть часть процесса линковки - собственно линкера!!!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129

154. Сообщение от Аноним (14), 06-Окт-26, 16:58	+/–
>И что "link time" совсем не означает, что это делает сам линковщик? "link time" это стадия работы линковщика, а сам линковщик еще опционально включает свою оптимизацию, свою, которая подключается через шаренную библиотеку libLTO. Ели к той или иной программе подключается та или иная шаренная библиотека, она становится частью процесса программы? НЕТ? тогда все ясно, можете не отвечать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133

155. Сообщение от Ivan_83 (ok), 06-Окт-26, 17:00	–1 +/–
Меньше секунды - это ваши фантазии. Выполнить все необходимые действия для инкрементальной сборки на 55к файлов занимает больше времени. > Да, сейчас ванька-хэллоуворлдщик, не понимающий, что такое инкоементальная сборка, расскажет мне о правильном воркфлоу. То ли дело божественный аноним, который знает и умеет всё на свете лучше всех! Если у вас там разработка методом: "тысяча обезъян напишут роман" то понимаю что время линковки для вас важно :) В обычном воркфлоу линковка это сильно меньше 1% времени, и обсуждать там какую то оптимизацию или укорение смысла не имеет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #144 Ответы: #161

156. Сообщение от Ivan_83 (ok), 06-Окт-26, 17:01	+/–
Нет, ты ничего не написал кроме своих неуклюжих оскорблений.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146 Ответы: #163

157. Сообщение от Аноним (39), 06-Окт-26, 17:03	+/–
> А чем еще должна быть шаренная библиотека как не подключаемым интерфейсом? > Повторяю, у тебя с логикой все в порядке? Чел, у тебя, наверное, СДВГ, но давай вместе пройдемся по нити дискусии: 1. Сперва я говорю "любой линковщик работает через плагин компилятора. Ибо ту самую оптимизацию выполняет именно компилятор, а не линковщик." 2. Всплываешь ты с заявлением "в LLVM лто тесно связано с линкером, оптимизатор там как отдельная либа к линкеру" и "отдельная либа используемая линковщиком на стадии линковки". Видимо, в твоих глазах эти утверждения как-то опровергают мой изначальный тезис. Поэтому... 3. ...дальше я тебе еще два раза повторяю изначальное утверждение, что "линкер вызывает плагин компилятора (в данном случае libLTO), к которому никак не привязан" и "использовать плагин компилятора ты можешь с любым линковщиком, который поддерживает интерфейс плагинов". Ты же продолжаешь искренне недоумевать где здесь логика. Но чтобы видеть логику, друг, надо уметь держать контекст обсуждения. > Повторяю альтернативно одаренным, автор новости LTO ускорил? Альтернативно одаренный здесь только ты, ибо автор в принципе не ставил себе задачи ускорять LTO.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143 Ответы: #165

158. Сообщение от Ivan_83 (ok), 06-Окт-26, 17:07	–1 +/–
А зачем мне это? Я в данном случае потребитель конечного продукта, и как разработчик и как меинтейнер. Я не занимаюсь разработкой компиляторов или линкеров - это слишком узкая область за пределами моих интересов. Как меинтейнеру мне mold не интересен: 1. ускорение не существенно 2. возни с mold слишком много 3. LTO оно не ускоряет и бесмысленно для таких проектов Как разработчику: 1. у меня длинный воркфлоу, а линковка там менее 1% времени занимает. 2. опять же тратить только время на возьню с поддержкой Вы то чего ради спорите? У вас точки зрения даже не просматривается, вы просто пришли сюда посыпать оскорблениями.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148 Ответы: #166

159. Сообщение от Аноним (14), 06-Окт-26, 17:10	+/–
//llvm.org/docs/LinkTimeOptimization.html Вот черным по белому: """ Phase 3 : Optimize Bitcode Files After symbol resolution, the linker tells the LTO shared object which symbols are needed by native object files. In the example above, the linker reports that only foo1() is used by native object files using lto_codegen_add_must_preserve_symbol(). Next the linker invokes the LLVM optimizer and code generators using lto_codegen_compile() which returns a native object file created by merging the LLVM bitcode files and applying various optimization passes. """ Внимание на "Next the linker invokes the LLVM optimizer and code generators using lto_codegen_compile()"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152

160. Сообщение от Ivan_83 (ok), 06-Окт-26, 17:15	+/–
Это к вопросу о дурацких дефолтах и тому что система в ванильном виде это конструктор а не конечный продукт. Оно там включено по дефолту скорее всего для тех кто занимается кросскомпеляцией, всех полутора человек :) Когда появилось - смотреть лень, я давно выключил всё ненужное и забыл. Собственно у меня можно сказать что свой собственный дистр фри, ибо достаточно много отличий от дефолта, не только конфигами но и патчи есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111 Ответы: #170

161. Сообщение от Аноним (39), 06-Окт-26, 17:16	+/–
> Меньше секунды - это ваши фантазии. > Выполнить все необходимые действия для инкрементальной сборки на 55к файлов занимает больше времени. Ты вообще никогда не сталкивался ни с инкрементальной сборкой, ни с ninja - но при этом вещаешь про якобы фантазии и сколько времени оно занимает. Господи, какой же сказочный персонаж... 🤦 >> Да, сейчас ванька-хэллоуворлдщик, не понимающий, что такое инкоементальная сборка, расскажет мне о правильном воркфлоу. > То ли дело божественный аноним Внезапно, аноним, в отличие от тебя, работает всю жизнь C++ кодером и потому банально сталкивался с проблемой и знает, о чем говорит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #155 Ответы: #164

162. Сообщение от name (??), 06-Окт-26, 17:17	+/–
А как ещё сделать рандомизацию? Ты что, хочешь чтобы его ОТСЛЕДИЛИ??!!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

163. Сообщение от Аноним (39), 06-Окт-26, 17:20	+/–
> Нет, ты ничего не написал кроме своих Именно что написал. Особенно в других ветках обсуждения. И даже с цифрами, для сравнения. Вот если бы ты еще читал не пятой точкой... Или хотя бы пошел таки почитал, что такое инкрементальная сборка и в каких случаях она нужна... Или о том, как работает LTO... Но нет же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #156 Ответы: #168

164. Сообщение от Ivan_83 (ok), 06-Окт-26, 17:22	–3 +/–
Да сразу видно божественный аноним лучше меня знает с чес я работал и работаю :) И кодером (перекладчиком с русского на кресты?) работает больше чем я существую, понятно же :))) Мы конечно же поверим божеству на слово, даже я про свой опыт и знания теперь буду только у вас спрашивать :)))))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161 Ответы: #169

165. Сообщение от Аноним (14), 06-Окт-26, 17:30	+/–
> Чел, у тебя, наверное, СДВГ Читать разучился? Если не прошелся по ссылке - нейрослоупок!!! //llvm.org/docs/LinkTimeOptimization.html Вот черным по белому: """ Phase 3 : Optimize Bitcode Files After symbol resolution, the linker tells the LTO shared object which symbols are needed by native object files. In the example above, the linker reports that only foo1() is used by native object files using lto_codegen_add_must_preserve_symbol(). Next the linker invokes the LLVM optimizer and code generators using lto_codegen_compile() which returns a native object file created by merging the LLVM bitcode files and applying various optimization passes. """ Внимание на "Next the linker invokes the LLVM optimizer and code generators using lto_codegen_compile()" --------------------------------------------------------------------- > 1. Сперва я говорю "любой линковщик работает через плагин компилятора. Ибо ту самую оптимизацию выполняет именно компилятор, а не линковщик." Оптимизация это часть процесса той или иной стадии!!! LTO это оптимизация на стадии линковки, эту оптимизацию запускает линкер!!! Любой другой стадии компиляции в LTO нет необходимости. > 2. Всплываешь ты с заявлением "в LLVM лто тесно связано с линкером, оптимизатор там как отдельная либа к линкеру" и "отдельная либа используемая линковщиком на стадии линковки". Видимо, в твоих глазах эти утверждения как-то опровергают мой изначальный тезис. Поэтому... "любой линковщик работает через плагин компилятора" - этот "плагин" тесная связь компилятора с линковщиков, в процессе используется собранная оптимизатором llvm инфа и линковщиком, чтобы провести так называемую link-time оптимизацию. Там по ссылке пример есть и четко написано "This example illustrates the advantage of tight integration with the linker. Here, the optimizer can not remove foo3() without the linker’s input." И далее пишут объясняют причины по которым приняли такое решение о тесной интеграции: """ Alternative Approaches Compiler driver invokes link time optimizer separately. In this model the link time optimizer is not able to take advantage of information collected during the linker’s normal symbol resolution phase. In the above example, the optimizer can not remove foo2() without the linker’s input because it is externally visible. This in turn prohibits the optimizer from removing foo3(). """ Вот почему LTO не независимый процесс, а тесная интеграция с линковщиком. И почему именно в виде шаренной либы: """ Use separate tool to collect symbol information from all object files. In this model, a new, separate, tool or library replicates the linker’s capability to collect information for link time optimization. Not only is this code duplication difficult to justify, but it also has several other disadvantages. For example, the linking semantics and the features provided by the linker on various platform are not unique. This means, this new tool needs to support all such features and platforms in one super tool or a separate tool per platform is required. This increases maintenance cost for link time optimizer significantly, which is not necessary. This approach also requires staying synchronized with linker developments on various platforms, which is not the main focus of the link time optimizer. Finally, this approach increases end user’s build time due to the duplication of work done by this separate tool and the linker itself. """ > 3. ...дальше я тебе еще два раза повторяю изначальное утверждение, что "линкер вызывает плагин компилятора (в данном случае libLTO), к которому никак не привязан" и "использовать плагин компилятора ты можешь с любым линковщиком, который поддерживает интерфейс плагинов". Они сами и пояснили по какой причине они приняли такое архитектурное решение, и это не делает LTO независимым от линкера. Повторяю еще раз, LTO это часть процесса линковщика под названием оптимизация!!! > Ты же продолжаешь искренне недоумевать где здесь логика. Но чтобы видеть логику, друг, надо уметь держать контекст обсуждения. Еще раз пройдись по ссылке если не нейрослоупок. Моя цель, донести до тебя, что LTO это часть линкера!!! Эта оптимизация которую вызывает линкер. А как эта часть кода исполнена, зашита в линкер или подключена через шаренную библиотеку, не имеет значения. Вот тут хоть включи логику!!! > Альтернативно одаренный здесь только ты, ибо автор в принципе не ставил себе задачи ускорять LTO. Мне все равно, что он ставил перед собой, для меня лично, ускорить линкер это ускорить процесс оптимизации на фазе линковки, а тупое конкатенирование файлов для меня не ускорение!!! В чем собственно и изначальная претензия к данной новости!!!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157

166. Сообщение от Аноним (39), 06-Окт-26, 17:33	+/–
> А зачем мне это? Чтобы, например, не позориться и не срывать покровы на уровне "LTO оно не умеет" и "бесполезный линковщик". > Я в данном случае > Я не занимаюсь > мне mold не интересен Вот, теперь ты наконец-то запел про "я" и "мне", хотя изначально с апломбом утверждал, что он "никому не нужен". > У вас точки зрения даже не просматривается Моя точка зрения (довольно очевидная по предыдущим сообщениям), что ты, будучи феерически некомпетентным в проблематике сабжа, имеешь глупость распространять тут ересь о том, что сабж якобы бесполезен, никому не нужен и "не умеет в LTO". Так понятнее, или ещё раз повторит?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #158 Ответы: #174, #205

167. Сообщение от morphe (?), 06-Окт-26, 17:39	+/–
И несмотря на существование vector::at, большинство кода делает [], потому что так привыкли
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128

168. Сообщение от Ivan_83 (ok), 06-Окт-26, 17:39	+/–
Кто вас анонимов резберёт, вот поха я отличаю как и прочие знакомые ники, а вы раз прячитесь за анонимом то и страдайте теперь. Я вам уже ответил - инкрементальная сборка в моих случаях даром не нужна, но вы никак не можете принять что другим плевать на те знания которые у вас есть. И вам или другому анониму я расписывал как она устроена и что на шелл скрипт билд системе её добавить не сложно - буквально меньше 100 строк. Потому, похоже что, кроме слова инкрементальная и галочки в вижал студии её включающую вы сами о ней ничего не знаете.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #163 Ответы: #172

169. Сообщение от Аноним (39), 06-Окт-26, 17:41	+1 +/–
> Да сразу видно божественный аноним лучше меня знает с чес я работал и работаю :) Конечно знаю, ведь ты сам об этом во всех подробностях прямым текстом пишешь прямо тут, на Опеннете - у тебя же язык, как помело. За последние ~3 года, что я тут читаю твою экспертизу, картина сложилась кристально чистая. > Да сразу видно божественный аноним лучше меня знает > Мы конечно же поверим божеству на слово Меня искренне умиляет, как ты тщетно пытаешься в ad hominem. Надеюсь, у тебя все-таки хватит ума пойти да прочитать про инкрементальную сборку и работу LTO, чтобы не впредь больше не позориться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164 Ответы: #180

170. Сообщение от пох.. (?), 06-Окт-26, 17:46	+/–
> Это к вопросу о дурацких дефолтах не, не. Еще раз - этой фичи просто не было в компиляторе, вообще. Он заточен был собирать сразу все и целиком. Возможность частичной сборки - это бсдшный патч поверх, и когда я это последний раз смотрел - его не удалось пропихнуть обратно разработчикам llvm. кажется, отключение сборки всяких анализаторов и прочего хлама тоже изначально пошло из фри, где оно вот вообще никому не уперлось. Я очень долго держал у себя уже непопулярную сборку на gcc, потому что ждать часами на том железе пока эта ненужная хрень собирает саму себя в миллионе ненужных вариантов очень не хотелось. (потом мы конечно убедились что даже если это все выключить, все равно ждать часами. плюсовые компиляторы тормоза.) И енти люди пришли учить нас делать быстрые линкеры, хахаха.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160 Ответы: #179

171. Сообщение от пох.. (?), 06-Окт-26, 17:50	–1 +/–
> молниеносно. Буквально вот для Хрома была создана. Но даже обычный дубовый > Make в нашем проекте отрабатывает за 4-5 секунд (хотя и это то есть ваш проект и есть хеловрот. (даже у меня к сожалению нифига не пять секунд, а это вовсе не "большой проект") > а в Хроме в свое время было 10-20. то есть очень давно. Показать нам как ты изменил дату на одном файлике в современном хроме и сколько оно после этого собирается - ты конечно же не захочешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126 Ответы: #183

172. Сообщение от Аноним (39), 06-Окт-26, 17:55	+/–
> Я вам уже ответил - инкрементальная сборка в моих случаях даром не нужна, но вы никак не можете принять что другим плевать на те знания которые у вас есть. Не, друг, это как раз ты никак не можешь понять, что другим плевать на ТВОИ хэллоуворлдные случаи. И потому продолжаешь на их основе давать экспертную оценку нужности таких вещей, как сабж и полноценные билд-чистемы. Естественно, ничего, кроме фейспалма, такая экспертиза не вызывает. > Потому, похоже что, кроме слова инкрементальная и галочки в вижал студии её включающую вы сами о ней ничего не знаете. Чувак, ну вот зачем ты только что сам себе подкинул в штаны? Кто тебя за язык тянул? Инкрементальну борку не нужно "включать", и никакой "галочки" для нее не существует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #168 Ответы: #188

173. Сообщение от пох.. (?), 06-Окт-26, 17:56	+/–
> Как только появилась новость о том что штатный компновщик LLVM стал мочь > в многопоток, разрабы mold тут же ришили попиарится и показать свою причем тут Opus? Он ничего не решал такого ;-) > нетакусесть, исход у таких проектов один, через год проект исчезнет из это зависит - ему какой-нибудь токийский универ оплачивает подписку или сам, все сам. Если первое - не вижу что мешает ему и через десять лет тихо пилить грантик в числе других прочих. Грантопил спит, опус трудится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

174. Сообщение от Аноним (14), 06-Окт-26, 17:56	–1 +/–
> Чтобы, например, не позориться и не срывать покровы на уровне "LTO оно не умеет" и "бесполезный линковщик". Логику включи, без LTO любой линковщик - бесполезный, а то что в самом mold нет кода LTO не говорит о том, что он как линковщик не использует LTO через шаренную либу. Если бы ваш mold не использовал бы LTO он точно был бы бесполезным. В контексте новости полученное "ускорение" является таким же бесполезным, ибо большую часть времени занимает именно LTO!!!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166 Ответы: #200

175. Сообщение от Аноним (113), 06-Окт-26, 17:58	+1 +/–
> Повторяю, он лто ускорил? Не-не-не Дэвид Блейн, ты писал > что вы там говорили про LTO? Видать там ускорение получено за счет выпиливания того самого LTO :))) хотя в тексте новости сразу же в первом и втором предложении "в качестве более быстрой прозрачной замены" и "является очень высокая скорость связывания объектных файлов, заметно опережающая компоновщики". Просто ты, как истинный знаток опеннета, не в курсе, что LTO - это к̵о̵с̵т̵ы̵л̵ь̵ ̵д̵л̵я̵ глобальной оптимизации _всей программы_ ("...Despite the "link time" name, LTO does not need to use any special linker features."), причем выполняемая компилятором, который для этого добавляет свой промежуточный код в файлы. А во время линковки - потому что классический-традиционный подход "пофайловая компиляция" позволял/ет скомпилировать даже большой проект на буквально паре КБ ОЗУ (что было актуально в 70-80 даже для суперкомпов), но в результате у компилятора тупо нет информации, из каких именно частей состоит ВЕСЬ бинарь. Эта инфа однако (опять таки - традиционно) передается линковщику т.е. появляется во время линковки ... но с самой линковкой связанно буквально никак, лишь удобный способ сделать "универсально" и не ломая совместимость (в отличие от расширения самого ЯП или спец. интерфейса для систем сборки или спец. файла для компилятора). Хотя чисто теоретически, можно добавить какое нибудь расширение "project files used" на ввод для gcc/шланга и оно будет делать то же самое - глобальную оптимизацию, причем ДО стадии линковки. --- > Link time optimization is implemented as a GCC front end for a bytecode representation of GIMPLE that is emitted in special sections of .o files. > By default, object files generated with LTO support contain only GIMPLE bytecode. Such objects are called “slim”, and they require that tools like ar and nm understand symbol tables of LTO sections. > One of the main goals of the GCC link-time infrastructure was to allow effective compilation of large programs. For this reason GCC implements two link-time compilation modes. > 1)    LTO mode, in which the whole program is read into the compiler at link-time and optimized in a similar way as if it were a single source-level compilation unit. > 2)    WHOPR or partitioned mode, designed to utilize multiple CPUs and/or a distributed compilation environment to quickly link large applications. WHOPR stands for WHOle Program optimizeR Т.е. чувак ускорил сам процесс линковки, за ускорением LTO - обращайся к разрабам LLVM/GCC.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136 Ответы: #184

177. Сообщение от пох.. (?), 06-Окт-26, 18:02	+/–
>>  Тут всё же не раст виноват. > А он как всегда ни в чем не виноват. Подозрительно, не правда > ли? не, все ок. Когда разрабы не могут в разработку - начинается то хруст, то переписывание интерфейса на html5. Ни хруст, ни html5 в общем действительно не виноваты. Ну и у ruffle же 82% все же получились... к моменту, правда, когда никому уже в целом свете было ненужно, но мы ж не имеем плюсового проекта для сравнения (и честно-то говоря - вряд ли бы вышло хорошо, учитывая что основной target там wasm.) И это у них еще не было ЫЫ!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114

178. Сообщение от пох.. (?), 06-Окт-26, 18:12	+/–
> Когда уже гну си компилер перепишут на раст, сил моих больше нет > терпеть это! Хочется уже безопастности как у более развитой части человечества так это ж - был же не переписанный а прям с нуля разработанный сворой ЫЫ агентов, этот, как его - https://github.com/anthropics/claudes-c-compiler Чего ж ты ждешь-то?! Бери, бери, пользуйся - совершенно безопастно ведь! И линуксное ведро даже компилирует! (что оно потом загрузится, правда, никто не обещал) А если токенов не пожалеешь - фабля 5.1 наверное даже сможет его с мертвой точки сдвинуть. > в нпм или пупи. э... вот лефтпадов к нему пока не написали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87

179. Сообщение от Ivan_83 (ok), 06-Окт-26, 18:16	+/–
Так фишка фри в том, что они никогда не юзают сборочную систему проекта который втаскивают. Всё переписано на bmake. И LLVM собирается через bmake а не cmake. Потому фревым разрабам пофик что там в апстриме, они всё равно сами за сборку отвечают. Вот меинтейнеры из портов могли ходить в апстрим чтобы ненужно хлам не собирать, они как раз cmake и всё что апстрим вывалит юзают. Но надо сказать что первые версии llvm которые ещё 3.5 были - собирались очень быстро, у меня тогда ещё были пень3 местами и не больше коредуо точно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #170

180. Сообщение от Ivan_83 (ok), 06-Окт-26, 18:20	–1 +/–
Да да, верь и дальше, я же всегда всё пишу без стёба. За эти 3 года я стал для тебя знаменитостью, хоть и трешовой, а ты как был никем так и дальше никто :) Чувак, раз ты не можешь понять что я пишу - хотя бы попробуй объяснить: зачем это надо знать? Что тебе лично дали эти знания?)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #169

181. Сообщение от черпало (?), 06-Окт-26, 18:28	+1 +/–
> в то время как в Rust за временем жизни следит компилятор только после тысяч приседаний с закорючками владения (гениально засунуть это в тип, бгг) то там овладел, то тут, крррасотиищща! Но утятам, что слаще редьки не едали, -- норм, гениальное решение на острие прогресса!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #219

182. Сообщение от черпало (?), 06-Окт-26, 18:31	+/–
Раньше раки были большие, но по три, а теперь маленькие, но по пять
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101

183. Сообщение от Аноним (39), 06-Окт-26, 18:34	+/–
> то есть ваш проект и есть хеловрот. Ну да, типичный такой хэловрот объемом более 1.6 млн строк. > даже у меня к сожалению нифига не пять секунд, а это вовсе не "большой проект" При чем тут ты вообще? Я писал за наш кейс, и за скорость сборки на моем конкретном железе. Что и на каком железе ты там собираешь - я хз, мне не интересно. >> а в Хроме в свое время было 10-20. > то есть очень давно. Вот именно, что очень давно. Сейчас, очевидно, будет еще дольше. Ты что сказать-то хотел?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #171 Ответы: #197

184. Сообщение от Аноним (14), 06-Окт-26, 18:35	–2 +/–
> Не-не-не Дэвид Блейн, ты писал >> что вы там говорили про LTO? Видать там ускорение получено за счет выпиливания того самого LTO :))) А что по вашему сделал LLVM? Он буквально выпилил LTO из линковщика, ради чего, описано вот тут: //llvm.org/docs/LinkTimeOptimization.html LTO это оптимизация на этапе линковщика, это его часть работы (код этой работы вынесли в отдельную либу), вы этого никак понять не хотите!!! > хотя в тексте новости сразу же в первом и втором предложении "в > качестве более быстрой прозрачной замены" и "является очень высокая скорость связывания > объектных файлов, заметно опережающая компоновщики". Мои претензии в том, что курам на смех такое ускорение линковщика, ибо без LTO, а он буквально без LTO, так как LLVM решил его выпилить из линкера, и без ускорения LTO такой "быстрый" линкер никому не сдался. Так понятна моя претензия? > Просто ты, как истинный знаток опеннета, не в курсе, что LTO - > это к̵о̵с̵т̵ы̵л̵ь̵ ̵д̵л̵я̵ > глобальной оптимизации _всей программы_ ("...Despite the "link time" name, LTO does > not need to use any special linker features."), причем выполняемая компилятором, > который для этого добавляет свой промежуточный код в файлы. Оптимизация это часть любой стадии (фазы) процесса компиляции. Когда вы говорите "причем выполняемая компилятором" - это полный бред, все в процессе компиляции можно назвать "выполняется компилятором" и тот же процесс линковки. "Компилятор" (процесс подготовки нативного объектного кода) не может применять LTO, так как процессом компоновки занимается  компоновщик (линкер), LTO это прерогатива компоновщика. > Хотя чисто теоретически, можно добавить какое нибудь расширение "project files used" на > ввод для gcc/шланга и оно будет делать то же самое - > глобальную оптимизацию, причем ДО стадии линковки. А еще можно все обозвать один названием, "дай мне экзешник". Не я придумал разделения на стадии (фазы) весь процесс под названием "компилирование", как компиляция+компоновка! И у каждой стадии есть понятие оптимизация, LTO это оптимизация стадии компоновки и точка!!! Почему в llvm она вынесена в отдельную шаред либу по ссылке выше объяснено!!! Говорить, что "компоновщик" только компанует, в 21 веке абсурдно, бесполезен такой компоновщик. Не просто так с бодуна появилось понятие "оптимизации во время компоновки", в этом есть необходимость. И если возвращаться к претензии, то ускорять в любом компоновщике нужно именно процесс оптимизации, а не конкатенацию файлов. > Т.е. чувак ускорил сам процесс линковки, за ускорением LTO - обращайся к > разрабам LLVM/GCC. Так с этим никто не спорит, я акцентировал на то, что LTO выпилен из компоновщика, сделал это LLVM или сам автор мне до лампочки. Факт в том, что этот компоновщик без LTO (собственным), так как он выпилен из него и сделан в виде подключаемого модуля (плагина, шаренной библиотеки). Если бы он еще ускорил бы libLTO то было бы другое дело, а так - курам на смех его ускорение. Так ясна мысль?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175

188. Сообщение от Ivan_83 (ok), 06-Окт-26, 18:51	–2 +/–
Со всем этим есть ровно две проблемы: 1. вы такой умный только со своих же слов. Ваших достижений никто никогда не видел. А из ваших слов не видно чтобы вы чем то владели или знали. (пох, нах, Тимур и некоторые другие - периодически пишут что то интересное и с явным глубоким знанием темы) 2. даже в рамках якобы своих помпетенций вы не можете "продать" ни инкрментальную компиляцию ни прочие тайные познания которыми вы тайно владеете. Даже банально объяснить пользу этого ненужно линкера вы не в состоянии. PS: самое смешное что обычно такие умники гордятся знаниями тех же крестов, но продать ценность этого знания они никогда не в состоянии. На аргумент что вместо 1к страниц бесполезно спеки крестов я лучше освою язык по проще и в придачу пару других технологий из RFC или вообще из реального мира какие навыки приобрету - им возразить нечем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #172 Ответы: #194

192. Сообщение от Герман (??), 06-Окт-26, 19:16	+/–
C++
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

194. Сообщение от Аноним (39), 06-Окт-26, 20:05	–1 +/–
> из ваших слов не видно чтобы вы чем то владели или знали. В том-то и дело, друг, что твои "знания" из твоих же слов видно идеально четко. Об этом-то и речь. > даже в рамках якобы своих помпетенций вы не можете "продать" ни инкрментальную компиляцию С чего ты взял, что я пытаюсь тебе что-то "продавать". Особенно инкрементальную сборку (лол), которую буквально любой без исключения C++ кодер использует по сто раз на дню. > Даже банально объяснить пользу этого ненужно линкера вы не в состоянии. Пользу я тебе уже объяснял (да и в новости-то написано) но ты, будучи "интересной личностью", продолжаешь твердить что ТЕБЕ оно не нужно (хотя о тебе речи вообще не шло). > самое смешное что обычно такие умники гордятся знаниями тех же крестов, но продать ценность этого знания они никогда не в состоянии Самое смешное, что тебе хватило ума ляпнуть такое человеку, который буквально все взрослую жизнь зарабатывает себе на хлеб кодингом на C++ в частности. Никогда не в состоянии продать, ага. Вдвойне смешно, что ты это ляпнул после того, как сам гордо признался, что никогда не работал программистом. То есть буквально не смог продать свои "знания", которых, как ты сам неоднократно подтверждал, годятся только для хэллоуворлдов. У тебя воистину феноменальный талант гадить себе же в штаны. 👍
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #188 Ответы: #198, #199

197. Сообщение от пох.. (?), 06-Окт-26, 21:19	+/–
> При чем тут ты вообще? Я писал за наш кейс, и за скорость сборки на моем конкретном > железе. и прям твое супержелезо упирается в немодный ld? (и LTO конечно отключен, отключен же?) > Вот именно, что очень давно. Сейчас, очевидно, будет еще дольше. Ты что сказать-то хотел? что тебя скорее всего ждет интересный сюрприз при попытке поредактировать один файлик. (хотя что-то я не очень верю что ты сможешь)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #183 Ответы: #213

198. Сообщение от Ivan_83 (ok), 06-Окт-26, 21:21	+/–
> В том-то и дело, друг, что твои "знания" из твоих же слов видно идеально четко. Видно кому? Тому кто не в состоянии воспринять и половины того что я пишу?) > С чего ты взял, что я пытаюсь тебе что-то "продавать". Особенно инкрементальную сборку (лол), которую буквально любой без исключения C++ кодер использует по сто раз на дню. С того что вы постоянно про неё пишите. А продать не можете потому что не в состоянии объяснить нафиг она мне сдалась. > Пользу я тебе уже объяснял (да и в новости-то написано) но ты, будучи "интересной личностью", продолжаешь твердить что ТЕБЕ оно не нужно (хотя о тебе речи вообще не шло). Да вот только ответ мой до вас не дошёл, повторю: мне 2 секунды на полную пересборку мелких проекто не жалко, от того что она станет в отдельных случаях 0,5с я счастливее не стану. А большие проекты я как меинтейнер в основном собираю, не делая правок или мне сильно дешевле на ccache положится черем с инкрементальностью возится в чужом то проекте. Вот поэтому у вас ничего не продаётся. > Самое смешное, что тебе хватило ума ляпнуть такое человеку, который буквально все взрослую жизнь зарабатывает себе на хлеб кодингом на C++ в частности. Никогда не в состоянии продать, ага. Речь не про продажу своей тушки работодателю, а про продажу того чем вы так гордитесь, что вас там кормит и тп. Я про свою билд систему на шелл скрипте довольно долго тут рассказывал, как и про другие штуки которые я сделал. Этого достаточно чтобы донести что такое есть и может заинтересовать = привлечь пользователя. Попробуйте проделать тоже самое с крестами, молдом, инкрементальной сборкой - вы же чего то там бурчите себе под нос и думаете что остальные должны понять, а если не поняли то дураки. > Вдвойне смешно, что ты это ляпнул после того, как сам гордо признался, что никогда не работал программистом. Так вы плохо читаете. Я астронафт, телепат, астралнафт, нудист, анонист, диктатор, самый добрый во вселенной человек, великий изобретатель, даритель подарков, получатель подарков, автор кучи всякой фигни, радиогубитель, сантехник, электрик, вело-самокато-механик, чинилыч-доламыватель электроники, маляр, штукатурщик-халтурщик и тп. Всего и не перечислить сейчас. Я и сейчас не пограмист, я тот кто им накидывает сверху :) За никогда - это вы сами себе придумали утешение. > У тебя воистину феноменальный талант гадить себе же в штаны. У кого что болит, как говорится :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #194 Ответы: #215

199. Сообщение от пох.. (?), 06-Окт-26, 21:22	–5 +/–
> В том-то и дело, друг, что твои "знания" из твоих же слов > видно идеально четко. Об этом-то и речь. из твоего вранья пока видно только ЧСВ овер 1000. и прожекты на мильены строк, собираются за три секунды. > Самое смешное, что тебе хватило ума ляпнуть такое человеку, который буквально все > взрослую жизнь зарабатывает себе на хлеб кодингом на C++ в частности. а по-моему ты просто врешь. Ванины-то умения в программирование - мы видели.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #194 Ответы: #214

200. Сообщение от пох.. (?), 06-Окт-26, 21:30	+/–
> как линковщик не использует LTO через шаренную либу. Если бы ваш > mold не использовал бы LTO он точно был бы бесполезным. В в тестах он его, очевидно, и не использовал. Если ты отлаживаешь проект, по сто раз пересобирая один файлик (так что тебе сильно мешает не пересборка всего гигабайта а линкер) - вряд ли ты будешь включать в нем lto. > контексте новости полученное "ускорение" является таким же бесполезным, ибо большую часть > времени занимает именно LTO!!! не для разработчика. Который на время последовательных пересборок одного и того же может (и захочет) ненужные медленные оптимизации выключить. (хотя выйдет смешно если без LTO ошибка не проявляется)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #174 Ответы: #203, #206

201. Сообщение от Аноним (14), 06-Окт-26, 21:52	–1 +/–
> "чтобы не было ошибок - просто не делайте ошибок!". они сами по себе появляются?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130

203. Сообщение от Аноним (14), 06-Окт-26, 22:04	–2 +/–
> в тестах он его, очевидно, и не использовал. ты имеешь ввиду в бенчах? на кой мне скорость копирования одного файла в другой? мне скорость LTO нужна. > Если ты отлаживаешь проект, по сто раз пересобирая один файлик (так что тебе сильно мешает не пересборка всего гигабайта а линкер) - вряд ли ты будешь включать в нем lto. А это зависит от проекта, lto как и любая другая оптимизация необходима на финальных стадиях разработки, для релизов. И lto буквально это оптимизации стадии линковки, то есть является частью линковщика. А после включения lto, у нас что разработка на этом останавливается? Проверять и тестировать (отлаживать) не надо поле этого? > не для разработчика. Именно, что для разработчика, я повторяю, после включения lto - тестировать и дебажить не надо? > Который на время последовательных пересборок одного и того же может (и захочет) ненужные медленные оптимизации выключить. Значит он выключит все оптимизации, а не только времени линковки!!! > (хотя выйдет смешно если без LTO ошибка не проявляется) Смешная у вас логика, а вы думали, что после включения lto при релизе, тестировать и дебажить не надо? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #200 Ответы: #207

204. Сообщение от Аноним (204), 06-Окт-26, 22:12	–1 +/–
fix> бесполезный Ivan_83 стал х10 бесполезнее
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

205. Сообщение от Ivan_83 (ok), 06-Окт-26, 22:27	+/–
Я там выше расписал свои аргументы почему мне mold не интересен, у вас какие то возражения по ним будут? > Вот, теперь ты наконец-то запел про "я" и "мне", хотя изначально с апломбом утверждал, что он "никому не нужен". Объясните тогда кому он такой нужен? > будучи феерически некомпетентным в проблематике сабжа, имеешь глупость распространять тут ересь о том, что сабж якобы бесполезен, никому не нужен и "не умеет в LTO". В отличии от вас я mold собирал и с его помощью даже что то линковал. систему и/или порты. И пришёл к выводу что я зря потратил время на эту поделку. Логика моих рассуждений изложена выше. У вас кроме обвинений в некомпетентности ничего нет. Даже собственного авторитета чтобы эти обвинения выдвигать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166 Ответы: #218

206. Сообщение от Ivan_83 (ok), 06-Окт-26, 22:31	+/–
> Если ты отлаживаешь проект, по сто раз пересобирая один файлик (так что тебе сильно мешает не пересборка всего гигабайта а линкер) - вряд ли ты будешь включать в нем lto. Да, но разница на хроме 16 секунд против 1,6. А на более мелких проектах 6 против 1 или около того. А если смотреть воркфлоу целиком, то обычно интересно или компиляция которая выдаёт ошибки или потом прогон тестов/запуск приложухи. В любом случае вклад линкера будет минимальным, и от его сокращения вообще ничего не изменится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #200 Ответы: #210

207. Сообщение от Ivan_83 (ok), 06-Окт-26, 22:37	+/–
> Именно, что для разработчика, я повторяю, после включения lto - тестировать и дебажить не надо? Думаю нет. Я не припоминаю ни одной проблемы в коде который собрался с LTO которой бы не было в коде собравшемся без LTO. Я и на проблемы с -O3/-O2 против -O0 наступал не часто. Особенно последние годы, когда это даже компелятор в варнингах подсказывает. Правда был какой то баг с asn.1 парсером, но там не то либа не то шланг был виноват, оно с -O1 уже не проявлялось, я зарепортил, забил -O1 опцию для порта и забыл. Баг года через 2 вроде закрыли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #203 Ответы: #209

208. Сообщение от yet another anonymous (?), 06-Окт-26, 22:41	+/–
> заметно опережающая компоновщики GNU gold и LLVM lld И то и другое --- вещи со специфическими особенностями, очень много ограничений по примененнию. Соответственно, и к subj вопросы --- какие ограничения/допущения?
Ответить | Правка | Наверх | Cообщить модератору

209. Сообщение от Аноним (14), 06-Окт-26, 23:14	+/–
> Думаю нет. Ясно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #207

210. Сообщение от пох.. (?), 06-Окт-26, 23:16	–1 +/–
> А если смотреть воркфлоу целиком, то обычно интересно или компиляция которая выдаёт > ошибки или потом прогон тестов/запуск приложухи. ну вот второго - придется подождать. правда в случае нормальных проектов а не какого-то суперчуда от местного чудесника с мильенами кода собирающегося за доли секунды - подождать придется вовсе не линкера. Его ты даже наверное и не заметишь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #206 Ответы: #211, #216

211. Сообщение от Ivan_83 (ok), 06-Окт-26, 23:36	–1 +/–
Кудесник всё никак не родит историю успеха mold - не расскажет в каком месте ему жмёт линковка. Наверное секретный какой то проект, вот всё в нём хорошо и только в линковку упирается. Так и вижу: правка кода 0,0001с (и автор на кофеиновой клизме и капельнице, может даже их местами поменяли для бутстрапона), компеляция 0,1с, линковка 10с, тесты 0,05с. И тут он такой фигак mold и весь ворклоу ускоряется в 10 раз и укладывается в 1 секунду.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #210 Ответы: #212, #217

212. Сообщение от пох.. (?), 07-Окт-26, 01:22	–2 +/–
> Наверное секретный какой то проект, конечно секретный - учоные могут не знать! (с мильенами строк собирается за семь секунд, это ли не чудо?! Только вот линкер все портит.) В принципе, у самого автора mold повидимому схожие проблемы. Хотя тоже неясно в каком проекте - вряд ли это lld. (ну или грантик для безопастных переписывателей все же где-то замаячил)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #211

213. Сообщение от Аноним (39), 07-Окт-26, 02:47	+/–
> и прям твое супержелезо упирается в немодный ld? Нет. Разве я что-то писал об этом? >> Вот именно, что очень давно. Сейчас, очевидно, будет еще дольше. Ты что сказать-то хотел? > что тебя скорее всего ждет интересный сюрприз при попытке поредактировать один файлик. Так ты договаривай-то до конца, что там за "интересный сюрприз" будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #197

214. Сообщение от Аноним (39), 07-Окт-26, 02:52	+/–
> из твоего вранья В чем конкретно я тебя обманул? > пока видно только ЧСВ овер 1000. Твоя самооценка пошатнулась от того, что кто-то работает программистом? Ну, сходи к психотерапевту, я хз... > прожекты на мильены строк, собираются за три секунды. Опять галлюцинируешь? Какая еще сборка за три секунды, лол? >> взрослую жизнь зарабатывает себе на хлеб кодингом на C++ в частности. > а по-моему ты просто врешь. Естественно вру! Ведь кодеров на C++ не существует! 😭
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #199

215. Сообщение от Аноним (39), 07-Окт-26, 03:14	+1 +/–
>> В том-то и дело, друг, что твои "знания" из твоих же слов видно идеально четко. > Видно кому? Очевидно, кому угодно, кто читает твою же писанину. >> С чего ты взял, что я пытаюсь тебе что-то "продавать". Особенно инкрементальную сборку (лол), которую буквально любой без исключения C++ кодер использует по сто раз на дню. > С того что вы постоянно про неё пишите. Где ты это постоянство увидел, лол? Я тебе советовал пойти почитать об инкрементальной сборке банально чтобы ты узнал, что это такое - и перестал тут писать ересь собачью. А не потому, что я тебе что-то пытаюсь "продать". > потому что не в состоянии объяснить нафиг она мне сдалась. А с чего ты взял, что у меня была такая цель? Я, по-моему, тебе черным по белому написал, что ТЕБЕ она НЕ нужна. Ты же продолжаешь меня спрашивать, зачем она тебе, одновременно повторяя мой же тезис о том, что ТЕБЕ она НЕ нужна. Какая-то идиотия, ей-богу... > или мне сильно дешевле на ccache положится черем с инкрементальностью возится в чужом то проекте Чел, с инкрементальность не нужно "возиться". Она просто есть из коробки. Господи ты ж боже мой... >> Самое смешное, что тебе хватило ума ляпнуть такое человеку, который буквально все взрослую жизнь зарабатывает себе на хлеб кодингом на C++ в частности. Никогда не в состоянии продать, ага. > Речь не про продажу своей тушки работодателю, а про продажу того чем вы так гордитесь, что вас там кормит и тп. Именно об этом и речь. > Я про свою билд систему на шелл скрипте довольно долго тут рассказывал [...] может заинтересовать = привлечь пользователя. > Попробуйте проделать тоже самое с крестами Ваня, ты там совсем связь с реальностью потерял и правда думаешь, что твоя шелл-портянь интересует людей больше и имеет больше пользователей, чем C++? >> Вдвойне смешно, что ты это ляпнул после того, как сам гордо признался, что никогда не работал программистом. > Так вы плохо читаете. > Я астронафт, телепат, астралнафт, нудист, анонист, диктатор, На этой ноте у Вани окончательно поехала крыша...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #198

216. Сообщение от Аноним (39), 07-Окт-26, 03:22	+/–
> правда в случае нормальных проектов а не какого-то суперчуда от местного чудесника с мильенами кода собирающегося за доли секунды За 4-5 секунд против менее одной я говорил в контексте сравнения make против ninja - это примерное время, которое им нужно для ПРЕСЧЕТА ЗАВИСИМОСТЕЙ после редактирования одного-нескольких файлов. Но пох традиционно читает задницей, и потому придумал себе, что речь шла о всей сборке. https://www.opennet.me/openforum/vsluhforumID3/141899.html#126
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #210

217. Сообщение от Аноним (39), 07-Окт-26, 03:28	+/–
> Кудесник всё никак не родит историю успеха mold - не расскажет в > каком месте ему жмёт линковка. Ваня, ты там в адеквате вообще? Я тебе еще в начале обсуждения объяснил (цитата): "Когда ты работаешь над большим проектом, где финальный бинарь размером с десяток мегабайт, компиляция отдельного CPP после правки может занимать доли секунды, а линковка бинаря при этом все равно занимает в десятки раз дольше, что невероятно бесит." https://www.opennet.me/openforum/vsluhforumID3/141899.html#33 Объясни, что конкретно тебе не понятно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #211

218. Сообщение от Аноним (39), 07-Окт-26, 03:39	+/–
> Я там выше расписал свои аргументы почему мне mold не интересен, у вас какие то возражения по ним будут? Ты описал аргумент, почему он не интересен ТЕБЕ. И нет, у меня нет по ним абсолютно никаких возражений. Я даже прямым текстом это сказал. >> Вот, теперь ты наконец-то запел про "я" и "мне", хотя изначально с апломбом утверждал, что он "никому не нужен". > Объясните тогда кому он такой нужен? Любому, кому нужна быстрая линковка вместо медленной. > я mold собирал и с его помощью даже что то линковал. систему и/или порты. > И пришёл к выводу что я зря потратил время И ЧСХ после этого ты так и не сделал вывод, что впредь нужно думать (разбираться в вопросе) - а уже потом делать. А не наоборот. > У вас кроме обвинений в некомпетентности ничего нет. А разве нужно что-то еще - после всего того забористого бреда, что ты навалил? О чем вообще с тобой можно говорить, если ты буквально в этом обсуждении впервые узнал, что оптимизацией при LTO занимается не линковщик? Ну камон...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #205 Ответы: #220

219. Сообщение от morphe (?), 07-Окт-26, 03:55	+/–
> (гениально засунуть это в тип, бгг) А где это должно находиться? Время владения это свойство ссылки, а не возвращаемого значения например И значение типа HashMap<&'symtab str, &'object [u8]> вполне имеет место быть
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #181

220. Сообщение от Аноним (14), 07-Окт-26, 04:20	+/–
> Любому, кому нужна быстрая линковка вместо медленной. твоя вся быстрота упрется тупо в IO! > что оптимизацией при LTO занимается не линковщик? Повторю тебе еще раз, LTO -  прерогатива линковщика, а то что в llvm она из него выпилена есть их архитектурное решение, и по ссылке пояснения причины такого решения. Не "компилятор" решает, а запущу ка я LTO, а линкер дергает LTO через шаренную (выпиленную) библиотеку. Не дошло это до тебя еще?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #218

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

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