Израильская компания Ceemple Software открыла (https://github.com/yrnkrn/zapcc) исходные тексты C++ компилятора Zapcc (https://www.zapcc.com/), основанного на наработках Clang/LLVM и отличающегося очень высокой скоростью компиляции, благодаря активному применению кэширования различных этапов сборки. Компилятор может выступать в роли прозрачной замены clang и gcc, и поддерживает интеграцию с любыми системами сборки. Исходные тексты открыты под лицензией LLVM.Особенно заметное увеличение скорости сборки наблюдается для проектов на C++ с большим число заголовочных файлов с шаблонами, таких как ScyllaDB, Webkit и LLVM, для проектов на Си ускорение менее заметно. Например, при тестировании производительности типовая повторная пересборка Boost.Math при помощи Zapcc производится в 10-50 раз быстрее (https://www.zapcc.com/demo-incremental-build/) по сравнению с Clang, а время полной сборки WebKit быстрее (https://www.zapcc.com/demo-webkit) в 2-5 раз. Сборка Clang при помощи Zapcc выполняется в два раза быстрее, чем сборка Clang при помощи Clang. По умолчанию для кода на языке Си кэширование отключается, поэтому компилятор Zapcc актуален только для проектов на C++.
Высокая скорость сборки достигается применением специального фонового процесса (zapccs), который поддерживает в оперативной памяти кэш компиляции, в котором сохраняется информация о всех этапах сборки между разными запусками компилятора. Запускаемого для компиляции приложение zapcc, поддерживающее полный набор опций Clang, выступает в роли клиента к серверу zapccs. Запуск сервера осуществляется автоматически. Качество и производительность итогового генерируемого кода аналогичны Сlang.
URL: https://news.ycombinator.com/item?id=17332330
Новость: https://www.opennet.dev/opennews/art.shtml?num=48796
> Высокая скорость сборки достигается применением специального фонового процесса (zapccs), который поддерживает в оперативной памяти кэш компиляции, в котором сохраняется информация о всех этапах сборки между разными запусками компиляторавзяли моду -- держать в памяти запущенным компилятор.
а без этого ни как нельзя?
Можно — если пересадить девелоперз на пентиум-2, при котором 32 МБ ОЗУ, а вместо SSD дать HDD через ATA 33. Что-то мне подсказывает, что после таких исцеляющих перемен у многих поубавилось бы прыти проектировать «космос», а большинство вылетело бы «вон из профессии»©.
Судишь по собственному опыту?
(#сарказм, #издевательское_сочувствие) Дауншифтинг?
> (#сарказм, #издевательское_сочувствие)Предже чем сам, убедись, что не стоишь под стрелой! #винтернетениктонеможетвсарказмямогу
ты {-# LANGUAGE MagicHash -#} забыл
Ничуть. Берём для сравнения популярную программу — допустим, Microsoft Word — 25-летней давности и самого свежего инновационного релиза. Сравниваем изменения и пополнения в списке действительно полезных функций, нужных людям в реальной жизни. Делаем фейспалм. То же можно сказать практически про любой потребительский прикладной софт, кроме сугубо мультимедийно-вычислительного (для которого каждый мегагерц и мегабайт может давать прибавку к производительности, но может и не давать). Всё, что может обеспечивать прирост чистой вычислительной мощности железа и других его «скоростных» ресурсов, утилизируется чудовищно раздутым софтом. Если не принимать во внимание развлекательную сторону, обычный человек не получает _никаких_ преимуществ, меняя «программно-аппаратный комплекс» на протяжении вот уже четверти века. Но из-за повсеместного «запланированного устаревания» людям приходится постоянно менять вещи на такие же, только новые. Идиоты называют это прогрессом. На самом деле это способ много раз продавать один и тот же товар одним и тем же людям. Если для одежды такой подход понятен и разумен, ибо она изнашивается в буквальном смысле слова, то для всевозможной бытовой и не только бытовой техники имеет место самый настоящий лохотрон. Эти черти даже свинец убрали из припоев — лишь бы электроника побыстрее ломалась, а то мы недостаточно быстро заполняем помойки и не так часто посещаем магазины. Так вот, я против этого лохотрона. Я знаю возможности специальных («профессиональных») программ 25-летней давности и нынешних — почти нигде нет реальных улучшений, только свистелки и перделки ценой отмены обратной совместимости и безумного возрастания прожорливости софта. Всё для того, чтобы вы не забывали покупать новый компьютер и программы каждые пару лет. А лучше всего посадить вас на лизинг или подписку. Неиссякаемый поток денег производителю, а лох доволен. Про добровольных защитников этой системы («инноваций и прогресса») хорошего сказать нечего и разговаривать с ними не о чем.
Можно конечно, только зачем? Если такое решение помогает быстрее компилировать код, то в чем проблема? Тестировать ПО на старом железе может быть и имеет смысл, но разработка на таком - по-моему глупость
electron и пользовательские приложения на java - это глупость
приложений на java и нет почти
>> electron и пользовательские приложения на java - это глупость- Еще один эксперт не может отличить Java от JS?
Пользовательское UI на JS пишется. Даже в самой Jаvа (Java FX UI).
А в чём проблема, собственно?
в том что есть подозрение что там наделали кучу ошибок и дыр, при реализации такого подхода.компилятор это и без того сложная программа -- а уж висеть перманентно в памяти и резделять память между различными процессами-и-пользователями (в том числе непривилигерованными) -- это просто открывает новый вектор непросветных дыр!
точно ли они там нет проблем с гонками конкурентно-работающих процессов? а если проблему с гонами какой-то из пользователей пытается вызвать сознательно -- точно ли не удасться это ему? и точно ли компилятор вообще проверяет привелегии различных пользователей компьютера?
а точно ли там в конце-концов -- нет утечек памяти?
точно ли получаемый на выходе результат -- является ровно одинаковым по сравнению с тем как если бы компилятор был был запущен в первый раз без кэша?
слишком много "если" для того чтобы предположить что они там не накосячили.
обычный компилятор запускаемый-и-завершающийся-после-своей-работы -- уж явно будет иметь поменьше потенциальных проблем.
# P.S.: а зачем вообще думать про безопасность компьютера разработчика? ответ -- наверно чтобы было поменьше вот таких инцидентов -- https://www.opennet.dev/opennews/art.shtml?num=48786
Вообще любые кеши — зло по определению. Ибо делают согласованность (в широком смысле слова), мягко говоря, весьма иллюзорной.
кто-то не смог в теорию графов
А вы не смейтесь, нам на экономическом вышку совсем по другому преподавали, так что потом приходилось самостоятельно все учить.
> Вообще любые кеши — зло по определению. Ибо делают согласованность (в широком смысле
> слова), мягко говоря, весьма иллюзорной.Кеши вещь нормальная и хорошая. Но вот компиляторы обычно пишутся в расчете на однопоточную компиляцию ровно одного исходника. Отсюда глобальные переменные в полный рост, потери памяти и т.д.
там где есть конкурирующие процессы согласованность всегда иллюзорна.
> а если проблему с гонами какой-то из пользователей пытается вызвать сознательно -- точно ли не удасться это ему?Прежде чем обсуждать угрозы, надо представить себе модель атаки. Вот допустим, я в своей домашней генте поставил этот самый zapcc в качестве CXX. И как должна быть организована атака? Кто-то должен выполнить произвольный код на моём компе, чтобы отправить в zapcc запущенном из под рута что-то там на компиляцию? Если на моём компе выполняется чей-то произвольный код, то ему проще не дожидаться, когда я поправлю CXX, а сделать что-нибудь интереснее, например, прописать в ~/.bashrc какой-нибудь интересный alias на su/sudo, чтобы когда мне захочется получить права рута, эти права достались бы и вредоносному коду тоже. Или если хочется извращений, то можно подменить весь сервер zapcc, а не обращаться к существующему -- всего-то надо прибить старый и запустить новый.
Или может у меня фантазии недостаточно, и есть какой-нибудь способ использовать этот zapcc без выполнения произвольного кода? А! Точно! Я придумал. Если сервер запустить на хорошем и мощном компьютере, а emerge на слабом и тупом, то zapcc позволяет избавиться от distcc. Но тут встанет вопрос как их безопасно связать, чтобы никто не вмешался... Но, всё же, я бы не стал на месте разрабов компилятора заморачиваться этой хнёй, достаточно дать возможность пользователю соорудить ssh-тоннель между сервером и клиентским компом, и пускай пользователь сам следит за правами доступа так, как он считает нужным.
> и точно ли компилятор вообще проверяет привелегии различных пользователей компьютера?
Если интересно, загляни, посмотри. Зачем гадать? Как по мне, тут не проверки нужны, а что-нибудь типа передачи сборочных команд серверу через unix-сокет с правами по умолчанию 0600: я вообще не вижу никаких юзкейсов для сборки, которая идёт из под нескольких пользователей одновременно.
> а точно ли там в конце-концов -- нет утечек памяти?
Утечки памяти -- это плохо, но если за счёт утечек памяти достигается ускорение сборки в несколько раз, то я за утечки памяти. В конце-концов, не сложно и перезапустить раз в сутки.
> а зачем вообще думать про безопасность компьютера разработчика?
Если разработчик со скуки клонирует рандомные репы и делает в них make, то ему никакой компилятор не поможет против rm -rf ~/*, затесавшимся промежь прочих команд в одном Makefile'ов.
> точно ли получаемый на выходе результат -- является ровно одинаковым по сравнению с тем как если бы компилятор был был запущен в первый раз без кэша?
Вот это интересный вопрос. В C/C++ есть куча способов получать разные результаты компиляции, выполняя include из разных контекстов, и действительно интересно, как этот компиль справляется с отслеживанием контекста.
Ещё интересно, как он будет справляться с перекомпиляцией сорцов после внесённых изменений. Насколько успешно он отслеживает зависимости или изменение одной строки в одном файле приводит к сбросу кеша в ноль и пересборке с нуля? С одной стороны -- это не его забота, этим должна заниматься система сборки, а с другой стороны не совсем не его, он мог бы делать это эффективнее, чем система сборки.
> компилятор это и без того сложная программа -- а уж висеть перманентно в памяти и резделять память между различными процессами-и-пользователями (в том числе непривелигированными) -- это просто открывает новый вектор непросветных дыр!Категорически поддерживаю. Я с одной стороны видел потроха разных компиляторов, где даже в самых разумных вариантах есть глобальные переменные. То есть, имеется довольно сложное и непрозрачное состояние, которое может приводить к ошибкам, если нет сброса между компиляциями разных файлов.
А с другой стороны, я недавно имел дело с гoвнoкомпилятором фирмы Борланд (Эмбаркадеро), который страшным образом глючил при компиляции всего проекта, но прекрасно переваривал тот же проект, компилируя файлы по-отдельности.
> А с другой стороны, я недавно имел дело с гoвнoкомпилятором фирмы Борланд
> (Эмбаркадеро), который страшным образом глючил при компиляции всего проекта, но прекрасно
> переваривал тот же проект, компилируя файлы по-отдельности.Я однажды столкнулся с их IDE/компиллятором Kylix (Borland C++ для Linux). Это было настолько глючное нечто, что путало точки с запятыми, если в переменных окружающей среды поменялась локализация (т.е. локаль не C/POSIX). Могло выдавать непонятную ошибку, но не выдавать ее после добавления в исходник нескольких пробелов в произвольном месте.
И этот "продукт" Borland продавал как продакшн релиз за тысячи долларов...
> Я однажды столкнулся с их IDE/компиллятором Kylix (Borland C++ для Linux).Ну это даже значительно хуже, чем обычно.
Но вот Трубо Паскакаль у них был отличным. Даже на ХТ компилировал очень быстро.
Я тоже всегда говорил - нефиг писать программы. А то мало ли чего можно понаписать. Кучу ошибок наделать и дыр. Лучше вообще ничего не делать - так оно лучше будет.
> Я тоже всегда говорил - нефиг писать программы. А то мало ли
> чего можно понаписать. Кучу ошибок наделать и дыр. Лучше вообще ничего
> не делать - так оно лучше будет.+много! Надо держаться,
«Денег нет, но вы держи́тесь».
>а без этого ни как нельзя?Можно, но будет медленнее.
Скорость это хорошо, а вот правильно собирает то?
> Скорость это хорошо, а вот правильно собирает то?Отличный вопрос, анон! Как раз хотел написать о том же.
Как раз хотел написать о том, что хотел задать тот же вопрос, но ты меня опередил.
как раз меня опередили, как я хотел написать об опережении меня перед тем, как я хотел задать тот же вопрос(з.ы. похожее видел в Haxe с CPP трагетом, там тоже применяется кеш компиляции cpp-кода. правда порой приходится вручную его чистить и собирать с нуля, потому как мог и "забыть" некоторые изменения в коде)
Только "собирает-то".
Поскольку код на С++ то нет.
Сектанты подтянулись.
Он собирает кошэрно и халяльно.
И только не в шабат
> Израильская компания Ceemple Software открыла (https://github.com/yrnkrn/zapcc) исходные
> тексты C++ компилятора Zapcc (https://www.zapcc.com/), основанного на наработках Clang/LLVM
> и отличающегося очень высокой скоростью компиляции, благодаря активному применению кэширования
> различных этапов сборки.Они сделали ccache, но не под GPLv3-or-any-later от тов.Триджела?
Ай, "малаццы".
>Компилятор может выступать в роли прозрачной замены clang
Какую _часть_ FreeBSD собирает? Насколько быстлеее кланга?
В какую часть портов смог? Насколько быстрее??> и gcc, и поддерживает интеграцию с любыми системами сборки.
В какую часть архива Debian смог? Насколько быстрее оригинального gcc??
>Исходные тексты открыты под лицензией LLVM.
Славно. Микрософт и Эппле уже несут донаты маленькой израильской фирме.
> Си кэширование отключается, поэтому компилятор Zapcc актуален только для проектов на
> C++.
Шекели не пахнут.
> Шекели не пахнут.Видимо-видимо. С проприертарщиками жить -- регулярно проверяться не забывать в цену включать.
>уже несут донаты маленькой израильской фирмеПравильно, не всем же быть идейно озабоченными нищебpодами.
>>уже несут донаты маленькой израильской фирме
> Правильно, не всем же быть идейно озабоченными нищебpодами.Согласен! Некоторым и в безыдейных -- что божья роса.
Г-н Митрофанов, вы еще скажите, что сами вот прям таки взяли и отказались бы от доната Майкрософта или Эппла. Эдак гордо - "Нет!". Просто не заносит никто, да?
> Г-н Митрофанов, вы еще скажите, что сами вот прям таки взяли и
> отказались бы от доната Майкрософта или Эппла. Эдак гордо - "Нет!".Конечно. Те, кто мене "донатит" не оценили бы.
> Просто не заносит никто, да?
Ваши "никто" -- да. Я прикладываю все усилия к тому, чтоб даже не пытались.
Что ещё не понятно? Спрашивайте.
>Я прикладываю все усилия к тому, чтоб даже не пытались"И рэкетир с утюгом - возьми сто рублей!" (с) то ли Петросян, то ли Карцев
>[оверквотинг удален]
> Ай, "малаццы".
>>Компилятор может выступать в роли прозрачной замены clang
> Какую _часть_ FreeBSD собирает? Насколько быстлеее кланга?
> В какую часть портов смог? Насколько быстрее??
>> и gcc, и поддерживает интеграцию с любыми системами сборки.
> В какую часть архива Debian смог? Насколько быстрее оригинального gcc??
>>Исходные тексты открыты под лицензией LLVM.
> Славно. Микрософт и Эппле уже несут донаты маленькой израильской фирме.
>> Си кэширование отключается, поэтому компилятор Zapcc актуален только для проектов на
>> C++.Это, скорее, компилятор для рабочих станций, где идёт разработка. Саму кодогенерацию, как я понял, не меняли. А вот если программист вместо минуты сборки будет ждать пять секунд — зер гут.
Хотя называть это ПО в целом компилятором у меня лично язык бы не повернулся.
>Это, скорее, компилятор для рабочих станций, где идёт разработка.Можно и на серверах для автоматических тестов гонять.
Просто люди изобрели флажок precompiled headers (см. какой-нибудь Borland C годов так 90х прошлого тысячелетия) и засунули его в отдельный процесс (клиент-сервер все дела). Так что если раньше можно было прекомпилированные части выкладывать в файл, а тот уж хошь в tmpfs, хошь в zram. То теперь жестко в памяти процесса.
>>Это, скорее, компилятор для рабочих станций, где идёт разработка.
> Можно и на серверах для автоматических тестов гонять.А вот это не всегда хорошая идея. С тем же ccache я уже натыкался на сбои; с прекомпилированными заголовками тоже бывали проблемы — правда, последнее было давно, неправда и под виндой, когда я был куда моложе и глупее. Лучше, ИМХО, дать железке больше работы и сэкономить своё время за счёт не-разбора сбоев при сборке.
> Просто люди изобрели флажок precompiled headers (см. какой-нибудь Borland C годов так
> 90х прошлого тысячелетия) и засунули его в отдельный процесс (клиент-сервер все
> дела). Так что если раньше можно было прекомпилированные части выкладывать в
> файл, а тот уж хошь в tmpfs, хошь в zram. То
> теперь жестко в памяти процесса.Разве всё в памяти? Я так понял, что процесс нужен только как интерфейс к БД (кешу), который может прекрасно жить на диске.
> прекомпилированные части выкладывать в файлЭто значит сериализовать содержимое памяти компилятора, а потом десериализовывать его на каждый запуск компилятора, коих могут быть сотни и тысячи на проект. Куча сложностей с (де)сериализацией и дополнительные тормоза. Зачем всё это?
> Это значит сериализовать содержимое памяти компилятора, а потом десериализовывать его
> на каждый запуск компилятора, коих могут быть сотни и тысячи на
> проект. Куча сложностей с (де)сериализацией и дополнительные тормоза. Зачем всё это?mmap + подходящая структура данных (базирующаяся на POD) спасет отца русской демократии. Если файл находится в /dev/shm, то без обращения эти данные даже через шину памяти не проходят.
> mmap + подходящая структура данных (базирующаяся на POD) спасет отца русской демократии.
> Если файл находится в /dev/shm, то без обращения эти данные даже
> через шину памяти не проходят.Вопрос "зачем эти сложности" не снимается упоминанием mmap и POD.
> Вопрос "зачем эти сложности" не снимается упоминанием mmap и POD.Ну скорость компиляторов ЦэПэПэ в разы увеличивается. Разумеется, необходимость этих извращений можно устранить просто введя в язык модули - см. Borland Pascal, Ocaml, Haskell и т.д., практически всё, кроме C и C++.
Кто такое POD? На ум только перловые доки приходят.
> Кто такое POD? На ум только перловые доки приходят.Plain Old Data - терминология С++ников.
Примерно год назад я читал статью про работу с памятью в языках программирования - грубо говоря, структуры в памяти можно разделить на несколько архетипов:
1. Атомарные и массивы - это уровень Fortran 66.
2. Графы из указателей - это LISP.
3. POD - это пришло из Кобола, сейчас в основном известно по C - структуры, занимающие сплошные блоки памяти.
4. Каналы, они же pipes.Ну и всё остальное - это сочетания этих подходов.
Об том и новизна решения.
Только вот, как только встанет вопрос как демону компилятору сообщить, мол то, что компилировал Вася нельзя сообщать Пете, или уж тем более заменять тем, который подсунул Петя. Или о том что и после перезагрузки и на другом узле кластера тоже можно не компилять stdio.h по тыще раз на дню если он уже дней сто как не меняется. Тут сериализация может быть и полезна. Даже если совершенно не будет покидать память.
> Об том и новизна решения.
> Только вот, как только встанет вопрос как демону компилятору сообщить, мол то,
> что компилировал Вася нельзя сообщать Пете, или уж тем более заменять
> тем, который подсунул Петя.Никак. Это не его проблемы. Обычный компилятор совершенно не парится тем, кто компилирует -- Вася или Петя, почему этот должен? Если Вася запустил себе такого демона, то как вообще Петя сможет до него достучаться?
> Или о том что и после перезагрузки
> и на другом узле кластера тоже можно не компилять stdio.h по
> тыще раз на дню если он уже дней сто как не
> меняется. Тут сериализация может быть и полезна. Даже если совершенно не
> будет покидать память.Видимо, кластерная сборка -- это юзкейс не для этого компилятора? Для кластера надо использовать другой кеширующий компилятор.
zapcc для разработчика, который имея дома восьмиядерную тачку с 32Гб оперативки, тратит по полчаса на каждую пересборку проекта. Тебе не приходилось писать ebuild'ы? Самый убедительный тест ебилда -- это когда emerge отлично отрабатывает этот ебилд. Но если есть замечания по тому, как ебилд отработал, то мы немного исправляем и, таким образом, инвалидируем все предыдущие тесты. Было бы круто ещё раз прогнать ебилд от начала и до конца, но это же ещё полчаса сборки... Но ок, ебилд работает, а будет ли он работать если мы поменяем окружение? Заменим bash на dash, например? Если zapcc может ускорить пересборку в пять раз, значит мы сможем позволить себе в пять раз больше тестовых прогонов ebuild'а.
zapcc для разработчика, который выгребает из почты патчи, просматривает их, применяет, компилирует, подписывает и отправляет в мейнстрим. Если пересборка занимает полчаса, то производительность работы этого разработчика упрётся в скорость компиляции. Если пересборка занимает 5 минут, то компиляция перестанет быть бутылочным горлышком.
zapcc для разработчика, который своими руками что-то твикает в коде, и хочет затем убедиться, что это компилируется и работает, а для этого надо пересобрать весь проект со всеми тестами и посмотреть, что из этого выйдет. И, скорее всего, пересобрать неоднократно, потому что с первой попытки не заработает. А когда оно в конечном итоге заработает, неплохо бы сделать make clean; make, чтобы убедиться, что оно на самом деле собирается -- бывает, что make отрабатывает, а после make clean всё ломается. А иногда оно ломается в результате твиков, и make не отрабатывает, а make clean; make -- справляется.
Вот тебе три примера людей, для которых сериализация будет ненужным усложнением, привносящим дополнительные баги и ненужные тормоза.
К несчастью, то ж бывает у людей:
Как ни полезна вещь,- цены не зная ей,
Невежда про нее свой толк все к худу клонит;
А ежели невежда познатней,
Так он ее еще и гонит.
Определить "изменённость" источников (да ещё и в широком смысле --- опции компилятору тоже в деле) чтобы понять надо ли пересобирать вместе с идентификацией --- быстрее чем просто пересборка? Что-то у меня сомнения закрадываются. Т.е. в паталогическом случае можно предыдущую сборку прикопать и потом вынуть кролика из шляпы, но ...
> Определить "изменённость" источников
> --- быстрее чем просто пересборка? Что-то у меня сомнения закрадываются. Т.е.Там наврху написано. Не веришь -- пачиму спрашиваешь??
Я не оракул, чтобы догадываться что такое они имеют ввиду под словами "кэш компиляции".По моим соображениям, корректное решение этой задачи несколько более сложно, чем просто собрать.
Да нет, это вполне себе тривиальная задача, обычно с ней хорошо справляется система сборки, вот определить что два вызова компилятора с разным набором параметров приведут к одному результату - сложная, видимо тут попытались решить именно вторую.
> Да нет, это вполне себе тривиальная задача, обычно с ней хорошо справляется система сборки,Хм, действительно, можно же продублироватьь работу make ;) И если для make есть представления о допущениях (чем пренебрегаем), то здесь придётся об этом догадываться.
> вот определить что два вызова компилятора с разным набором параметров приведут к одному результату - сложная, видимо тут попытались решить именно вторую.
Определить эквивалентность набора параметров для компиляции + определить эквивалентность источников (?!).
Давно уже умеет через ninja-build и make -GNinja
Вас кто-то обманул. В дизайне ninja для этого ничего нет.
Кстати precompiled headers поддерживал borland c++ 3.0 в 1991 году
> Кстати precompiled headers поддерживали "GCC (3.4 and newer)"
>borland c++ 3.0 в 1991 году
в 2004-ом. И чито??
в 91, ты перепутал билдер и просто c++
>ты перепуталЭто я так нипамяааатна написал про gcc 3.4.0.
С++ это как раз тот язык где через 40 лет не могут сделать удовлитворительный компилятор
> С++ это как раз тот язык где через 40 лет не могут
> сделать удовлитворительный компиляторЭкий вы, батенька, привереда[I]!
GCC более чем удовлетворительный.
Моя программа с 1 классом и 10 методами компилируется около 3 секунд, это удовлетворительно?
> Моя программа с 1 классом и 10 методами компилируется около 3 секунд,
> это удовлетворительно?У препода своего спроси, копиляция без ошипок -- это "на троечку" или нет.
Дык препод меня на С++ писать и заставил, та же программа переписанная на С компилируется мгновенно.
Заставить-то он заставил, только вот руки на место не поставил.
Я локализовал твою ошибку. Она по эту сторону экрана. Попробуй пропатчиться.
> Моя программа с 1 классом и 10 методами компилируется около 3 секунд,
> это удовлетворительно?Да.
> GCC более чем удовлетворительный.Сравни скорость компиляции с турбопаскалем.
Ну Паскалю и у Борланда Си сливало. Все ж таки Паскаль был их родной, а Сишечка купленной.
Не поэтому.
Паскаль однопроходной язык, в этом все дело, а не в куплености Си. То есть тормозная компиляция Сей это из-за дизайна самого языка.
При этом подправить сишечку, чтобы сделать однопроходным язык не настолько сложно. При этом выразительные возможности не уменьшились бы.
> С++ это как раз тот язык где через 40 лет не могут
> сделать удовлитворительный компиляторза 40 лет несколько разных C++ вышло, вы о каком?
>> С++ это как раз тот язык где через 40 лет не могут
>> сделать удовлитворительный компилятор
> за 40 лет несколько разных C++ вышло, вы о каком?О. Сферический борланд в вакууме.
Ни на каком из них никогда годных компиляторов и не было
> Ни на каком из них никогда годных компиляторов и не былоТо ли дело всеправославнейший Watcom!
Я егойным редактором ресурсов смотрю разную малварь. :) Версия 10.6 1994-го года рождения.
> То ли дело всеправославнейший Watcom!он тоже был феерический тормоз, и C-only тоже.
>> То ли дело всеправославнейший Watcom!
> он тоже был феерический тормоз, и C-only тоже.Ну, не знаю… В «Getting Started» (это версия 10.6, напоминаю, 1994 г.) написано:
«Welcome to the Watcom C/C++ 10.6 development system. Version 10.6 of Watcom C/C++ is a professional, optimizing, multi-platform C and C++ compiler with a comprehensive suite of development tools for developing and debugging both 16-bit and 32-bit applications for DOS, extended DOS, Novell NLMs, 16-bit OS/2 1.x, 32-bit OS/2, Windows 3.x, Windows 95, Win32s, and Windows NT (Win32)».
А некоторые аноны считают его одним из самых быстрых, если не самым быстрым.Ну и вообще: https://en.wikipedia.org/wiki/Watcom_C/C%2B%2B
P. S.И вот что характерно, она у меня работает без малейших взбрыков спустя четверть века от создания на 64-разрядной системе с ядром NT6. Наверное, тогдашние девелоперз были волшебниками и знали какую-то магию.
Во FreeBSD ccache уже интегрирован, достаточно в /etc/make.conf добавить:
WITH_CCACHE_BUILD=yes
CCACHE_DIR=/var/cache/ccacheПри этом желательно в /var/cache/ccache добавить ccache.conf типа (дефолты мне не нравятся):
disable = false
read_only = false
recache = false
stats = false
cache_dir_levels = 4
max_files = 0
max_size = 8G
limit_multiple = 0.9
compression = true
compression_level = 1compiler_check = %compiler% -v
direct_mode = false
unify = true
run_second_cpp = true
sloppiness = file_macro,time_macros
hash_dir = false
ignore_headers_in_manifest =
keep_comments_cpp = false
extra_files_to_hash =hard_link = false
temporary_dir = /tmpИ после этого все порты и сама система будет собираться через ccache.
sloppiness может вызывать проблемы, но я пока не сталкивался.
> Во FreeBSD ccache уже интегрирован, достаточно в /etc/make.conf добавить:Вы не поверите, использование ccache много где поддерживается.
Через костыли естесвенно
> Через костыли естесвенноccache сам по себе костыль, а ваш комментарий не понятен. Решение, используемое в *BSD в виде добавления 1-2 строк в системный конфигурационный файл, вы считаете костылём? Или что?
>> Через костыли естесвенно
> ccache сам по себе костыль, а ваш комментарий не понятен. Решение, используемое
> в *BSD в виде добавления 1-2 строк в системный конфигурационный файл,
> вы считаете костылём? Или что?Если это из портов. Пакеты из внешних источников при кросс-сборке: вот где я вижу много гемора.
>>> Через костыли естесвенно
>> ccache сам по себе костыль, а ваш комментарий не понятен. Решение, используемое
>> в *BSD в виде добавления 1-2 строк в системный конфигурационный файл,
>> вы считаете костылём? Или что?
> Если это из портов. Пакеты из внешних источников при кросс-сборке: вот где
> я вижу много гемора.Соглашусь. Собственно, отчасти поэтому в OpenBSD кросс-компиляция, хотя и поддерживается, но основной упор именно на self-hosted.
что написать в /etc/mk.conf?
> что написать в /etc/mk.conf?USE_CCACHE=Yes
Есть там и дополнительные переменные для настроек, см. bsd.port.mk(5).
> И после этого все порты и сама система будет собираться через ccache."троллейбус из буханки".jpeg
Но зачем?
>> И после этого все порты и сама система будет собираться через ccache.
> "троллейбус из буханки".jpeg
> Но зачем?Если вы работаете над патчем для ОС или портов, то ответ как бы очевиден — чтобы было быстрее собирать-тестировать. Ну а если нет, то эти опции вас просто не касаются, и всё.
>>> И после этого все порты и сама система будет собираться через ccache.
>> "троллейбус из буханки".jpeg
>> Но зачем?...и немножечко GPLv3-or-any-later из портов -- так "УдобнееТМ".
> Если вы работаете над патчем для ОС или портов, то ответ как
> бы очевиден — чтобы было быстрее собирать-тестировать. Ну а если нет,
>>>> И после этого все порты и сама система будет собираться через ccache.
>>> "троллейбус из буханки".jpeg
>>> Но зачем?
> ...и немножечко GPLv3-or-any-later из портов -- так "УдобнееТМ".Я могу еще более страшные вещи рассказать: многие разработчики *BSD пользуются vim и — о, ужас! — emacs.
> Если вы работаете над патчем для ОС или портов, то ответ какну разьве что портов. Потому что тестируется (да и патчится,по большей части) там сама система сборки, порты бывают развесистые, тут соглашусь. (правда, USE_GCC, притащенный третьей вложенной зависимостью, обгадит всю малину)
С ос все просто - хотя это и немодно, но для просто отладки кода совершенно незачем пересобирать мир. И ядро с нуля тоже незачем пересобирать. make все еще работает и способен собрать только то, что зависит от изменившихся исходников. Поверьте человеку, который этим вынужден заниматься регулярно.
А вот перед комитом в репо (если вы один из счастливчиков-с-битом) - надо всякие кэши выкинуть, src подвинуть, и собрать таки все с нуля и заново наложив патчи - иначе может выйти как всегда.
>> Если вы работаете над патчем для ОС или портов, то ответ как
> ну разьве что портов. Потому что тестируется (да и патчится,по большей части)
> там сама система сборки, порты бывают развесистые, тут соглашусь. (правда, USE_GCC,
> притащенный третьей вложенной зависимостью, обгадит всю малину)
> С ос все просто - хотя это и немодно, но для просто
> отладки кода совершенно незачем пересобирать мир. И ядро с нуля тоже
> незачем пересобирать.Прежде всего, базовая система написана в основном на Си, поэтому данный компилятор для её сборки попросту бесполезен. :)
ооох, ваши б слова да Б-гу в уши!> базовая система написана в основном на Си
угадайте, ЧТО занимает сейчас 90% времени make world на даже хорошем железе?
Пра-а-а-авильно, пересборка самого llvm+clang (включая миллиард неотключаемых сборочным инструментарием ненужных вещей, от кодогенераторов для мертвых архитектур до специфических отладочных инструментов). ДА, именно потому, что, в отличие от gcc, он и его миллион библиотек написаны на c++.другое дело, что попатчив очередные грабли в недрах arc.c, пересобирать шланг не надо, достаточно пересобрать zfs.ko и userland.
> ооох, ваши б слова да Б-гу в уши!
>> базовая система написана в основном на Си
> угадайте, ЧТО занимает сейчас 90% времени make world на даже хорошем железе?
> Пра-а-а-авильно, пересборка самого llvm+clang (включая миллиард неотключаемых сборочным
> инструментарием ненужных вещей, от кодогенераторов для мертвых архитектур до специфических
> отладочных инструментов). ДА, именно потому, что, в отличие от gcc, он
> и его миллион библиотек написаны на c++.Это да, Тео (да и не только он) очень долго не хотел Clang в базе опёнка в том числе поэтому.
Да, llvm долго собирается.
Нет, лишнее отключается и другие архитектуры оно не трогает пока ты явным образом не делаешь кросскомпеляцию.
man src.conf
Там есть отключение кусков llvm и есть отключение кросскомпеляции, но это не под другие архитектуры, это бутстрап самого компелятора, те в начале собирается какой то огрызок нового компелятора и он собирает систему и компилятор. Если отключить бутстрап то огрызок собиратся не будет и системным компелятором попробует сразу всё собрать. Но это иногда не работает - вылетает с ошибкой.Ты там что то не правильное делаешь.
Пересборка ядра занимает максимум минут 10, на стареньком коредуо.
Если отключить все ненужные модули, как ,например, у меня тут:
http://www.netlab.linkpc.net/download/software/os_cfg/FBSD/1...
то пересобирается раза в 2-3 быстрее и весит меньше.
Ещё у меня кастомный конфиг ядра, тоже без лишних модулей.Ещё можно пересобирать с -DNO_CLEAN это даже на коредуо полностью мир и ядро "пересоберёт" быстро (на самом деле перекомпилят только то что поменялось, но бывают фейлы).
> Нет, лишнее отключаетсянихрена там не отключается. Он вообще не умеет такую сборку - весь миллиард экзотических архитектур всегда собирается.
> man src.confты сам-то его читать - пробовал?
Нет там нихрена (потому что у апстрима нет). Можно выключить ненужно-lld (сэкономит две секунды и вполне вероятно приведет к проблемам в будущем, когда все же научится линковать freebsd, и совместимость с gnu ld тут же сломают) и какие-то совсем причудливые вещи ARCMigrate, Rewriter and StaticAnalyzer (из которых понятно только последнее, и тоже даром не нужно), которые тоже экономят максимум несколько минут. Основное время идет на libclang, libllvm и еще какие-то его внутренние детали, линкующиеся к любому из его бинарников. Большая их часть - это именно генерация/оптимизация под миллиард ненужно-архитектур. Оно вот так у эпла устроено, и они не видят в этом проблемы - "а вдруг мне захочется собрать бинарник под хрень-брень-никто-никогда-не-видал-все-равно-не-заработает".> Ты там что то не правильное делаешь.
просто некоторые понимают, что они делают - а ты нет.
Содержимое cddl/zfs - общее для userland и ядра, поэтому если в нем ковыряться - пересобирается не ядро, а и ядро, и (если умеешь) пачка бинарников. (если не умеешь - world)> Если отключить все ненужные модули, как ,например, у меня тут:
молодец, победил zfs.
А мне вот только она в основном и нужна. Кстати, хрена с два ты угадаешь, какие модули для нее "нужные". (особенно приятно, когда из-за очередного MFV "нужных" внезапно удваивается. Нет, оторвать не получится, новое поколение девелоперов не умеет ifdef)> Ещё у меня кастомный конфиг ядра, тоже без лишних модулей.
я надеюсь, ты в курсе про платформо-независимый конфиг, включающийся по умолчанию? ;-)
Правда, оверрайды в make.conf его перекроют, в части модулей.Но, опять же, если ты занимаешься даже не "разработкой", а просто ловлей блох - собирать что-то нестандартное, не требующееся по ТЗ - значит, очень вероятно, произвести патч, в одном месте что-то чинящий, в десяти - ломающий.
WITHOUT_CLANG_BOOTSTRAP
Set to not build the Clang C/C++ compiler during the bootstrap
phase of the build. To be able to build the system, either gcc
or clang bootstrap must be enabled unless an alternate compiler
is provided via XCC.
WITHOUT_CLANG_FULL
Set to avoid building the ARCMigrate, Rewriter and StaticAnalyzer
components of the Clang C/C++ compiler.
WITHOUT_CROSS_COMPILER
Set to not build any cross compiler in the cross-tools stage of
buildworld. When compiling a different version of FreeBSD than
what is installed on the system, provide an alternate compiler
with XCC to ensure success. When compiling with an identical
version of FreeBSD to the host, this option may be safely used.
This option may also be safe when the host version of FreeBSD is
close to the sources being built, but all bets are off if there
have been any changes to the toolchain between the versions.
When set, it enforces these options:WITHOUT_BINUTILS_BOOTSTRAP
WITHOUT_CLANG_BOOTSTRAP
WITHOUT_ELFTOOLCHAIN_BOOTSTRAP
WITHOUT_GCC_BOOTSTRAPВот последний параметр позволит не собирать libclang, libllvm два раза.
А -DNO_CLEAN или ccache позволят не собирать с нуля и тот единственный раз.А где в шланге ты нашёл архитектуры отличные от х86 во время компеляции?
Я вот когда хотел с арм поиграться ставил гцц для кросскомпеляции.ZFS мне лично не нужен.
По работе я быстро нашёл все его зависимости.GENERIC самый ужасный конфиг, к тому же он не на всех пллатформах есть, в тех же арм и мипс под каждый чип свой конфиг.
У меня всего пара приватных патчей ядра, они никоим образом сборку не трогают, и ничего не ломают.
> WITHOUT_CLANG_BOOTSTRAPэто бесполезно и потенциально сломает билд
> WITHOUT_CLANG_FULL
> Set to avoid building the ARCMigrate,об этом тебе сказали
> WITHOUT_CROSS_COMPILER
это выключено по умолчанию, GCC на обычных архитектурах вообще давно не собирается... к чему была вся эта простыня?
> А -DNO_CLEAN или ccache позволят не собирать с нуля и тот единственный раз.
и что-нибудь сломать. А если ты понимаешь как работает то, что ты менял - то тебе не нужно пересобирать мир вообще. Кроме теста перед попыткой отдать свои патчи кому-то еще, который надо проводить с полной пересборкой без всяких "оптимизаций", если интересует результат.
> А где в шланге ты нашёл архитектуры отличные от х86 во время
посмотреть что и как он в этом процессе собирает, когда один хрен заняться нечем, не?
> ZFS мне лично не нужен.
> По работе я быстро нашёл все его зависимости.пара пересборок с парой аварийных перезагрузок, и нашел, да?
Не проще ли не маяться дурью и не экономить на спичках?
(в конце-концов, можно целенаправленно выключить часть модулей)> GENERIC самый ужасный конфиг, к тому же он не на всех пллатформах
у него есть две особенности - он имеет свойство меняться даже в пределах releng, самому это отслеживать не слишком удобно. И есть еще дефолтные конфиги в уровне выше arch.
если система не предназначена для "поставил и забыл", это может когда-нибудь выйти боком. А если предназначена - то тем более нафиг не надо бороться за время его сборки - поставил и забыл.
ccache у меня ещё ни разу ничего не ломал.
-DNO_CLEAN иногда приводит к фейлам при сборке, иногда к фейлам при работе, но это инструмент для определённых целей.Раз не хочешь смотреть то не стоит и говорить.
Нет никаких аварийны перезагрузок.
Собрал с одним ZFS, инсталл, ребут.
kldload zfs
если фейл, смотрим чего не хватило, собираем ядро с этим модулем, инсталл, опять kldload zfs.
Всё просто.Мне проще было один раз разобраться в том какие именно модули из всей помойки мне нужны или могут потребоваться чем каждый раз собирать эту помойку.
У меня есть и слабые тазики, уровня атома, где время сборки неприлично большое.В GENERIC всё равно пихают всякий хлам, уже лет 9 сижу на своём конфиге и проблем не испытывал.
У меня ядро получается 7-12мб, против 40+мб генерика, те грузится оно тоже чуточку быстрее.
А поскольку там меньше хлама то оно и немного безопаснее.
Короче, меня не напрягает это суппортить, и я в курсе того что у меня в системе есть, в отличии от большинства пользователей генерика.
для тазиков с неприлично большим временем сборки - имеет смысл держать отдельный сборочный тазик.
Да, было бы здорово.
Но нет времени/желания пока это автоматизировать: тазиков не много и обновляются они сравнительно редко.
Затем что от этого есть профит практически всегда на живой системе.
И много профита если ты разработчик который больше одного раза собирает одно и тоже.
Его не надо никуда "интегрировать". Достаточно сделать PATH=/usr/local/libexec/ccache:$PATH и больше ничего.
Компилирует быстро, но такая фигня получается!
> Компилирует быстро, но такая фигня получается!Уже FreeBSD пересобрал?
>> Компилирует быстро, но такая фигня получается!
> Уже FreeBSD пересобрал?Небось уже и упало, попутно разобрав рейд-массив и сломав все USB-порты.
>> Компилирует быстро, но такая фигня получается!
>
> Уже FreeBSD пересобрал?Собирал FreeBSD, а в итоге ALT получился.
>>> Компилирует быстро, но такая фигня получается!
>>
>> Уже FreeBSD пересобрал?
> Собирал FreeBSD, а в итоге ALT получился.Чтобы после компиляции АLT получить, нужно сначала деньюжку им заплатить :)
>>> Компилирует быстро, но такая фигня получается!
>> Уже FreeBSD пересобрал?
> Собирал FreeBSD, а в итоге ALT получился.А не-фихня по вашему -- это MS-Windows-10-Enterprise-Server?
Не удалось, пичалька.
#<<<АLT получить, нужно сначала деньюжку им заплатить :)
Патить лучше микрософту. Они ж Друзья опенсорсика. </>
может в самом коде проблема ? :)
Что линкует тоже быстрее, чем LLVM/llc ?
https://lld.llvm.org
>и поддерживающего в оперативной памяти кэш компиляции128 GiB хватит для всех?
>>и поддерживающего в оперативной памяти кэш компиляции
> 128 GiB хватит для всех?Зависит от аппетита отдела продаж. То есть _точно_ не хватит.
Не _всем_.
" [...] 2592 двухпроцессорных серверов на 28-ядерных процессорах ThunderX2.[...] каждый из процессоров системы имеет прямой доступ к большому пулу памяти. "
--https://www.ixbt.com/news/2018/06/18/arm-145-152.html
" У текущего прототипа 160 ТБ памяти разделены на 40 физических узлов, соединённых при помощи [...] "
--https://www.ixbt.com/news/2017/05/18/hewlett-packard-enterpr...
>[оверквотинг удален]
>> 128 GiB хватит для всех?
> Зависит от аппетита отдела продаж. То есть _точно_ не хватит.
> Не _всем_.
> " [...] 2592 двухпроцессорных серверов на 28-ядерных процессорах ThunderX2.
> [...] каждый из процессоров системы имеет прямой доступ к большому пулу памяти.
> "
> --https://www.ixbt.com/news/2018/06/18/arm-145-152.html
> " У текущего прототипа 160 ТБ памяти разделены на 40 физических
> узлов, соединённых при помощи [...] "
> --https://www.ixbt.com/news/2017/05/18/hewlett-packard-enterpr...и что? ты про SGI Altrix слышал? канделяберный ты наш..
> --
> --https://lwn.net/Articles/655437/
> --
>>[оверквотинг удален]
>>> 128 GiB хватит для всех?
> и что? ты про SGI Altrix слышал? канделяберный ты наш..Ну, " up to 128 TB of memory (192TB with single microprocessor socket blades ' услышал, "up to 2048 dual-core Itanium 2 and Itanium ("Montvale" revision) microprocessor sockets" допустим. Мммм... нуу-у-.... ээээ.... Ну, допустим "до" то ли 384ПБ, то ли 192ПБ, то ли 256ПБ. ///Чёт NASA себе такой не купила.
Давай теперь, вдвоём!!, поговорим с типо-сарказмием предыдущего Анонима из #81:
160Тб на 40 узлах по 2 сокета в _прототипе_ даёт _минимум_ до {$ну-к, посчитай сам!} ТБ ^W ПБ? ЭБ???... на "2592 двухпроцессорных серверах" !??И нет, это [типо] не "кластер" ("was a 10240-microprocessor cluster of twenty Altix 3000 systems, each with 512 microprocessors, interconnected with InfiniBand." / "scale to over 51,200 cores" [c "up to 512 proc. up to 2ТB" => up to 40TB|up to 200TB?]).
Впрочем, разница (см.слово "интерконнект" наверху) мала, согласен!
>> --
>> --https://lwn.net/Articles/655437/
>> --
>Исходные тексты открыты под лицензией LLVM.License: UoI-NCSA rc BSD public-domain llvm_targets_ARM? ( LLVM-Grant )
Под которой из них конкретно?
Скоко памяти хавает на сборке буста?
можно просто компилить в рамдиске и ненужны всякие сомнительные компиляторы
Это не тоже самое. Один и тот же класс в разных проектах будет компилироваться дважды.
Сомнительно, что в upstrem их код примут, там под 200К изменений над llvm.
Благодаря таким ребятам C++ жив и развивается!
Так это проприетарь, устареет через 1 минорный релиз шланга.
> Благодаря таким ребятам C++ жив и развивается!Я зык меняют комитетчики, а не шлома-колеры.
>> Благодаря таким ребятам C++ живВпрочем, в части "жив", видимо, да. "Нужно" много незамутнённых "художников". Для хайпа...
>> и развивается!
> Я зык меняют комитетчики, а не шлома-колеры.
Любой, кто работал с транслятором бинарных продуктов знает, что по крайней мере 1/10 бинарного выхода это повторяющиеся комбинации символов, я называю их "рамки". Они повторяются десятки, сотни, тысячи раз при выполнении тривиальных трансляций, а уже для средних проэктов речь идет о миллионах повторов. В среднем, я подсчитал в свое время, эти повторяющиеся сегменты занимают 1/5 бинарного продукта. Их передача по внутренним каналам транслятора это результат лености программиста. Да, в результате ошибок, некоторые неуклюжие попытки избавиться это этой "шелухи" закончились появлением серьёзных ошибок, которые поправляют возвращением бездумного повторения идентичных паттерн. В принципе, убрав "рамки", можно добиться улучшения скорости транслятора до 2-х раз. Для рекурсивно нагруженных проэктов, и Boost исключительно нагружен рекурсией, выигрыш растет по экспоненте. Так что все логично. Молодцы.
>по крайней мере
> 1/10 бинарного выхода это повторяющиеся комбинации символов,
> нагружен рекурсией, выигрыш растет по экспоненте. Так что все логично. Молодцы.Вы , как Большой Учёный, наверное, слышали про такой мощный, я бы даже сказал, "неповторимый" язык, как ассемблер. Попробуйте! Проьлему "повторов" решит на корню. >/<