The OpenNET Project / Index page

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

Библиотека Qt успешно собрана компилятором Clang

29.10.2010 20:44

Разработчики компании Nokia сообщили о достижении успешной сборки последнего снапшота фреймворка Qt компилятором Clang на платформах MacOS X и Linux. Тестирование вариантов Qt, собранных в GCC и Clang, выявило, что Linux-сборка на основе Clang функционирует на 16% медленнее и занимает на 5% больше дискового пространства, но собирается на 23% быстрее. Отмечается, что результаты оценки производительности не окончательны - после внесения определенных оптимизаций ситуация может измениться.



  1. Главная ссылка к новости (http://labs.qt.nokia.com/2010/...)
  2. OpenNews: В Clang обеспечена возможность сборки Linux-ядра 2.6.36
  3. OpenNews: В состав базовой системы FreeBSD включен компилятор Clang
  4. OpenNews: Clang достиг уровня успешной пересборки комплекта C++-библиотек Boost
  5. OpenNews: Компилятор Clang преодолел барьер собственной пересборки
Автор новости: Ariel
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/28461-Clang
Ключевые слова: Clang, qt, benchmark
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (42) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.4, Аноним (-), 21:32, 29/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Что этот компилятор на 20% быстрее работает.
     
  • 1.7, Sunder (ok), 21:39, 29/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Конкуренция - это всегда хорошо.
    два открытых компилятора лучше чем один :)
    ICC и SCC в расчёт не берём, по понятной причине.
     
  • 1.8, аноним (?), 21:51, 29/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    На время компиляции и размер глубоко положить. Когда производительность кода будет на уровне gcc, последний можно будет выкинуть для сборки всего. А пока можно выкинуть только для разработки - clang на порядок обгоняет gcc по части полезных warning'ов и читабельности текстов ошибок для C++, не говоря о остальных плюшках. Пока не хватает только coverage.
     
     
  • 2.91, PereresusNeVlezaetBuggy (ok), 22:34, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > На время компиляции и размер глубоко положить.

    Время компиляции влияет на скорость разработки (сюрприз?). Что означает влияние скорость исправления ошибок и появления нужных пользователям возможностей, а так же, в соответствующих случаях, на конечную стоимость продукта. Так что этот параметр важен.

     
     
  • 3.95, Аноним (-), 03:38, 31/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    просто бред.
    1. есть make - перекомпилировываются только измененные файл
    2. наибольшее время при разработке - на отладке. время сборки влияет, но весьма частично
    3. скорость добавления ошибок и исправления нужных возможностей зависит от архитектуры программы и качества кода
     
     
  • 4.100, PereresusNeVlezaetBuggy (ok), 05:35, 31/10/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > просто бред.
    > 1. есть make - перекомпилировываются только измененные файл

    Угу, а линковать кто будет? Программы и библиотеки редко состоят из одного объектника. А когда меняется хедер (который по определению используется многими)?.. И т.д.

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

    И при самой отладке время сборки тоже влияет, когда что-то постоянно «подкручиваешь», вычисляя точную причину сбоев.

    > 3. скорость добавления ошибок и исправления нужных возможностей зависит от архитектуры
    > программы и качества кода

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

     
     
  • 5.102, Аноним (-), 14:41, 31/10/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Угу, а линковать кто будет? Программы и библиотеки редко состоят из одного объектника. А когда меняется хедер (который по определению используется многими)?.. И т.д.

    сборщик связей ld из пакета binutils. причем тут компилятор?

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

    но зачем? есть же отладчик. работа с отладчиком занимает куда больше времени чем компиляция

    >А вот скорость сборки зависит от особенностей компилятора.

    скорость сборки никого не волнует

     

  • 1.12, Commie (?), 22:35, 29/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Отлично. Надеюсь gcc, clang и icc начнут грызться между собой за производительность, стабильность работы, грамотные варнинги и дебаг код, так же как это происходит с браузерами и коммуникаторами, и любимая компания просрет еще один рынок, как это было с её IE и WM. А уж после потери M$VS останется им только троллить. А останутся на плаву все равно останемся в выигрыше.
     
     
  • 2.27, аноним (?), 00:36, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    icc не начнет, он сразу слил потому что умеет полторы платформы и проприетарщина. На 5% более эффективной оптимизации не выехать, тем более если она только на их процах и работает.
     
     
  • 3.92, User294 (ok), 00:01, 31/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > icc не начнет, он сразу слил потому что умеет полторы платформы и
    > проприетарщина.

    Интель уже сам начал GCC подтягивать в плане оптимизации под свои процы. Как ни странно, им это оказалось надо, вероятно из-за MeeGo.

     
  • 2.29, аноним (?), 00:38, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > и любимая компания просрет еще один рынок

    Сорри, не дочитал досюда. Вы это серьёзно? Микрософтовский компилятор вообще никогда не был никому конкурентом :)) Его используют только потому что в VC он по умолчанию и gcc лень ставить.

     
     
  • 3.37, FPGA (ok), 01:37, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Его используют только потому что в VC он по умолчанию и gcc лень ставить.

    Есть один знакомый, утверждающий что msvc это глобально быстро и надежно или что-то в этом роде. Делал ли он сравнительный анализ? Нет.

     
     
  • 4.90, тоже Аноним (ok), 20:44, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Честно говоря, был бы рад увидеть пруфлинк о том, что gcc может конкурировать с VS-компилятором на win-платформе.
    Я до сих пор был уверен, что конкурентов у VS нет по другой причине - не доросли-с...
    Можете дать пруф? Только не на фичи и попугаи, а на сравнение оптимизации результирующего приложения - и по размеру, и по скорости. Есть у меня пара числодробилок, слегка ускорившихся после перекомпиляции в VS2010, благо STL плотно использовалась...
     
     
  • 5.93, User294 (ok), 00:04, 31/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Я до сих пор был уверен, что конкурентов у VS нет по
    > другой причине - не доросли-с...
    > Можете дать пруф?

    Могу дать достаточно своеобразный пруф: поищите в реальных приложениях на реальном компьютере характерные строки. Если на комп поставили дополнительных программ, есть отнюдь не нулевой шанс что встретятся строки тиапичные для Mingw (GCC) например. По-моему, в VLC видел. И кстати VLC не является тормозным плеером. Правда, кроме GCC там еще асмовые вставки, но никто не виноват что вылизанный асм в критичных кусках в любом случае лучше "бреда" нагенеряченного в критичном куске компилером.

     
     
  • 6.97, Аноним (-), 03:43, 31/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Могу дать достаточно своеобразный пруф: поищите в реальных приложениях на реальном компьютере
    > характерные строки. Если на комп поставили дополнительных программ, есть отнюдь не
    > нулевой шанс что встретятся строки тиапичные для Mingw (GCC) например.

    это только докажет, что gcc дешевле msvc и его можно применять для разработки, а просили без попугаев.

     
  • 6.101, тоже Аноним (ok), 12:59, 31/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Не то. Не тормозной интерфейс вполне достигается любым компилятором и зависит от самого кода.
    А у меня NP-задача, решающаяся полным перебором с отходом назад, и я когда-то (еще в прошлой версии) ставил обновление экрана на 30000 циклов, чтобы промежуточное состояние было различимо глазом, а не сливалось. И тут от компилятора требуется все, что он может сделать для ускорения этих расчетов.
     

  • 1.39, мимопроходил (?), 01:40, 30/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Если будет еще один свободный компилятор, это плюс. Конечно gcc он не убьет но будет стимулировать развитие, ибо конкуренция. Использую clang как как анализатор довесок к gcc очень удобно(http://clang.llvm.org/diagnostics.html).
    Если верить тому же графику, gcc заточен под linux сильнее чем под остальные платформы.
     
     
  • 2.57, ананим (?), 03:48, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Если верить тому же графику, gcc заточен под linux сильнее чем под остальные платформы.

    какому графику? скорости комиляции? :D
    и откуда это видно? там всё (!!!) примерно одинаково. или вы дебаг от релиз не отличаете?
    офигенно авторитетный по полноте аналитических алгоритмов вывод.

     
     
  • 3.61, Аноним (-), 04:39, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > какому графику? скорости комиляции? :D
    > и откуда это видно? там всё (!!!) примерно одинаково. или вы дебаг от релиз не отличаете?
    > офигенно авторитетный по полноте аналитических алгоритмов вывод.

    Что вы подразумеваете под "аналитическими алгоритмами" и что под "полнотой вывода"?
    И понимаете ли вы вообще что-либо в предмете, кроме слова "скорость"?

     

  • 1.72, MarCo (?), 07:41, 30/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Не пойму, чего народ парится. Написано же, что всё ещё может измениться и компилиться будет дольше и код толще.
     
  • 1.73, Sylvia (ok), 07:50, 30/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Qt вообщем-то всегда собиралась различными компиляторами без особенных проблем и на всех поддерживаемых платформах, так что сборка с clang++ это скорее тест на готовность самого Clang собирать большие и серьезные проекты.
    Жаль что сборщики не пишут как оно работает, не полезли ли ошибки и глюки
     
     
  • 2.75, ImPressed (ok), 09:20, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Да товарищи Вижу тут сборище ярых фанатиков За ради бога, пользуйтесь каким... большой текст свёрнут, показать
     
  • 2.96, Vkni (?), 03:41, 31/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Qt вообщем-то всегда собиралась различными компиляторами без особенных проблем и на всех
    > поддерживаемых платформах

    Да, в Qt нет ничего действительно серьёзного, напрягающего С++ компилятор.
    Это далеко не boost, который, как утверждают, собирается clang'ом с этого февраля.

     

  • 1.78, Зенитар (?), 09:32, 30/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Почему-то для компилятора от Интел таких новостей не пишут. Неужели он ничего серьезного и сложного скомпилировать не умеет?
     
     
  • 2.89, Sylvia (ok), 19:51, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Почему-то для компилятора от Интел таких новостей не пишут. Неужели он ничего
    > серьезного и сложного скомпилировать не умеет?

    лицензия ICC сильно ограничивает его использование и распространение получаемых бинарников,
    а qt с ним давно собирается )

     
  • 2.94, User294 (ok), 00:11, 31/10/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Почему-то для компилятора от Интел таких новостей не пишут. Неужели он ничего
    > серьезного и сложного скомпилировать не умеет?

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

     
     
  • 3.103, Sylvia (ok), 17:04, 31/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >плюс их компилер генерит код который плохо работает на процах 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 результаты до патча и после патча были идентичны (работала оптимизированная ветка)

     
  • 2.106, sluge (ok), 09:34, 02/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Почему-то для компилятора от Интел таких новостей не пишут. Неужели он ничего
    > серьезного и сложного скомпилировать не умеет?

    потому что icc заточен строго под интеловские процы, а это никому нафиг ненадо

     

  • 1.80, Аноним (-), 11:21, 30/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > но собирается на 23% быстрее

    О это прям праздник для гентушников какой то ;)

     
     
  • 2.81, СуперАноним (?), 12:19, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Как пользовался GCC, так и дальше буду.
    Недостаточно быстро компилит? Так добавьте процессорных ядер наконец. Всё равно медленно? Поставьте аппаратный RAID.
     
     
  • 3.82, Аноним (-), 12:58, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Всё равно медленно? Поставьте аппаратный RAID.

    Месье родом из Омска? Какая связь между скоростью сборки и RAID?

     
     
  • 4.83, Аноним (-), 13:15, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    При сборке достаточно быстрыми компиляторами, например gcc(а не g++ с moc0), все упирается в I/O.
     
     
  • 5.84, NarkTranquility (?), 13:50, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    создаем раздел tmpfs в ОЗУ и собираем в нем
     
     
  • 6.85, Аноним (-), 14:44, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > создаем раздел tmpfs в ОЗУ и собираем в нем

    А сланг это будет на 23 процента еще быстрее ;P

     
  • 6.88, alz (??), 18:42, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    openoffice так соберите
     
     
  • 7.98, Аноним (-), 03:47, 31/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > openoffice так соберите

    а у меня опенофис собирается за два дня.
    // гентушник на целероне 2.5ГГц

     
  • 2.86, Zenitur (?), 14:57, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Гентушники если хотят быстро кмпилировать, заменяют ключи сборки с -02 (-03) на -0a.
     
     
  • 3.87, Zenitur (?), 14:58, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Гентушники если хотят быстро кмпилировать, заменяют ключи сборки с -02 (-03) на
    > -0a.

    -0s

     
  • 3.99, Аноним (-), 03:48, 31/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Гентушники если хотят быстро кмпилировать, заменяют ключи сборки с -02 (-03) на
    > -0a.

    может лучше ccache?

     
     
  • 4.104, Sylvia (ok), 22:58, 31/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > может лучше ccache?

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


     
     
  • 5.105, sluge (ok), 09:33, 02/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    distcc ускоряет
     

  • 1.107, sluge (ok), 09:35, 02/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    жаль не написали с какими опциями собирали
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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