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.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.
| |
|
|
6.85, Аноним (-), 14:44, 30/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
> создаем раздел tmpfs в ОЗУ и собираем в нем
А сланг это будет на 23 процента еще быстрее ;P
| |
|
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 не ускоряет скорость сборки, даже чуть замедляет, ускоряется скорость пересборки,
это как веб-прокси, если страница не кеширована , то она будет скачана полностью, если кеширована , то возьмется из кеша
| |
|
|
|
|