Разработчики компании Nokia сообщили (http://labs.qt.nokia.com/2010/10/29/compiling-qt-with-clang/) о достижении успешной сборки последнего снапшота фреймворка Qt компилятором Clang на платформах MacOS X и Linux. Тестирование вариантов Qt, собранных в GCC и Clang, выявило, что Linux-сборка на основе Clang функционирует на 16% медленнее, но собирается на 23% быстрее и занимает на 5% меньше дискового пространства. Отмечается, что результаты оценки производительности не окончательны - после внесения определенных оптимизаций ситуация может измениться.
<center><a href="http://labs.qt.nokia.com/wp-content/uploads/2010/10/clang-vs... src="http://www.opennet.me/opennews/pics_base/28461_1288372597.jp... style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></a></center>URL: http://labs.qt.nokia.com/2010/10/29/compiling-qt-with-clang/
Новость: http://www.opennet.me/opennews/art.shtml?num=28461
Что этот компилятор на 20% быстрее работает.
Конкуренция - это всегда хорошо.
два открытых компилятора лучше чем один :)
ICC и SCC в расчёт не берём, по понятной причине.
На время компиляции и размер глубоко положить. Когда производительность кода будет на уровне gcc, последний можно будет выкинуть для сборки всего. А пока можно выкинуть только для разработки - clang на порядок обгоняет gcc по части полезных warning'ов и читабельности текстов ошибок для C++, не говоря о остальных плюшках. Пока не хватает только coverage.
> На время компиляции и размер глубоко положить.Время компиляции влияет на скорость разработки (сюрприз?). Что означает влияние скорость исправления ошибок и появления нужных пользователям возможностей, а так же, в соответствующих случаях, на конечную стоимость продукта. Так что этот параметр важен.
просто бред.
1. есть make - перекомпилировываются только измененные файл
2. наибольшее время при разработке - на отладке. время сборки влияет, но весьма частично
3. скорость добавления ошибок и исправления нужных возможностей зависит от архитектуры программы и качества кода
> просто бред.
> 1. есть make - перекомпилировываются только измененные файлУгу, а линковать кто будет? Программы и библиотеки редко состоят из одного объектника. А когда меняется хедер (который по определению используется многими)?.. И т.д.
> 2. наибольшее время при разработке - на отладке. время сборки влияет, но
> весьма частичноИ при самой отладке время сборки тоже влияет, когда что-то постоянно «подкручиваешь», вычисляя точную причину сбоев.
> 3. скорость добавления ошибок и исправления нужных возможностей зависит от архитектуры
> программы и качества кодаЭто в первую очередь, согласен. Но это хотя бы контролируемые факторы. А вот скорость сборки зависит от особенностей компилятора.
>Угу, а линковать кто будет? Программы и библиотеки редко состоят из одного объектника. А когда меняется хедер (который по определению используется многими)?.. И т.д.сборщик связей ld из пакета binutils. причем тут компилятор?
>И при самой отладке время сборки тоже влияет, когда что-то постоянно «подкручиваешь», вычисляя точную причину сбоев.
но зачем? есть же отладчик. работа с отладчиком занимает куда больше времени чем компиляция
>А вот скорость сборки зависит от особенностей компилятора.
скорость сборки никого не волнует
Отлично. Надеюсь gcc, clang и icc начнут грызться между собой за производительность, стабильность работы, грамотные варнинги и дебаг код, так же как это происходит с браузерами и коммуникаторами, и любимая компания просрет еще один рынок, как это было с её IE и WM. А уж после потери M$VS останется им только троллить. А останутся на плаву все равно останемся в выигрыше.
icc не начнет, он сразу слил потому что умеет полторы платформы и проприетарщина. На 5% более эффективной оптимизации не выехать, тем более если она только на их процах и работает.
> icc не начнет, он сразу слил потому что умеет полторы платформы и
> проприетарщина.Интель уже сам начал GCC подтягивать в плане оптимизации под свои процы. Как ни странно, им это оказалось надо, вероятно из-за MeeGo.
> и любимая компания просрет еще один рынокСорри, не дочитал досюда. Вы это серьёзно? Микрософтовский компилятор вообще никогда не был никому конкурентом :)) Его используют только потому что в VC он по умолчанию и gcc лень ставить.
> Его используют только потому что в VC он по умолчанию и gcc лень ставить.Есть один знакомый, утверждающий что msvc это глобально быстро и надежно или что-то в этом роде. Делал ли он сравнительный анализ? Нет.
Честно говоря, был бы рад увидеть пруфлинк о том, что gcc может конкурировать с VS-компилятором на win-платформе.
Я до сих пор был уверен, что конкурентов у VS нет по другой причине - не доросли-с...
Можете дать пруф? Только не на фичи и попугаи, а на сравнение оптимизации результирующего приложения - и по размеру, и по скорости. Есть у меня пара числодробилок, слегка ускорившихся после перекомпиляции в VS2010, благо STL плотно использовалась...
> Я до сих пор был уверен, что конкурентов у VS нет по
> другой причине - не доросли-с...
> Можете дать пруф?Могу дать достаточно своеобразный пруф: поищите в реальных приложениях на реальном компьютере характерные строки. Если на комп поставили дополнительных программ, есть отнюдь не нулевой шанс что встретятся строки тиапичные для Mingw (GCC) например. По-моему, в VLC видел. И кстати VLC не является тормозным плеером. Правда, кроме GCC там еще асмовые вставки, но никто не виноват что вылизанный асм в критичных кусках в любом случае лучше "бреда" нагенеряченного в критичном куске компилером.
> Могу дать достаточно своеобразный пруф: поищите в реальных приложениях на реальном компьютере
> характерные строки. Если на комп поставили дополнительных программ, есть отнюдь не
> нулевой шанс что встретятся строки тиапичные для Mingw (GCC) например.это только докажет, что gcc дешевле msvc и его можно применять для разработки, а просили без попугаев.
Не то. Не тормозной интерфейс вполне достигается любым компилятором и зависит от самого кода.
А у меня NP-задача, решающаяся полным перебором с отходом назад, и я когда-то (еще в прошлой версии) ставил обновление экрана на 30000 циклов, чтобы промежуточное состояние было различимо глазом, а не сливалось. И тут от компилятора требуется все, что он может сделать для ускорения этих расчетов.
Если будет еще один свободный компилятор, это плюс. Конечно gcc он не убьет но будет стимулировать развитие, ибо конкуренция. Использую clang как как анализатор довесок к gcc очень удобно(http://clang.llvm.org/diagnostics.html).
Если верить тому же графику, gcc заточен под linux сильнее чем под остальные платформы.
>Если верить тому же графику, gcc заточен под linux сильнее чем под остальные платформы.какому графику? скорости комиляции? :D
и откуда это видно? там всё (!!!) примерно одинаково. или вы дебаг от релиз не отличаете?
офигенно авторитетный по полноте аналитических алгоритмов вывод.
> какому графику? скорости комиляции? :D
> и откуда это видно? там всё (!!!) примерно одинаково. или вы дебаг от релиз не отличаете?
> офигенно авторитетный по полноте аналитических алгоритмов вывод.Что вы подразумеваете под "аналитическими алгоритмами" и что под "полнотой вывода"?
И понимаете ли вы вообще что-либо в предмете, кроме слова "скорость"?
Не пойму, чего народ парится. Написано же, что всё ещё может измениться и компилиться будет дольше и код толще.
Qt вообщем-то всегда собиралась различными компиляторами без особенных проблем и на всех поддерживаемых платформах, так что сборка с clang++ это скорее тест на готовность самого Clang собирать большие и серьезные проекты.
Жаль что сборщики не пишут как оно работает, не полезли ли ошибки и глюки
Да товарищи.... Вижу тут сборище ярых фанатиков.
За ради бога, пользуйтесь какими угодно компиляторами, компилятор - это лишь инструмент в руках программиста. Нравится GCC - пользуйте GCC, нравится Шланг и ллвм пользуйтесь ими.
За чем разводить срач XXX - рулит, YYY - педалит, а ZZZ - надо вообще закопать?
--Хотя новость в принципе не про это, а про то что CLang научился QT собирать. Научился - и слава богу, может-быть кому-то это будет полезным. Для себя я пока нужды не вижу чтобы с GCC переходить на другие компиляторы, даже не смотря на то, в некоторых случаях GCC генерит код просто отвратительно (хотя может-быть дело не в GCC а в кривизне моих рук?).
Что тут ломать копья? Наоборот, это же хорошо - есть альтернативы, хуже бы было если бы их совсем не было этих альтернатив. Вот тут и прослеживается OSS в действии - людям был нужен компилятор, они его написали и открыли для других, и не надо тут воевать.
> Qt вообщем-то всегда собиралась различными компиляторами без особенных проблем и на всех
> поддерживаемых платформахДа, в Qt нет ничего действительно серьёзного, напрягающего С++ компилятор.
Это далеко не boost, который, как утверждают, собирается clang'ом с этого февраля.
Почему-то для компилятора от Интел таких новостей не пишут. Неужели он ничего серьезного и сложного скомпилировать не умеет?
> Почему-то для компилятора от Интел таких новостей не пишут. Неужели он ничего
> серьезного и сложного скомпилировать не умеет?лицензия ICC сильно ограничивает его использование и распространение получаемых бинарников,
а qt с ним давно собирается )
> Почему-то для компилятора от Интел таких новостей не пишут. Неужели он ничего
> серьезного и сложного скомпилировать не умеет?Да просто это коммерческий проект, плюс их компилер генерит код который плохо работает на процах AMD. Ну вот никто с ним особо и не связывается.
>плюс их компилер генерит код который плохо работает на процах AMD.вы неправы, точнее информация насчет работы кода на AMD уже устарела , версия 11.1 генерирует код, который независимо от вендора работает и на процессорах Intel и на процессорах AMD согласно возможностям процессора
в качестве proof могу предложить вот такой тест
собирается код c ICC , -mia32 (Generic) и -axT (-mtune=core2)
замеряется производительность, далее патчем patch-AuthenticAMD меняется vendor id в бинарнике, так что Core2 становится для этого кода "чужим"
с ICC 10.1 я наблюдала достаточно существенную просадку производительности (работала ветка -mia32) , с 11.1 результаты до патча и после патча были идентичны (работала оптимизированная ветка)
> Почему-то для компилятора от Интел таких новостей не пишут. Неужели он ничего
> серьезного и сложного скомпилировать не умеет?потому что icc заточен строго под интеловские процы, а это никому нафиг ненадо
> но собирается на 23% быстрееО это прям праздник для гентушников какой то ;)
Как пользовался GCC, так и дальше буду.
Недостаточно быстро компилит? Так добавьте процессорных ядер наконец. Всё равно медленно? Поставьте аппаратный RAID.
>Всё равно медленно? Поставьте аппаратный RAID.Месье родом из Омска? Какая связь между скоростью сборки и RAID?
При сборке достаточно быстрыми компиляторами, например gcc(а не g++ с moc0), все упирается в I/O.
создаем раздел tmpfs в ОЗУ и собираем в нем
> создаем раздел tmpfs в ОЗУ и собираем в немА сланг это будет на 23 процента еще быстрее ;P
openoffice так соберите
> openoffice так соберитеа у меня опенофис собирается за два дня.
// гентушник на целероне 2.5ГГц
Гентушники если хотят быстро кмпилировать, заменяют ключи сборки с -02 (-03) на -0a.
> Гентушники если хотят быстро кмпилировать, заменяют ключи сборки с -02 (-03) на
> -0a.-0s
> Гентушники если хотят быстро кмпилировать, заменяют ключи сборки с -02 (-03) на
> -0a.может лучше ccache?
> может лучше ccache?ccache не ускоряет скорость сборки, даже чуть замедляет, ускоряется скорость пересборки,
это как веб-прокси, если страница не кеширована , то она будет скачана полностью, если кеширована , то возьмется из кеша
distcc ускоряет
жаль не написали с какими опциями собирали
