Опубликован выпуск компоновщика Mold 2.0, который может применяться в качестве более быстрой прозрачной замены GNU linker на Linux-системах. Проект развивает автор компоновщика LLVM lld. Ключевой особенностью Mold является очень высокая скорость связывания объектных файлов, заметно опережающая компоновщики GNU gold и LLVM lld (компоновка в Mold выполняется со скоростью, всего в два раза медленнее простого копирования файлов утилитой cp). Код написан на языке С++ (C++20) и распространяется под лицензией MIT...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=59510
>По мнению разработчиков переход на лицензию MIT позволит повысить привлекательность проекта в корпоративной средеДа кто бы сомневался.
Как лицензия может сделать код лучше?
тут про привлекательность, про лучше не было
Легко. Код под несовместимой лицензией эквивалентен отсутствию кода. А код который есть лучше кода которого нет.
ну так разработчики хотят кушать (и это чесно и справедливо для высококлассных образованных спецов)
а не бродить с протянутой рукой по заветам киберкомуняк или сидеть на з/п от тех же корпорастов (при этом рассказывая про швободку)
Хех, если бы оставили двойное лицензирование (AGPL и комм.), вот тогда - да, могли бы кушать и сытно. А с пермессивом на их желание кушать коммерсы болт класть будут.
У него именно так и было - AGPL + proprietary
И сменил на MIT + proprietary.
На самом деле у автора и так есть закрытая версия линкера Mold со своими плюшками типа макос и тд
Sold: The commercial version of the mold linker
https://github.com/bluewhalesystems/sold
И никакой гыпыэль ему не мешал это сделать.Просто другие разрабы не хотели коммититься в gpl-огороженный Mold.
А смена лицензии на автора и sold не повлияет, но можешь привлечь других разрабов.
Так что все правильно сделал.
Огороженным может быть только проприетарная лицензия, а никак не копилефт. У вас неправильные воззрения.
> переход с использования копилефт лицензии AGPLv3 на разрешительную лицензию MITСнимаю шляпу, мое увожение. Вирусная лицензия -- это путь вникуда.
Два Розенталя вне очереди.
Два Борменталя
Скажи это копирастам.
> мое увожениеВот увАжил, так увАжил! Может, имелось ввиду "унавоживание"? Или вожжами автора, вожжами?
Загугли эту фразу. Гугл даже не предложит исправление, так что в кавычки ее брать не обязательно. Далее пройди по первым трем ссылкам. Далее подойди к зеркалу. Оттуда на тебя своими потускневшими глазами будет смотреть дряхлый ворчливый старик.
какой же кайф будет когда мерикосы дистанционно вырубят вам наконец базовые станции, просто посмотреть на ваши зомби глаза, впервые осматривающие окружающий реальный мир.
Американцы дистанционно отключат китайские базовые станции? Не смеши мои тапочки, а то они умрут со смеху и WWF тебя засудит и посадит.Скорее твои базовые станции и коммутационные узлы лягут, когда дядюшке Ляо надоест этот цирк.
> переход с AGPLv3 на MITвот она, эволюция здорового проекта!
Интересные результаты они заявляют:
Program (linker output size) GNU gold LLVM lld mold
Chrome 96 (1.89 GiB) 53.86s 11.74s 2.21s
Clang 13 (3.18 GiB) 64.12s 5.82s 2.90s
Firefox 89 libxul (1.64 GiB) 32.95s 6.80s 1.42sЗолотистая гнутелла на два порядка медленнее этого Mold, и существенно медленнее обычного lld.
Неужели она такая тормознутая?
Когда собирал хромиум, линковка занимала пару минут, сжирала почти всю раму и нагружала проц. Спасибо гну за это. У меня даже такая примета появилась: если в процессе выполнения повседневных задач вдруг все стало резко тормозить, значит хромиум почти собрался, и работает линкер.
А зачем ты хромиум собирал gcc? Есть же шланг, который его идеально собирает.
дурак был, думал гну эта крута
Только на той неделе мне пришлось установить шланг, захардкоженный на лдд, потому что шланг теперь вендор-лок и нормальный системный линкер ему больше не годится. Твоё "идеально" это с багами и костылями при сборке, не переносимо, с более низкой производительностью результирующих файлов.
> шланг теперь вендор-локбрехня
> нормальный системный линкер ему больше не годится
э, а кто сказал что системный линкер - нормальный?
> не переносимо
это GNU Extensions, которые (были) прибыты костылями к одному единственному компилятору
> с более низкой производительностью результирующих файлов.
Напомню что речь про хромиум.
У них в доке прямо написано про шланг - "This is the only supported compiler for building Chromium."
Так что давай пруфы что Chromium Clang менее производительный чем Chromium GCC
Это правда, например, тот же swiftshader задействует определённые костыли, имеющиеся только у шланга. Ну и, по тому, что chromium, spidermonkey и firefox регулярно ломали компиляцию гцц, а куча ебилдов уже тянет по ведру патчей для сборки не шлангом, можно начинать делать определённые выводы. Системный линкер прекрасно справляется со сборкой 100% бинарей, но постоянно обламывается на коде гугл-спонсоред разрабов. Тоже определённая тенденция. Хромиум вот уже официально больше никак не собрать гцц. А производительность шланга всегда была и есть ниже, поскольку единственная оптимизация, ему известная, это лапша из goto, по месту и нет. GCC+PGO лучше всем.
> Хромиум вот уже официально больше никак не собрать гццВот дока и их официальная позиция.
https://chromium.googlesource.com/chromium/src/+/main/docs/c...
Они его не собирают и не тестят, и если gcc что-то сломает или заведорлочит - это проблемы gcc, они не будут тратить на это свое время.
Но если есть желание это исправить - присылайте патчи.> прекрасно справляется со сборкой 100% бинарей
> но постоянно обламывается на коде гугл-спонсоред разрабовПротиворечие в этой фразе вижу я))) Никак не может быть 100%, если линкер постоянно обламывается.
> производительность шланга всегда была и есть ниже
Это все круто, но все-таки хочется увидеть пруфы что chromium gcc быстрее clang
> Тоже определённая тенденция.
А то что ядро было годами прибито к одному компилятору и ушли тысячи человекочасов чтобы заставить его компилиться шлангом это тоже тенденция или "это другое (с)"?
Ну смотри, объектники гцц собирались любым линкером, объектники шланга собираются только линкером шланга (и похоже весь тулчейн шланговский должен быть). Шланг проникает в проекты посредством агрессивной рекламы и промывки мозгов, после чего эти проекты перестают нормально работать с другими компиляторами. Конечно, более высокой производительностью производимого кода привлечь не получается (её нет), поэтому, в дело идут другие методы.А расширения компилятора не вчера появились и решают вполне конкретные задачи, которые не могли быть решены иначе. Поза "мы тоже хотим свои несовместимые расширения" (т.е. очередной вендор-лок), каждый раз приводит к тому, что и наблюдаем.
Окей, ты второй раз игнорируешь одну и ту же просьбу.
Я могу считать, что пруфов про медленность хромиума, собранного шлангом, я так и не дождусь?> более высокой производительностью производимого кода привлечь не получается
Да, именно так. Куча проектов переходят с GCC на шланг, потому что гцц всасывает почти во всех приложениях, кроме заточенных под gcc.
Вот сравнение Clang 16 vs. GCC 13
Новенькое, за May 2023 - https://www.phoronix.com/review/gcc13-clang16-raptorlake/5
Clang 16 was in first place 81% of the time.> Шланг проникает в проекты посредством агрессивной рекламы и промывки мозгов
Какая возмутительная ложь... Про скорость я написал выше, но не приходило в голову, что дело может быть еще в чем-то кроме нее? Напр. что они не хотя мараться об раковую лицензию? Или вообще связываться с гнутыми?
А может шланг более гибкий? Или он поддерживает другие языки используемые в проекте, которые гцц не осилил?
Это похороникс, нечего обсуждать. Ты сам, если квалификация позволяет, можешь всё замерить и убедиться лично, а также, можешь посмотреть, что генерируется, и почему результат быстрее или медленнее. Шланг хуже всегда и во всех применениях. Но, код, сгенерированный им, может быть быстрее (но не эффективнее), в то время как код, генерируемый гцц, более универсален и предсказуем (при других вводных данных разброс производительности будет меньше), при этом, оптимизации, раздувающие код, включены не будут, и производительность окажется меньше. До тех пор, пока не будет задейстован PGO, и тут я ни одного раза не увидел измеримого превосходства шланга, в крайнем случае, будет одно и то же.По второму пункту, я вижу, что ты не разбираешься в вопросе и просто хочешь набросить.
Ахаха, конечно нечего обсуждать))
Ну тогда приведи "правильные" тесты.> может быть быстрее (но не эффективнее),
> код, генерируемый гцц, более универсален и предсказуемО, пошли отмазки.
> По второму пункту, я вижу, что ты не разбираешься в вопросе и просто хочешь набросить.
Спасибо, ты и тут слился. Даже немного обидно, я тебе пруфы привел, а ты только комменты строчишь...
> Шланг хуже всегда и во всех применениях.
Какое прекрасное, совсем нефанатичное, утверждение! Сказал как отрезал!
И никаких доказательств не нужно!
Какие "пруфы" ты привёл по поводу того, что гцц заражает проприетарный код? Единственное "преимущество", которое я вижу, это возможность разработки проприетарных бэкендов для ллвм. Чья бы корова мычала. Просто я добрый, поэтому не макаю сразу, когда сливаются. Ты не отвечаешь по сути, и просто поочерёдно набрасываешь новых фантазий из рекламных брошюрок, вешаешь ярлыки, цепляешься к словам, пытаешься задеть и вывести на эмоции, но, при этом, ничего не можешь сказать по сути. Тебе нечего сказать.
> гцц заражает проприетарный кодНу и где я такое написал? Читать разучился?
Вот объясни как из слов "они не хотя мараться об раковую лицензию? Или вообще связываться с гнутыми?"
можно получить "гцц заражает проприетарный код"?Люди просто не хотят связываться со всем что гнутое.
Заодно можешь вспомнить, почему bsd пришлось выкинуть gcc из стандартной поставки, а заодно поставить цель вообще избавиться от gpl. https://wiki.freebsd.org/GPLinBase> возможность разработки проприетарных бэкендов для ллвм
Тоже, кстати, весомый аргумент.
> Ты не отвечаешь по сути
В твоих сообщениях нет ни одного вопроса, просто поток сознания, причем хорошо если там 10% будет по теме.
Мои же вопросы ты просто игнорируешь.Ты пишешь что шланг медленнее, но не в состоянии привести пруфы, сливаясь "а вот сам возьми и потести".
На примеры тестов ты пишешь "ваши тесты не тесты".
Ты просто балабол, может и добрый, но балабол.
Так какая кому разница в таком случае? В случае с бзднутыми, понятно, что они хотят стелиться под проприерастов, но зачем остальным выбирать менее эфективный компилятор? Ты озвучил вариант, что разработчики опасаются за проприетарность своего кода. Возможно, но есть ли для того предпосылки? И кстати, чтобы отвечать по сути и попадать в контекст, вопросы не нужны. Что касается рейтингов попугаев из интернета, то это в целом лишено смысла. Если у тебя есть задача, требующая вычислений, ты лично можешь собрать 2 билда софта и сравнить производительность, это не rocket science. Ты легко можешь доказать, что я ошибаюсь. Только смотри не выдай желаемое за действительное, а то я же проверю.
Можно конечно попытаться оправдать гнутых что проц новый, что они еще не успели, что биг-литл, что интел и еще кучу отмазок.Но вот сравнение на AMD https://www.phoronix.com/review/amd-znver4-gcc13-clang16/6
LLVM Clang 16 был быстрее в 57% тестов из 131 теста
>GNU Extensions, которые (были) прибыты костылями к одному единственному компиляторуу интеловского компилятора тоже были (не говоря про шланг), например, так что вот это очевидная ложь.
А зачем вообще chromium пересобирать?
Gold гулаговские бездельники придумали. Экспериментальный игрушечный проект и никогда ничем иным не был.
Голд никогда не был быстрым, он существовал затем что лучше оптимизировал в своё время. Но всегда был проблемным и уже много лет заброшен и бесполезен. Кстати линукс в 2019 его дропнул https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
> The motivation for writing gold was to make a linker that is faster than the GNU linker, especially for large applications coded in C++.Т.е. GNU linker еще более тормозной чем голда? Или потом они забегали и улучшили linker?
Кто знает насколько текущий GNU linker тормозной?
Да, bfd значительно доработали за 15 лет.
Пробовал я молд, фишка в том что он быстрее пока lto выключено, а с ним скороть от шланга не отличается почти. Автор сказал что лто через шланговый плагин работает и потому ускорения не будет. На этом мой интерес пропал.
Манипуляции с лицензиями - вечная история в эквиваленте с патентами.
> MIT позволит повысить привлекательность проектаПовысит привлекательность только хорошо работающий чистый код.
в два раза медленнее /usr/bin/cp -- это насколько привлекательно?
т.е ты считаешь, что у создателя проекта нет права перевести свой проект на любую лицензию которую он хочет?
и называешь это право "Манипуляции с лицензиями"?
хм... а не попух ли ты случайно?
Некоторые "создатели" просто вниманиеляди, мечтающие о работе на благо корп. Незачем тут глубоко копать.
хахаха
они просто хотят писать хороший код и при этом не побираться по донатамсейчас только корпы (и другой бизнес) могут обеспечить их достойной зарплатой
есть только пару опенсорс проектов с хорошей монетизацией (и то убогие ноют, что "они корпам продались")вот когда придумают нормальную схему монетизации попенсорса - то сразу ситуация поменяется
но такого скорее всего не будет т.к. нытики и ни#еброды хотят только потреблять нахаляву, да еще и что-то требовать от разработчиков
Корпорастам интересно может быть этот молд использовать.Но вот нахрена им делать с ним что-то ещё, особливо связанное с закрытием кода, непонятно абсолютно.
Сначала нужно хорошо работающее чистое железо.
> Опция "-undefined" теперь обрабатывается как синоним "--undefined", в не "-u ndefined". Аналогично опция "-nopie" обрабатывается как синоним "--no-pie".Будем поощрять бардак в головах и лишний код?
В лучшем случае должно выводиться сообщение чтобы пользователь понял где он не прав. В худшем исполняться по стандартам.
Опция "-undefined" теперь обрабатывается как синоним "--undefined", в не "-u ndefined"Если они заняты этим, то все остальное уже сделали. Проект можно закрывать.
> Но разработчики отказались от подобной модели, так как такой подход не оправдал себя.Зато теперь что? Бесплатно получат? Такой подход себя оправдывает?
Пора бы уже запомнить на такие лицензии как MIT, Apache выкидывают ненужные проекты.
CMake и LLVM с BSD оказались ненужными?
>с использования копилефт лицензииТак разве можно говорить в русском языке? "Копилефтной лицензии" было бы уместнее.
> Так разве можно говорить в русском языке?Можно. Язык формируется и меняется носителями. Именно так живой язык и развивается.
Откуда тогда берутся люди, которые устанавливают правила?
это не люди, это политические назначенцы типа Розенталя (у которого как известно русский язык даже не родной).
Они их не устанавливают, а обнаруживают. Гугли "дескриптивизм v. прескриптивизм".
Как выбирают тех людей чьи обнаружения считаются верными? Если две независимы команды обнаружили разное?
Выбирают куда? Твой вопрос не имеет смысла.
>Можно. Язык формируется и меняется носителями. Именно так живой язык и развивается.Перевираете сударь. Язык "формируется и меняется носителями" в течение десятилетий и столетий, со сменой поколений. В данном конкретном случае вы выгораживаете человека неумеющего элементарно составить предложение.
Можно было поставить дефис, претензий бы не было.
Есть разница между естественным развитием языка и безграмотностью отдельных его носителей.Грамотно - через дефис: "копилефт-лицензия".
Цитата из свода правил русского правописания:
Пишутся через дефис:
1. Сложные существительные, имеющие значение одного слова и состоящие из двух самостоятельно употребляющихся существительных, соединённых без помощи соединительных гласных о и е <...>
Да, с дефисом было бы уместнее. Но аноним (33) говорил про то, чтобы заменить одно слово другим, потому что иначе будут нарушаться его собственные правила русского языка.
Версия анонима (33) тоже допустима. Не допустима версия человека, который опубликовал эту новость.
Так можно брать практически ВЕСЬ опенсорсный код - написанный, дилетантами, он ужасает своими "решениями" и скоростью. Переписать всё нахер на D!
Я D симпатизирую, но как он может изменить дилетантские решения?
В D профессионалы ещё не проросли. поэтому будут все равны =)
lld наработки в себя вберёт?
Это сильно ускорит и без того медленную компиляцию проектов на C/C++?
Медленную компиляцию проектов на C++ ускорит грамотное разделение кода по единицам трансляции. Если юзать header-only библиотеки, как macaques любят, где шаблон на шаблоне сидит и constevalом погоняет, тогда, разумеется, будет медленно.
AGPL самая кабальная лицензия из когда либо созданных, впрочем как GPL особенно 3 версии
Ложь.
на моем жирном aarch64 проекте:gold:
real 0m11,171s
user 0m0,388s
sys 0m0,177smold:
real 0m11,293s
user 0m0,382s
sys 0m0,188sпоходу типок просто впаривает коммерсу на mac
походу твой жырный тро...прожект на никому не впершейся архитектуре просто никому не нужен - но ты конечно можешь пооптимизировать линкер и прислать патчи.Типок целится в замену gnu ld и lld - для тех кого достало. И это не макое6ы.