The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



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

"Открыт код C++ компилятора Zapcc"  +/
Сообщение от opennews (?), 18-Июн-18, 12:05 
Израильская компания 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.ru/opennews/art.shtml?num=48796

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


2. "Открыт код C++ компилятора Zapcc"  +7 +/
Сообщение от X4asd (ok), 18-Июн-18, 12:09 
> Высокая скорость сборки достигается применением специального фонового процесса (zapccs), который поддерживает в оперативной памяти кэш компиляции, в котором сохраняется информация о всех этапах сборки между разными запусками компилятора

взяли моду -- держать в памяти запущенным компилятор.

а без этого ни как нельзя?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Открыт код C++ компилятора Zapcc"  +49 +/
Сообщение от Anonymoustus (ok), 18-Июн-18, 12:20 
Можно — если пересадить девелоперз на пентиум-2, при котором 32 МБ ОЗУ, а вместо SSD дать HDD через ATA 33. Что-то мне подсказывает, что после таких исцеляющих перемен у многих поубавилось бы прыти проектировать «космос», а большинство вылетело бы «вон из профессии»©.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

10. "Открыт код C++ компилятора Zapcc"  –8 +/
Сообщение от Аноним (-), 18-Июн-18, 12:39 
Судишь по собственному опыту?
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

35. "Открыт код C++ компилятора Zapcc"  –1 +/
Сообщение от IRASoldier (?), 18-Июн-18, 13:39 
(#сарказм, #издевательское_сочувствие) Дауншифтинг?
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

40. "Открыт код C++ компилятора Zapcc"  –4 +/
Сообщение от Andrey Mitrofanov (?), 18-Июн-18, 13:56 
> (#сарказм, #издевательское_сочувствие)

Предже чем сам, убедись, что не стоишь под стрелой!  #винтернетениктонеможетвсарказмямогу

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

112. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от анон (?), 18-Июн-18, 22:17 
ты {-# LANGUAGE MagicHash -#} забыл
Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

150. "Открыт код C++ компилятора Zapcc"  +4 +/
Сообщение от Anonymoustus (ok), 20-Июн-18, 10:38 
Ничуть. Берём для сравнения популярную программу — допустим, Microsoft Word — 25-летней давности и самого свежего инновационного релиза. Сравниваем изменения и пополнения в списке действительно полезных функций, нужных людям в реальной жизни. Делаем фейспалм. То же можно сказать практически про любой потребительский прикладной софт, кроме сугубо мультимедийно-вычислительного (для которого каждый мегагерц и мегабайт может давать прибавку к производительности, но может и не давать). Всё, что может обеспечивать прирост чистой вычислительной мощности железа и других его «скоростных» ресурсов, утилизируется чудовищно раздутым софтом. Если не принимать во внимание развлекательную сторону, обычный человек не получает _никаких_ преимуществ, меняя «программно-аппаратный комплекс» на протяжении вот уже четверти века. Но из-за повсеместного «запланированного устаревания» людям приходится постоянно менять вещи на такие же, только новые. Идиоты называют это прогрессом. На самом деле это способ много раз продавать один и тот же товар одним и тем же людям. Если для одежды такой подход понятен и разумен, ибо она изнашивается в буквальном смысле слова, то для всевозможной бытовой и не только бытовой техники имеет место самый настоящий лохотрон. Эти черти даже свинец убрали из припоев — лишь бы электроника побыстрее ломалась, а то мы недостаточно быстро заполняем помойки и не так часто посещаем магазины. Так вот, я против этого лохотрона. Я знаю возможности специальных («профессиональных») программ 25-летней давности и нынешних — почти нигде нет реальных улучшений, только свистелки и перделки ценой отмены обратной совместимости и безумного возрастания прожорливости софта. Всё для того, чтобы вы не забывали покупать новый компьютер и программы каждые пару лет. А лучше всего посадить вас на лизинг или подписку. Неиссякаемый поток денег производителю, а лох доволен. Про добровольных защитников этой системы («инноваций и прогресса») хорошего сказать нечего и разговаривать с ними не о чем.
Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

108. "Открыт код C++ компилятора Zapcc"  –1 +/
Сообщение от Аноним (-), 18-Июн-18, 21:21 
Можно конечно, только зачем? Если такое решение помогает быстрее компилировать код, то в чем проблема? Тестировать ПО на старом железе может быть и имеет смысл, но разработка на таком - по-моему глупость
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

133. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Это я (?), 19-Июн-18, 11:06 
electron и пользовательские приложения на java - это глупость
Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

141. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Аноним (141), 19-Июн-18, 19:14 
приложений на java и нет почти
Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

144. "Открыт код C++ компилятора Zapcc"  +1 +/
Сообщение от Вареник (?), 20-Июн-18, 03:17 
>> electron и пользовательские приложения на java - это глупость

- Еще один эксперт не может отличить Java от JS?

Пользовательское UI на JS пишется. Даже в самой Jаvа (Java FX UI).

Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

12. "Открыт код C++ компилятора Zapcc"  +2 +/
Сообщение от Crazy Alex (ok), 18-Июн-18, 12:43 
А в чём проблема, собственно?
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

21. "Открыт код C++ компилятора Zapcc"  –3 +/
Сообщение от Xasd (ok), 18-Июн-18, 13:01 
в том что есть подозрение что там наделали кучу ошибок и дыр, при реализации такого подхода.

компилятор это и без того сложная программа -- а уж висеть перманентно в памяти и резделять память между различными процессами-и-пользователями (в том числе непривилигерованными) -- это просто открывает новый вектор непросветных дыр!

точно ли они там нет проблем с гонками конкурентно-работающих процессов? а если проблему с гонами какой-то из пользователей пытается вызвать сознательно -- точно ли не удасться это ему? и точно ли компилятор вообще проверяет привелегии различных пользователей компьютера?

а точно ли там в конце-концов -- нет утечек памяти?

точно ли получаемый на выходе результат -- является ровно одинаковым по сравнению с тем как если бы компилятор был был запущен в первый раз без кэша?

слишком много "если" для того чтобы предположить что они там не накосячили.

обычный компилятор запускаемый-и-завершающийся-после-своей-работы -- уж явно будет иметь поменьше потенциальных проблем.

# P.S.: а зачем вообще думать про безопасность компьютера разработчика? ответ -- наверно чтобы было поменьше вот таких инцидентов -- https://www.opennet.ru/opennews/art.shtml?num=48786

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

32. "Открыт код C++ компилятора Zapcc"  –2 +/
Сообщение от Anonymoustus (ok), 18-Июн-18, 13:29 
Вообще любые кеши — зло по определению. Ибо делают согласованность (в широком смысле слова), мягко говоря, весьма иллюзорной.
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

95. "Открыт код C++ компилятора Zapcc"  +1 +/
Сообщение от Аноним (-), 18-Июн-18, 19:11 
кто-то не смог в теорию графов
Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

120. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Аноним (120), 19-Июн-18, 06:50 
А вы не смейтесь, нам на экономическом вышку совсем по другому преподавали, так что потом приходилось самостоятельно все учить.
Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

103. "Открыт код C++ компилятора Zapcc"  –1 +/
Сообщение от Vkni (ok), 18-Июн-18, 20:32 
> Вообще любые кеши — зло по определению. Ибо делают согласованность (в широком смысле
> слова), мягко говоря, весьма иллюзорной.

Кеши вещь нормальная и хорошая. Но вот компиляторы обычно пишутся в расчете на однопоточную компиляцию ровно одного исходника. Отсюда глобальные переменные в полный рост, потери памяти и т.д.

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

146. "Открыт код C++ компилятора Zapcc"  –1 +/
Сообщение от cutlass (?), 20-Июн-18, 05:09 
там где есть конкурирующие процессы согласованность всегда иллюзорна.
Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

53. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Orduemail (ok), 18-Июн-18, 14:39 
> а если проблему с гонами какой-то из пользователей пытается вызвать сознательно -- точно ли не удасться это ему?

Прежде чем обсуждать угрозы, надо представить себе модель атаки. Вот допустим, я в своей домашней генте поставил этот самый zapcc в качестве CXX. И как должна быть организована атака? Кто-то должен выполнить произвольный код на моём компе, чтобы отправить в zapcc запущенном из под рута что-то там на компиляцию? Если на моём компе выполняется чей-то произвольный код, то ему проще не дожидаться, когда я поправлю CXX, а сделать что-нибудь интереснее, например, прописать в ~/.bashrc какой-нибудь интересный alias на su/sudo, чтобы когда мне захочется получить права рута, эти права достались бы и вредоносному коду тоже. Или если хочется извращений, то можно подменить весь сервер zapcc, а не обращаться к существующему -- всего-то надо прибить старый и запустить новый.

Или может у меня фантазии недостаточно, и есть какой-нибудь способ использовать этот zapcc без выполнения произвольного кода? А! Точно! Я придумал. Если сервер запустить на хорошем и мощном компьютере, а emerge на слабом и тупом, то zapcc позволяет избавиться от distcc. Но тут встанет вопрос как их безопасно связать, чтобы никто не вмешался... Но, всё же, я бы не стал на месте разрабов компилятора заморачиваться этой хнёй, достаточно дать возможность пользователю соорудить ssh-тоннель между сервером и клиентским компом, и пускай пользователь сам следит за правами доступа так, как он считает нужным.

> и точно ли компилятор вообще проверяет привелегии различных пользователей компьютера?

Если интересно, загляни, посмотри. Зачем гадать? Как по мне, тут не проверки нужны, а что-нибудь типа передачи сборочных команд серверу через unix-сокет с правами по умолчанию 0600: я вообще не вижу никаких юзкейсов для сборки, которая идёт из под нескольких пользователей одновременно.

> а точно ли там в конце-концов -- нет утечек памяти?

Утечки памяти -- это плохо, но если за счёт утечек памяти достигается ускорение сборки в несколько раз, то я за утечки памяти. В конце-концов, не сложно и перезапустить раз в сутки.

> а зачем вообще думать про безопасность компьютера разработчика?

Если разработчик со скуки клонирует рандомные репы и делает в них make, то ему никакой компилятор не поможет против rm -rf ~/*, затесавшимся промежь прочих команд в одном Makefile'ов.

> точно ли получаемый на выходе результат -- является ровно одинаковым по сравнению с тем как если бы компилятор был был запущен в первый раз без кэша?

Вот это интересный вопрос. В C/C++ есть куча способов получать разные результаты компиляции, выполняя include из разных контекстов, и действительно интересно, как этот компиль справляется с отслеживанием контекста.

Ещё интересно, как он будет справляться с перекомпиляцией сорцов после внесённых изменений. Насколько успешно он отслеживает зависимости или изменение одной строки в одном файле приводит к сбросу кеша в ноль и пересборке с нуля? С одной стороны -- это не его забота, этим должна заниматься система сборки, а с другой стороны не совсем не его, он мог бы делать это эффективнее, чем система сборки.

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

102. "Открыт код C++ компилятора Zapcc"  +4 +/
Сообщение от Vkni (ok), 18-Июн-18, 20:29 
> компилятор это и без того сложная программа -- а уж висеть перманентно в памяти и резделять память между различными процессами-и-пользователями (в том числе непривелигированными) -- это просто открывает новый вектор непросветных дыр!

Категорически поддерживаю. Я с одной стороны видел потроха разных компиляторов, где даже в самых разумных вариантах есть глобальные переменные. То есть, имеется довольно сложное и непрозрачное состояние, которое может приводить к ошибкам, если нет сброса между компиляциями разных файлов.

А с другой стороны, я недавно имел дело с гoвнoкомпилятором фирмы Борланд (Эмбаркадеро), который страшным образом глючил при компиляции всего проекта, но прекрасно переваривал тот же проект, компилируя файлы по-отдельности.

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

145. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Вареник (?), 20-Июн-18, 03:23 
> А с другой стороны, я недавно имел дело с гoвнoкомпилятором фирмы Борланд
> (Эмбаркадеро), который страшным образом глючил при компиляции всего проекта, но прекрасно
> переваривал тот же проект, компилируя файлы по-отдельности.

Я однажды столкнулся с их IDE/компиллятором Kylix (Borland C++ для Linux). Это было настолько глючное нечто, что путало точки с запятыми, если в переменных окружающей среды поменялась локализация (т.е. локаль не C/POSIX). Могло выдавать непонятную ошибку, но не выдавать ее после добавления в исходник нескольких пробелов в произвольном месте.

И этот "продукт" Borland продавал как продакшн релиз за тысячи долларов...

Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

158. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Vkni (ok), 22-Июн-18, 07:00 
> Я однажды столкнулся с их IDE/компиллятором Kylix (Borland C++ для Linux).

Ну это даже значительно хуже, чем обычно.

Но вот Трубо Паскакаль у них был отличным. Даже на ХТ компилировал очень быстро.

Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

136. "Открыт код C++ компилятора Zapcc"  +1 +/
Сообщение от Аноним (136), 19-Июн-18, 16:07 
Я тоже всегда говорил - нефиг писать программы. А то мало ли чего можно понаписать. Кучу ошибок наделать и дыр. Лучше вообще ничего не делать - так оно лучше будет.
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

151. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Andrey Mitrofanov (?), 20-Июн-18, 10:52 
> Я тоже всегда говорил - нефиг писать программы. А то мало ли
> чего можно понаписать. Кучу ошибок наделать и дыр. Лучше вообще ничего
> не делать - так оно лучше будет.

+много!  Надо держаться,

Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

153. "Открыт код C++ компилятора Zapcc"  +1 +/
Сообщение от Anonymoustus (ok), 20-Июн-18, 11:28 
«Денег нет, но вы держи́тесь».
Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

61. "Открыт код C++ компилятора Zapcc"  +1 +/
Сообщение от Аноним (-), 18-Июн-18, 15:06 
>а без этого ни как нельзя?

Можно, но будет медленнее.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

3. "Открыт код C++ компилятора Zapcc"  +7 +/
Сообщение от Аноним (-), 18-Июн-18, 12:11 
Скорость это хорошо, а вот правильно собирает то?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Открыт код C++ компилятора Zapcc"  +1 +/
Сообщение от Anonymoustus (ok), 18-Июн-18, 12:21 
> Скорость это хорошо, а вот правильно собирает то?

Отличный вопрос, анон! Как раз хотел написать о том же.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

67. "Открыт код C++ компилятора Zapcc"  +6 +/
Сообщение от Аноним (-), 18-Июн-18, 15:14 
Как раз хотел написать о том, что хотел задать тот же вопрос, но ты меня опередил.
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

162. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от заминированный тапок (?), 16-Сен-19, 14:52 
как раз меня опередили, как я хотел написать об опережении меня перед тем, как я хотел задать тот же вопрос

(з.ы. похожее видел в Haxe с CPP трагетом, там тоже применяется кеш компиляции cpp-кода. правда порой приходится вручную его чистить и собирать с нуля, потому как мог и "забыть" некоторые изменения в коде)

Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

9. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Аноним (-), 18-Июн-18, 12:25 
Только "собирает-то".
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

11. "Открыт код C++ компилятора Zapcc"  –6 +/
Сообщение от Аноним (-), 18-Июн-18, 12:42 
Поскольку код на С++ то нет.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

101. "Открыт код C++ компилятора Zapcc"  +2 +/
Сообщение от Аноним (-), 18-Июн-18, 19:45 
Сектанты подтянулись.
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

100. "Открыт код C++ компилятора Zapcc"  +2 +/
Сообщение от Аноним (-), 18-Июн-18, 19:44 
Он собирает кошэрно и халяльно.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

126. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Аноним (126), 19-Июн-18, 09:30 
И только не в шабат
Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

4. "Открыт код C++ компилятора Zapcc"  –3 +/
Сообщение от Andrey Mitrofanov (?), 18-Июн-18, 12:17 
> Израильская компания 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++.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Anonymoustus (ok), 18-Июн-18, 12:22 
Шекели не пахнут.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

13. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Andrey Mitrofanov (?), 18-Июн-18, 12:43 
> Шекели не пахнут.

Видимо-видимо.  С проприертарщиками жить -- регулярно проверяться не забывать в цену включать.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

19. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от IRASoldier (?), 18-Июн-18, 13:00 
>уже несут донаты маленькой израильской фирме

Правильно, не всем же быть идейно озабоченными нищебpодами.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

22. "Открыт код C++ компилятора Zapcc"  +2 +/
Сообщение от Andrey Mitrofanov (?), 18-Июн-18, 13:03 
>>уже несут донаты маленькой израильской фирме
> Правильно, не всем же быть идейно озабоченными нищебpодами.

Согласен!  Некоторым и в безыдейных -- что божья роса.

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

30. "Открыт код C++ компилятора Zapcc"  –1 +/
Сообщение от IRASoldier (?), 18-Июн-18, 13:12 
Г-н Митрофанов, вы еще скажите, что сами вот прям таки взяли и отказались бы от доната Майкрософта или Эппла. Эдак гордо - "Нет!". Просто не заносит никто, да?
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

41. "Открыт код C++ компилятора Zapcc"  +2 +/
Сообщение от Andrey Mitrofanov (?), 18-Июн-18, 13:59 
> Г-н Митрофанов, вы еще скажите, что сами вот прям таки взяли и
> отказались бы от доната Майкрософта или Эппла. Эдак гордо - "Нет!".

Конечно.  Те, кто мене "донатит" не оценили бы.

> Просто не заносит никто, да?

Ваши "никто" -- да.  Я прикладываю все усилия к тому, чтоб даже не пытались.

Что ещё не понятно?  Спрашивайте.

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

64. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от IRASoldier (?), 18-Июн-18, 15:12 
>Я прикладываю все усилия к тому, чтоб даже не пытались

"И рэкетир с утюгом - возьми сто рублей!" (с) то ли Петросян, то ли Карцев

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

45. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от PereresusNeVlezaetBuggy (ok), 18-Июн-18, 14:04 
>[оверквотинг удален]
> Ай, "малаццы".
>>Компилятор может выступать в роли прозрачной замены clang
> Какую _часть_ FreeBSD собирает?  Насколько быстлеее кланга?
> В какую часть портов смог?  Насколько быстрее??
>> и gcc, и поддерживает интеграцию с любыми системами сборки.
> В какую часть архива Debian смог?  Насколько быстрее оригинального gcc??
>>Исходные тексты открыты под лицензией LLVM.
> Славно.  Микрософт и Эппле уже несут донаты маленькой израильской фирме.
>> Си кэширование отключается, поэтому компилятор Zapcc актуален только для проектов на
>> C++.

Это, скорее, компилятор для рабочих станций, где идёт разработка. Саму кодогенерацию, как я понял, не меняли. А вот если программист вместо минуты сборки будет ждать пять секунд — зер гут.

Хотя называть это ПО в целом компилятором у меня лично язык бы не повернулся.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

79. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от КО (?), 18-Июн-18, 16:36 
>Это, скорее, компилятор для рабочих станций, где идёт разработка.

Можно и на серверах для автоматических тестов гонять.

Просто люди изобрели флажок precompiled headers (см. какой-нибудь Borland C годов так 90х прошлого тысячелетия) и засунули его в отдельный процесс (клиент-сервер все дела). Так что если раньше можно было прекомпилированные части выкладывать в файл, а тот уж хошь в tmpfs, хошь в zram. То теперь жестко в памяти процесса.

Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

82. "Открыт код C++ компилятора Zapcc"  –1 +/
Сообщение от PereresusNeVlezaetBuggy (ok), 18-Июн-18, 16:52 
>>Это, скорее, компилятор для рабочих станций, где идёт разработка.
> Можно и на серверах для автоматических тестов гонять.

А вот это не всегда хорошая идея. С тем же ccache я уже натыкался на сбои; с прекомпилированными заголовками тоже бывали проблемы — правда, последнее было давно, неправда и под виндой, когда я был куда моложе и глупее. Лучше, ИМХО, дать железке больше работы и сэкономить своё время за счёт не-разбора сбоев при сборке.

> Просто люди изобрели флажок precompiled headers (см. какой-нибудь Borland C годов так
> 90х прошлого тысячелетия) и засунули его в отдельный процесс (клиент-сервер все
> дела). Так что если раньше можно было прекомпилированные части выкладывать в
> файл, а тот уж хошь в tmpfs, хошь в zram. То
> теперь жестко в памяти процесса.

Разве всё в памяти? Я так понял, что процесс нужен только как интерфейс к БД (кешу), который может прекрасно жить на диске.

Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

99. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Orduemail (ok), 18-Июн-18, 19:38 
> прекомпилированные части выкладывать в файл

Это значит сериализовать содержимое памяти компилятора, а потом десериализовывать его на каждый запуск компилятора, коих могут быть сотни и тысячи на проект. Куча сложностей с (де)сериализацией и дополнительные тормоза. Зачем всё это?

Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

104. "Открыт код C++ компилятора Zapcc"  –2 +/
Сообщение от Vkni (ok), 18-Июн-18, 20:35 
> Это значит сериализовать содержимое памяти компилятора, а потом десериализовывать его
> на каждый запуск компилятора, коих могут быть сотни и тысячи на
> проект. Куча сложностей с (де)сериализацией и дополнительные тормоза. Зачем всё это?

mmap + подходящая структура данных (базирующаяся на POD) спасет отца русской демократии. Если файл находится в /dev/shm, то без обращения эти данные даже через шину памяти не проходят.

Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

110. "Открыт код C++ компилятора Zapcc"  +1 +/
Сообщение от Orduemail (ok), 18-Июн-18, 21:52 
> mmap + подходящая структура данных (базирующаяся на POD) спасет отца русской демократии.
> Если файл находится в /dev/shm, то без обращения эти данные даже
> через шину памяти не проходят.

Вопрос "зачем эти сложности" не снимается упоминанием mmap и POD.

Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

160. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Vkni (ok), 22-Июн-18, 07:08 
> Вопрос "зачем эти сложности" не снимается упоминанием mmap и POD.

Ну скорость компиляторов ЦэПэПэ в разы увеличивается. Разумеется, необходимость этих извращений можно устранить просто введя в язык модули - см. Borland Pascal, Ocaml, Haskell и т.д., практически всё, кроме C и C++.

Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

157. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от nuclightemail (??), 21-Июн-18, 21:04 
Кто такое POD? На ум только перловые доки приходят.
Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

159. "Открыт код C++ компилятора Zapcc"  –1 +/
Сообщение от Vkni (ok), 22-Июн-18, 07:06 
> Кто такое POD? На ум только перловые доки приходят.

Plain Old Data - терминология С++ников.

Примерно год назад я читал статью про работу с памятью в языках программирования - грубо говоря, структуры в памяти можно разделить на несколько архетипов:

1. Атомарные и массивы - это уровень Fortran 66.
2. Графы из указателей - это LISP.
3. POD - это пришло из Кобола, сейчас в основном известно по C - структуры, занимающие сплошные блоки памяти.
4. Каналы, они же pipes.

Ну и всё остальное - это сочетания этих подходов.

Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

123. "Открыт код C++ компилятора Zapcc"  –1 +/
Сообщение от КО (?), 19-Июн-18, 08:49 
Об том и новизна решения.
Только вот, как только встанет вопрос как демону компилятору сообщить, мол то, что компилировал Вася нельзя сообщать Пете, или уж тем более заменять тем, который подсунул Петя. Или о том что и после перезагрузки и на другом узле кластера тоже можно не компилять stdio.h по тыще раз на дню если он уже дней сто как не меняется. Тут сериализация может быть и полезна. Даже если совершенно не будет покидать память.
Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

134. "Открыт код C++ компилятора Zapcc"  +2 +/
Сообщение от Orduemail (ok), 19-Июн-18, 11:38 
> Об том и новизна решения.
> Только вот, как только встанет вопрос как демону компилятору сообщить, мол то,
> что компилировал Вася нельзя сообщать Пете, или уж тем более заменять
> тем, который подсунул Петя.

Никак. Это не его проблемы. Обычный компилятор совершенно не парится тем, кто компилирует -- Вася или Петя, почему этот должен? Если Вася запустил себе такого демона, то как вообще Петя сможет до него достучаться?

> Или о том что и после перезагрузки
> и на другом узле кластера тоже можно не компилять stdio.h по
> тыще раз на дню если он уже дней сто как не
> меняется. Тут сериализация может быть и полезна. Даже если совершенно не
> будет покидать память.

Видимо, кластерная сборка -- это юзкейс не для этого компилятора? Для кластера надо использовать другой кеширующий компилятор.

zapcc для разработчика, который имея дома восьмиядерную тачку с 32Гб оперативки, тратит по полчаса на каждую пересборку проекта. Тебе не приходилось писать ebuild'ы? Самый убедительный тест ебилда -- это когда emerge отлично отрабатывает этот ебилд. Но если есть замечания по тому, как ебилд отработал, то мы немного исправляем и, таким образом, инвалидируем все предыдущие тесты. Было бы круто ещё раз прогнать ебилд от начала и до конца, но это же ещё полчаса сборки... Но ок, ебилд работает, а будет ли он работать если мы поменяем окружение? Заменим bash на dash, например? Если zapcc может ускорить пересборку в пять раз, значит мы сможем позволить себе в пять раз больше тестовых прогонов ebuild'а.

zapcc для разработчика, который выгребает из почты патчи, просматривает их, применяет, компилирует, подписывает и отправляет в мейнстрим. Если пересборка занимает полчаса, то производительность работы этого разработчика упрётся в скорость компиляции. Если пересборка занимает 5 минут, то компиляция перестанет быть бутылочным горлышком.

zapcc для разработчика, который своими руками что-то твикает в коде, и хочет затем убедиться, что это компилируется и работает, а для этого надо пересобрать весь проект со всеми тестами и посмотреть, что из этого выйдет. И, скорее всего, пересобрать неоднократно, потому что с первой попытки не заработает. А когда оно в конечном итоге заработает, неплохо бы сделать make clean; make, чтобы убедиться, что оно на самом деле собирается -- бывает, что make отрабатывает, а после make clean всё ломается. А иногда оно ломается в результате твиков, и make не отрабатывает, а make clean; make -- справляется.

Вот тебе три примера людей, для которых сериализация будет ненужным усложнением, привносящим дополнительные баги и ненужные тормоза.

Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

59. "Открыт код C++ компилятора Zapcc"  +3 +/
Сообщение от z (??), 18-Июн-18, 14:49 
К несчастью, то ж бывает у людей:
Как ни полезна вещь,- цены не зная ей,
Невежда про нее свой толк все к худу клонит;
А ежели невежда познатней,
Так он ее еще и гонит.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

5. "Открыт код C++ компилятора Zapcc"  –3 +/
Сообщение от yet another anonymous (?), 18-Июн-18, 12:18 
Определить "изменённость" источников (да ещё и в широком смысле --- опции компилятору тоже в деле) чтобы понять надо ли пересобирать вместе с идентификацией --- быстрее чем просто пересборка? Что-то у меня сомнения закрадываются. Т.е. в паталогическом случае можно предыдущую сборку прикопать и потом вынуть кролика из шляпы, но ...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

14. "Открыт код C++ компилятора Zapcc"  +1 +/
Сообщение от Andrey Mitrofanov (?), 18-Июн-18, 12:45 
> Определить "изменённость" источников
> --- быстрее чем просто пересборка? Что-то у меня сомнения закрадываются. Т.е.

Там наврху написано.  Не веришь -- пачиму спрашиваешь??

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

38. "Открыт код C++ компилятора Zapcc"  –2 +/
Сообщение от yet another anonymous (?), 18-Июн-18, 13:50 
Я не оракул, чтобы догадываться что такое они имеют ввиду под словами "кэш компиляции".

По моим соображениям, корректное решение этой задачи несколько более сложно, чем просто собрать.

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

43. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Анонимус2 (?), 18-Июн-18, 14:03 
Да нет, это вполне себе тривиальная задача, обычно с ней хорошо справляется система сборки, вот определить что два вызова компилятора с разным набором параметров приведут к одному результату - сложная, видимо тут попытались решить именно вторую.
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

55. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от yet another anonymous (?), 18-Июн-18, 14:42 
> Да нет, это вполне себе тривиальная задача, обычно с ней хорошо справляется система сборки,

Хм, действительно, можно же продублироватьь работу make ;) И если для make есть представления о допущениях (чем пренебрегаем), то здесь придётся об этом догадываться.

> вот определить что два вызова компилятора с разным набором параметров приведут к одному результату - сложная, видимо тут попытались решить именно вторую.

Определить эквивалентность набора параметров для компиляции + определить эквивалентность источников (?!).

Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

62. "Открыт код C++ компилятора Zapcc"  –2 +/
Сообщение от Аноняша (?), 18-Июн-18, 15:07 
Давно уже умеет через ninja-build и make -GNinja
Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

72. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от yet another anonymous (?), 18-Июн-18, 15:36 
Вас кто-то обманул. В дизайне ninja для этого ничего нет.
Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

15. "Открыт код C++ компилятора Zapcc"  –1 +/
Сообщение от Аноним (-), 18-Июн-18, 12:45 
Кстати precompiled headers поддерживал borland c++ 3.0 в 1991 году
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

17. "Открыт код C++ компилятора Zapcc"  +1 +/
Сообщение от Andrey Mitrofanov (?), 18-Июн-18, 12:55 
> Кстати precompiled headers поддерживал

и "GCC (3.4 and newer)"

>borland c++ 3.0 в 1991 году

в 2004-ом.   И чито??

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

23. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Аноним (-), 18-Июн-18, 13:03 
в 91, ты перепутал билдер и просто c++
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

26. "Открыт код C++ компилятора Zapcc"  +2 +/
Сообщение от Andrey Mitrofanov (?), 18-Июн-18, 13:07 
>ты перепутал

Это я так нипамяааатна написал про gcc 3.4.0.

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

16. "Открыт код C++ компилятора Zapcc"  +4 +/
Сообщение от Аноним (-), 18-Июн-18, 12:47 
С++ это как раз тот язык где через 40 лет не могут сделать удовлитворительный компилятор
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

18. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Andrey Mitrofanov (?), 18-Июн-18, 12:56 
> С++ это как раз тот язык где через 40 лет не могут
> сделать удовлитворительный компилятор

Экий вы, батенька, привереда!

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

20. "Открыт код C++ компилятора Zapcc"  +4 +/
Сообщение от Аноним (-), 18-Июн-18, 13:01 
GCC более чем удовлетворительный.
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

25. "Открыт код C++ компилятора Zapcc"  –2 +/
Сообщение от Аноним (-), 18-Июн-18, 13:06 
Моя программа с 1 классом и 10 методами компилируется около 3 секунд, это удовлетворительно?
Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

27. "Открыт код C++ компилятора Zapcc"  +1 +/
Сообщение от Andrey Mitrofanov (?), 18-Июн-18, 13:08 
> Моя программа с 1 классом и 10 методами компилируется около 3 секунд,
> это удовлетворительно?

У препода своего спроси, копиляция без ошипок -- это "на троечку" или нет.

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

29. "Открыт код C++ компилятора Zapcc"  –1 +/
Сообщение от Аноним (-), 18-Июн-18, 13:12 
Дык препод меня на С++ писать и заставил, та же программа переписанная на С компилируется мгновенно.
Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

36. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Аноним (-), 18-Июн-18, 13:42 
Заставить-то он заставил, только вот руки на место не поставил.
Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

37. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Анонимemail (37), 18-Июн-18, 13:46 
Я локализовал твою ошибку. Она по эту сторону экрана. Попробуй пропатчиться.
Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

46. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от PereresusNeVlezaetBuggy (ok), 18-Июн-18, 14:06 
> Моя программа с 1 классом и 10 методами компилируется около 3 секунд,
> это удовлетворительно?

Да.

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

119. "Открыт код C++ компилятора Zapcc"  –2 +/
Сообщение от Аноним (119), 19-Июн-18, 02:09 
> GCC более чем удовлетворительный.

Сравни скорость компиляции с турбопаскалем.

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

124. "Открыт код C++ компилятора Zapcc"  –3 +/
Сообщение от КО (?), 19-Июн-18, 08:51 
Ну Паскалю и у Борланда Си сливало. Все ж таки Паскаль был их родной, а Сишечка купленной.
Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

142. "Открыт код C++ компилятора Zapcc"  +5 +/
Сообщение от Led (ok), 20-Июн-18, 00:34 
Не поэтому.
Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

147. "Открыт код C++ компилятора Zapcc"  –1 +/
Сообщение от cutlass (?), 20-Июн-18, 05:15 
Паскаль однопроходной язык, в этом все дело, а не в куплености Си. То есть тормозная компиляция Сей это из-за дизайна самого языка.
  При этом подправить сишечку, чтобы сделать однопроходным язык не настолько сложно. При этом выразительные возможности не уменьшились бы.
Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

24. "Открыт код C++ компилятора Zapcc"  +3 +/
Сообщение от Аноним (-), 18-Июн-18, 13:05 
> С++ это как раз тот язык где через 40 лет не могут
> сделать удовлитворительный компилятор

за 40 лет несколько разных C++ вышло, вы о каком?

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

28. "Открыт код C++ компилятора Zapcc"  –1 +/
Сообщение от Andrey Mitrofanov (?), 18-Июн-18, 13:09 
>> С++ это как раз тот язык где через 40 лет не могут
>> сделать удовлитворительный компилятор
> за 40 лет несколько разных C++ вышло, вы о каком?

О. Сферический борланд в вакууме.

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

31. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Аноним (-), 18-Июн-18, 13:18 
Ни на каком из них никогда годных компиляторов и не было
Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

34. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Anonymoustus (ok), 18-Июн-18, 13:35 
> Ни на каком из них никогда годных компиляторов и не было

То ли дело всеправославнейший Watcom!

Я егойным редактором ресурсов смотрю разную малварь. :) Версия 10.6 1994-го года рождения.

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

58. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от нах (?), 18-Июн-18, 14:49 
> То ли дело всеправославнейший Watcom!

он тоже был феерический тормоз, и C-only тоже.

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

66. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Anonymoustus (ok), 18-Июн-18, 15:14 
>> То ли дело всеправославнейший 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. Наверное, тогдашние девелоперз были волшебниками и знали какую-то магию.

Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

39. "Открыт код C++ компилятора Zapcc"  +1 +/
Сообщение от Ivan_83 (ok), 18-Июн-18, 13:51 
Во 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    = 1

compiler_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 может вызывать проблемы, но я пока не сталкивался.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

47. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от PereresusNeVlezaetBuggy (ok), 18-Июн-18, 14:09 
> Во FreeBSD ccache уже интегрирован, достаточно в /etc/make.conf добавить:

Вы не поверите, использование ccache много где поддерживается.

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

48. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Аноняша (?), 18-Июн-18, 14:30 
Через костыли естесвенно
Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

51. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от PereresusNeVlezaetBuggy (ok), 18-Июн-18, 14:36 
> Через костыли естесвенно

ccache сам по себе костыль, а ваш комментарий не понятен. Решение, используемое в *BSD в виде добавления 1-2 строк в системный конфигурационный файл, вы считаете костылём? Или что?

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

52. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Аноняша (?), 18-Июн-18, 14:38 
>> Через костыли естесвенно
> ccache сам по себе костыль, а ваш комментарий не понятен. Решение, используемое
> в *BSD в виде добавления 1-2 строк в системный конфигурационный файл,
> вы считаете костылём? Или что?

Если это из портов. Пакеты из внешних источников при кросс-сборке: вот где я вижу много гемора.

Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

54. "Открыт код C++ компилятора Zapcc"  +1 +/
Сообщение от PereresusNeVlezaetBuggy (ok), 18-Июн-18, 14:41 
>>> Через костыли естесвенно
>> ccache сам по себе костыль, а ваш комментарий не понятен. Решение, используемое
>> в *BSD в виде добавления 1-2 строк в системный конфигурационный файл,
>> вы считаете костылём? Или что?
> Если это из портов. Пакеты из внешних источников при кросс-сборке: вот где
> я вижу много гемора.

Соглашусь. Собственно, отчасти поэтому в OpenBSD кросс-компиляция, хотя и поддерживается, но основной упор именно на self-hosted.

Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

56. "Открыт код C++ компилятора Zapcc"  –1 +/
Сообщение от бедный буратино (ok), 18-Июн-18, 14:43 
что написать в /etc/mk.conf?
Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

63. "Открыт код C++ компилятора Zapcc"  +1 +/
Сообщение от PereresusNeVlezaetBuggy (ok), 18-Июн-18, 15:11 
> что написать в /etc/mk.conf?

USE_CCACHE=Yes

Есть там и дополнительные переменные для настроек, см. bsd.port.mk(5).

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

60. "Открыт код C++ компилятора Zapcc"  –1 +/
Сообщение от нах (?), 18-Июн-18, 14:51 
> И после этого все порты и сама система будет собираться через ccache.

"троллейбус из буханки".jpeg

Но зачем?


Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

65. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от PereresusNeVlezaetBuggy (ok), 18-Июн-18, 15:13 
>> И после этого все порты и сама система будет собираться через ccache.
> "троллейбус из буханки".jpeg
> Но зачем?

Если вы работаете над патчем для ОС или портов, то ответ как бы очевиден — чтобы было быстрее собирать-тестировать. Ну а если нет, то эти опции вас просто не касаются, и всё.

Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

71. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Andrey Mitrofanov (?), 18-Июн-18, 15:27 
>>> И после этого все порты и сама система будет собираться через ccache.
>> "троллейбус из буханки".jpeg
>> Но зачем?

...и немножечко GPLv3-or-any-later из портов -- так "УдобнееТМ".

> Если вы работаете над патчем для ОС или портов, то ответ как
> бы очевиден — чтобы было быстрее собирать-тестировать. Ну а если нет,

Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

73. "Открыт код C++ компилятора Zapcc"  –1 +/
Сообщение от PereresusNeVlezaetBuggy (ok), 18-Июн-18, 15:46 
>>>> И после этого все порты и сама система будет собираться через ccache.
>>> "троллейбус из буханки".jpeg
>>> Но зачем?
> ...и немножечко GPLv3-or-any-later из портов -- так "УдобнееТМ".

Я могу еще более страшные вещи рассказать: многие разработчики *BSD пользуются vim и — о, ужас! — emacs.

Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

84. "Открыт код C++ компилятора Zapcc"  –1 +/
Сообщение от нах (?), 18-Июн-18, 17:00 
> Если вы работаете над патчем для ОС или портов, то ответ как

ну разьве что портов. Потому что тестируется (да и патчится,по большей части) там сама система сборки, порты бывают развесистые, тут соглашусь. (правда, USE_GCC, притащенный третьей вложенной зависимостью, обгадит всю малину)

С ос все просто - хотя это и немодно, но для просто отладки кода совершенно незачем пересобирать мир. И ядро с нуля тоже незачем пересобирать. make все еще работает и способен собрать только то, что зависит от изменившихся исходников. Поверьте человеку, который этим вынужден заниматься регулярно.

А вот перед комитом в репо (если вы один из счастливчиков-с-битом) - надо всякие кэши выкинуть, src подвинуть, и собрать таки все с нуля и заново наложив патчи - иначе может выйти как всегда.

Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

87. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от PereresusNeVlezaetBuggy (ok), 18-Июн-18, 17:52 
>> Если вы работаете над патчем для ОС или портов, то ответ как
> ну разьве что портов. Потому что тестируется (да и патчится,по большей части)
> там сама система сборки, порты бывают развесистые, тут соглашусь. (правда, USE_GCC,
> притащенный третьей вложенной зависимостью, обгадит всю малину)
> С ос все просто - хотя это и немодно, но для просто
> отладки кода совершенно незачем пересобирать мир. И ядро с нуля тоже
> незачем пересобирать.

Прежде всего, базовая система написана в основном на Си, поэтому данный компилятор для её сборки попросту бесполезен. :)

Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

94. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от пох (?), 18-Июн-18, 19:09 
ооох, ваши б слова да Б-гу в уши!

> базовая система написана в основном на Си

угадайте, ЧТО занимает сейчас 90% времени make world на даже хорошем железе?
Пра-а-а-авильно, пересборка самого llvm+clang (включая миллиард неотключаемых сборочным инструментарием ненужных вещей, от кодогенераторов для мертвых архитектур до специфических отладочных инструментов). ДА, именно потому, что, в отличие от gcc, он и его миллион библиотек написаны на c++.

другое дело, что попатчив очередные грабли в недрах arc.c, пересобирать шланг не надо, достаточно пересобрать zfs.ko и userland.

Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

96. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от PereresusNeVlezaetBuggy (ok), 18-Июн-18, 19:13 
> ооох, ваши б слова да Б-гу в уши!
>> базовая система написана в основном на Си
> угадайте, ЧТО занимает сейчас 90% времени make world на даже хорошем железе?
> Пра-а-а-авильно, пересборка самого llvm+clang (включая миллиард неотключаемых сборочным
> инструментарием ненужных вещей, от кодогенераторов для мертвых архитектур до специфических
> отладочных инструментов). ДА, именно потому, что, в отличие от gcc, он
> и его миллион библиотек написаны на c++.

Это да, Тео (да и не только он) очень долго не хотел Clang в базе опёнка в том числе поэтому.

Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

113. "Открыт код C++ компилятора Zapcc"  –1 +/
Сообщение от Ivan_83 (ok), 18-Июн-18, 22:31 
Да, llvm долго собирается.
Нет, лишнее отключается и другие архитектуры оно не трогает пока ты явным образом не делаешь кросскомпеляцию.
man src.conf
Там есть отключение кусков llvm и есть отключение кросскомпеляции, но это не под другие архитектуры, это бутстрап самого компелятора, те в начале собирается какой то огрызок нового компелятора и он собирает систему и компилятор. Если отключить бутстрап то огрызок собиратся не будет и системным компелятором попробует сразу всё собрать. Но это иногда не работает - вылетает с ошибкой.

Ты там что то не правильное делаешь.
Пересборка ядра занимает максимум минут 10, на стареньком коредуо.
Если отключить все ненужные модули, как ,например, у меня тут:
http://www.netlab.linkpc.net/download/software/os_cfg/FBSD/1...
то пересобирается раза в 2-3 быстрее и весит меньше.
Ещё у меня кастомный конфиг ядра, тоже без лишних модулей.

Ещё можно пересобирать с -DNO_CLEAN это даже на коредуо полностью мир и ядро "пересоберёт" быстро (на самом деле перекомпилят только то что поменялось, но бывают фейлы).

Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

129. "Открыт код C++ компилятора Zapcc"  +1 +/
Сообщение от . (?), 19-Июн-18, 10:01 
> Нет, лишнее отключается

нихрена там не отключается. Он вообще не умеет такую сборку - весь миллиард экзотических архитектур всегда собирается.
> man src.conf

ты сам-то его читать - пробовал?
Нет там нихрена (потому что у апстрима нет). Можно выключить ненужно-lld (сэкономит две секунды и вполне вероятно приведет к проблемам в будущем, когда все же научится линковать freebsd, и совместимость с gnu ld тут же сломают) и какие-то совсем причудливые вещи ARCMigrate, Rewriter and StaticAnalyzer (из которых понятно только последнее, и тоже даром не нужно), которые тоже экономят максимум несколько минут. Основное время идет на libclang, libllvm и еще какие-то его внутренние детали, линкующиеся к любому из его бинарников. Большая их часть - это именно генерация/оптимизация под миллиард ненужно-архитектур. Оно вот так у эпла устроено, и они не видят в этом проблемы - "а вдруг мне захочется собрать бинарник под хрень-брень-никто-никогда-не-видал-все-равно-не-заработает".

> Ты там что то не правильное делаешь.

просто некоторые понимают, что они делают - а ты нет.
Содержимое cddl/zfs - общее для userland и ядра, поэтому если в нем ковыряться - пересобирается не ядро, а и ядро, и (если умеешь) пачка бинарников. (если не умеешь - world)

> Если отключить все ненужные модули, как ,например, у меня тут:

молодец, победил zfs.
А мне вот только она в основном и нужна. Кстати, хрена с два ты угадаешь, какие модули для нее "нужные". (особенно приятно, когда из-за очередного MFV "нужных" внезапно удваивается. Нет, оторвать не получится, новое поколение девелоперов не умеет ifdef)

> Ещё у меня кастомный конфиг ядра, тоже без лишних модулей.

я надеюсь, ты в курсе про платформо-независимый конфиг, включающийся по умолчанию? ;-)
Правда, оверрайды в make.conf его перекроют, в части модулей.

Но, опять же, если ты занимаешься даже не "разработкой", а просто ловлей блох - собирать что-то нестандартное, не требующееся по ТЗ - значит, очень вероятно, произвести патч, в одном месте что-то чинящий, в десяти - ломающий.

Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

135. "Открыт код C++ компилятора Zapcc"  –1 +/
Сообщение от Ivan_83 (ok), 19-Июн-18, 13:33 
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 самый ужасный конфиг, к тому же он не на всех пллатформах есть, в тех же арм и мипс под каждый чип свой конфиг.

У меня всего пара приватных патчей ядра, они никоим образом сборку не трогают, и ничего не ломают.

Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

139. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от нах (?), 19-Июн-18, 18:02 
> WITHOUT_CLANG_BOOTSTRAP

это бесполезно и потенциально сломает билд

> WITHOUT_CLANG_FULL
>       Set to avoid building the ARCMigrate,

об этом тебе сказали

> WITHOUT_CROSS_COMPILER

это выключено по умолчанию, GCC на обычных архитектурах вообще давно не собирается... к чему была вся эта простыня?

> А -DNO_CLEAN или ccache позволят не собирать с нуля и тот единственный раз.

и что-нибудь сломать. А если ты понимаешь как работает то, что ты менял - то тебе не нужно пересобирать мир вообще.  Кроме теста перед попыткой отдать свои патчи кому-то еще, который надо проводить с полной пересборкой без всяких "оптимизаций", если интересует результат.

> А где в шланге ты нашёл архитектуры отличные от х86 во время

посмотреть что и как он в этом процессе собирает, когда один хрен заняться нечем, не?

> ZFS мне лично не нужен.
> По работе я быстро нашёл все его зависимости.

пара пересборок с парой аварийных перезагрузок, и нашел, да?

Не проще ли не маяться дурью и не экономить на спичках?
(в конце-концов, можно целенаправленно выключить часть модулей)

> GENERIC самый ужасный конфиг, к тому же он не на всех пллатформах

у него есть две особенности - он имеет свойство меняться даже в пределах releng, самому это отслеживать не слишком удобно. И есть еще дефолтные конфиги в уровне выше arch.

если система не предназначена для "поставил и забыл", это может когда-нибудь выйти боком. А если предназначена - то тем более нафиг не надо бороться за время его сборки - поставил и забыл.


Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

140. "Открыт код C++ компилятора Zapcc"  –2 +/
Сообщение от Ivan_83 (ok), 19-Июн-18, 19:09 
ccache у меня ещё ни разу ничего не ломал.
-DNO_CLEAN иногда приводит к фейлам при сборке, иногда к фейлам при работе, но это инструмент для определённых целей.

Раз не хочешь смотреть то не стоит и говорить.

Нет никаких аварийны перезагрузок.
Собрал с одним ZFS, инсталл, ребут.
kldload zfs
если фейл, смотрим чего не хватило, собираем ядро с этим модулем, инсталл, опять kldload zfs.
Всё просто.

Мне проще было один раз разобраться в том какие именно модули из всей помойки мне нужны или могут потребоваться чем каждый раз собирать эту помойку.
У меня есть и слабые тазики, уровня атома, где время сборки неприлично большое.

В GENERIC всё равно пихают всякий хлам, уже лет 9 сижу на своём конфиге и проблем не испытывал.
У меня ядро получается 7-12мб, против 40+мб генерика, те грузится оно тоже чуточку быстрее.
А поскольку там меньше хлама то оно и немного безопаснее.
Короче, меня не напрягает это суппортить, и я в курсе того что у меня в системе есть, в отличии от большинства пользователей генерика.

Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

148. "Открыт код C++ компилятора Zapcc"  +1 +/
Сообщение от Аноним (148), 20-Июн-18, 08:18 
для тазиков с неприлично большим временем сборки - имеет смысл держать отдельный сборочный тазик.
Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

156. "Открыт код C++ компилятора Zapcc"  +1 +/
Сообщение от Ivan_83 (ok), 20-Июн-18, 18:49 
Да, было бы здорово.
Но нет времени/желания пока это автоматизировать: тазиков не много и обновляются они сравнительно редко.
Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

80. "Открыт код C++ компилятора Zapcc"  –1 +/
Сообщение от Ivan_83 (ok), 18-Июн-18, 16:36 
Затем что от этого есть профит практически всегда на живой системе.
И много профита если ты разработчик который больше одного раза собирает одно и тоже.
Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

97. "Открыт код C++ компилятора Zapcc"  –1 +/
Сообщение от Аноним (-), 18-Июн-18, 19:33 
Его не надо никуда "интегрировать". Достаточно сделать PATH=/usr/local/libexec/ccache:$PATH и больше ничего.
Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

42. "Открыт код C++ компилятора Zapcc"  +1 +/
Сообщение от Аноним (-), 18-Июн-18, 14:00 
Компилирует быстро, но такая фигня получается!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

44. "Открыт код C++ компилятора Zapcc"  +2 +/
Сообщение от Andrey Mitrofanov (?), 18-Июн-18, 14:04 
> Компилирует быстро, но такая фигня получается!

Уже FreeBSD пересобрал?

Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

69. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Anonymoustus (ok), 18-Июн-18, 15:22 
>> Компилирует быстро, но такая фигня получается!
> Уже FreeBSD пересобрал?

Небось уже и упало, попутно разобрав рейд-массив и сломав все USB-порты.

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

107. "Открыт код C++ компилятора Zapcc"  –3 +/
Сообщение от Аноним (-), 18-Июн-18, 20:42 
>> Компилирует быстро, но такая фигня получается!
>
> Уже FreeBSD пересобрал?

Собирал FreeBSD, а в итоге ALT получился.

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

122. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от DmA (??), 19-Июн-18, 08:20 
>>> Компилирует быстро, но такая фигня получается!
>>
>> Уже FreeBSD пересобрал?
> Собирал FreeBSD, а в итоге ALT получился.

Чтобы после компиляции АLT получить, нужно сначала деньюжку им заплатить :)

Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

128. "Открыт код C++ компилятора Zapcc"  –2 +/
Сообщение от Andrey Mitrofanov (?), 19-Июн-18, 09:55 
>>> Компилирует быстро, но такая фигня получается!
>> Уже FreeBSD пересобрал?
> Собирал FreeBSD, а в итоге ALT получился.

А не-фихня по вашему -- это MS-Windows-10-Enterprise-Server?

Не удалось, пичалька.

#<<<АLT получить, нужно сначала деньюжку им заплатить :)

Патить лучше микрософту.  Они ж Друзья опенсорсика.  </>

Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

121. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от DmA (??), 19-Июн-18, 08:19 
может в самом коде проблема ? :)
Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

49. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Аноняша (?), 18-Июн-18, 14:31 
Что линкует тоже быстрее, чем LLVM/llc ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

50. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Аноняша (?), 18-Июн-18, 14:32 
https://lld.llvm.org
Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

81. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Аноним (-), 18-Июн-18, 16:50 
>и поддерживающего в оперативной памяти кэш компиляции

128 GiB хватит для всех?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

91. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Andrey Mitrofanov (?), 18-Июн-18, 18:15 
>>и поддерживающего в оперативной памяти кэш компиляции
> 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...

--
--https://lwn.net/Articles/655437/
--

Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

149. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Аноним (148), 20-Июн-18, 08:19 
>[оверквотинг удален]
>> 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/
> --

Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

152. "А теперь о межгалактических сферо-слонах-мастодонтах в вакууме!"  +/
Сообщение от Andrey Mitrofanov (?), 20-Июн-18, 11:24 
>>[оверквотинг удален]
>>> 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/
>> --

Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

85. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Аноним (-), 18-Июн-18, 17:37 
>Исходные тексты открыты под лицензией LLVM.

License:       UoI-NCSA rc BSD public-domain llvm_targets_ARM? ( LLVM-Grant )
Под которой из них конкретно?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

92. "Открыт код C++ компилятора Zapcc"  –1 +/
Сообщение от L29Ah (ok), 18-Июн-18, 18:59 
Скоко памяти хавает на сборке буста?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

109. "Открыт код C++ компилятора Zapcc"  –2 +/
Сообщение от Аноним (-), 18-Июн-18, 21:34 
можно просто компилить в рамдиске и ненужны всякие сомнительные компиляторы
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

125. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Аноним (-), 19-Июн-18, 09:20 
Это не тоже самое. Один и тот же класс в разных проектах будет компилироваться дважды.
Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

111. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Аноним (111), 18-Июн-18, 22:01 
Сомнительно, что в upstrem их код примут, там под 200К изменений над llvm.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

117. "Открыт код C++ компилятора Zapcc"  –1 +/
Сообщение от Аноним (117), 19-Июн-18, 01:07 
Благодаря таким ребятам C++ жив и развивается!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

118. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Аноним (118), 19-Июн-18, 01:09 
Так это проприетарь, устареет через 1 минорный релиз шланга.
Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

130. "Открыт код C++ компилятора Zapcc"  +1 +/
Сообщение от Andrey Mitrofanov (?), 19-Июн-18, 10:14 
> Благодаря таким ребятам C++ жив и развивается!

Я зык меняют комитетчики, а не шлома-колеры.

Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

131. "Открыт код C++ компилятора Zapcc"  +1 +/
Сообщение от Andrey Mitrofanov (?), 19-Июн-18, 10:24 
>> Благодаря таким ребятам C++ жив

Впрочем, в части "жив", видимо, да.  "Нужно" много незамутнённых "художников".  Для хайпа...

>> и развивается!
> Я зык меняют комитетчики, а не шлома-колеры.

Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

132. "Открыт код C++ компилятора Zapcc"  –1 +/
Сообщение от Аноним (132), 19-Июн-18, 10:46 
Любой, кто работал с транслятором бинарных продуктов знает, что по крайней мере 1/10 бинарного выхода это повторяющиеся комбинации символов, я называю их "рамки". Они повторяются десятки, сотни, тысячи раз при выполнении тривиальных трансляций, а уже для средних проэктов речь идет о миллионах повторов. В среднем, я подсчитал в свое время, эти повторяющиеся сегменты занимают 1/5 бинарного продукта. Их передача по внутренним каналам транслятора это результат лености программиста. Да, в результате ошибок, некоторые неуклюжие попытки избавиться это этой "шелухи" закончились появлением серьёзных ошибок, которые поправляют возвращением бездумного повторения идентичных паттерн. В принципе, убрав "рамки", можно добиться улучшения скорости транслятора до 2-х раз. Для рекурсивно нагруженных проэктов, и Boost исключительно нагружен рекурсией, выигрыш растет по экспоненте. Так что все логично. Молодцы.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

154. "Открыт код C++ компилятора Zapcc"  +/
Сообщение от Andrey Mitrofanov (?), 20-Июн-18, 12:21 
>по крайней мере
> 1/10 бинарного выхода это повторяющиеся комбинации символов,
> нагружен рекурсией, выигрыш растет по экспоненте. Так что все логично. Молодцы.

Вы , как Большой Учёный, наверное, слышали про такой мощный, я бы даже сказал, "неповторимый" язык, как ассемблер.  Попробуйте!  Проьлему "повторов" решит на корню.  >/<

Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру