LINUX.ORG.RU

СлабО взять и померять конкретно на своем коде и со своим набором опций?!? Зачем дебильные вопросы тут задаешь?

anonymous
()
Ответ на: комментарий от anonymous

А я может хочу чтобы ответ на форуме был. Чтобы другому человеку полезно было. Чтобы он когда искал в интернете нашел бы ответ.

facelift
() автор топика

Быстрее в плане компиляции или в плане генерируемого кода?

Компиляция быстрее у clang/llvm. В бенчмарках в основном выигрывает код, порождённый gcc. Смотри пхороникс на эту тему.

EXL ★★★★★
()
Ответ на: комментарий от EXL

Искал скорость компиляции. Про скорость работы скомпиленного нашел, g++ быстрее.

Кароче, писать на clang. А релиз на g++. Вот че нашел http://insights.dice.com/2013/11/04/speed-test-comparing-intel-c-gnu-c-and-ll...

Всем спасибо.

facelift
() автор топика
Ответ на: комментарий от facelift

А я может хочу чтобы ответ на форуме был. Чтобы другому человеку полезно было. Чтобы он когда искал в интернете нашел бы ответ.

Ну так запостите свои изыскания на форуме. К чему тупой вопрос?

andreyu ★★★★★
()
Ответ на: комментарий от facelift

Это старая статья. Потом, по ссылке, например, последний тест проводит бОльшую часть времени в system и конечная разница незначительна. При этом используется cilk который я бы не назвал типичным кодом на cpp. Поэтому делать вывод «g++ быстрее» преждевременно.

Правильным ответом будет «тестируй сам на своём коде и со своими флагами». У нас на разных программах разные результаты получаются. Но зато clang умеет диагностировать бОльшее кол-про проблем в коде, имхо.

true_admin ★★★★★
()
Ответ на: комментарий от facelift

Синтетические тесты такие синтетические. Но общий посыл правильный.

Вот ссылка на нормальные замеры (смотрим в менюшку слева, выбираем 2014 -> x86_64 SPEC2000).

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

alexanius ★★
()
Ответ на: комментарий от alexanius

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

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

anonymous
()
Ответ на: комментарий от andreyu

Дык нету их =( Постить нечего

Нормальный вопрос ничего тупого в нем нет.

facelift
() автор топика
Последнее исправление: facelift (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

А все предупреждения вычищать не всегда нужно - частенько бывают или false-positive вообще, или false-positive в определённых режимах компиляции.

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

alexanius ★★
()

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Gorthauer

Особенности начинаются если брать libc++ вместо gccшной.

Что clang++, что g++ по умолчанию используют libstdc++ на линуксе. И обоих есть g++-libc++ и clang++-libc++. Так что аргумент притянут даже не за уши.

anonymous
()

Вот более-менее актуальное сравнение: http://www.phoronix.com/scan.php?page=article&item=clang-gcc-broadwell&am... . Часть тестов лучше, часть хуже, принципиально проигрывает только в тестах с OpenMP, т.к. он еще не реализован. Обещают к следующему релизу сделать, тогда совсем догонит.

nonimous
()
Ответ на: комментарий от alexanius

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

clang имеет поддержку расширений gcc. Хотя, конечно же, лучше в их сторону даже не смотреть и писать по стандарту. Насчет оптимизаций - - в любом случае дебаг/релиз отличаются, хоть с gcc, хоть с clang.

anonymous
()
Ответ на: комментарий от Gorthauer

Тем не менее, есть макось, есть FreeBSD, там уже clang+libc++ дефолт.

Это, конечно, плюс для clang и libc++, но уже не имеет отношения к оригинальной теме.

Да и всякие sanitizer'ы лучше себя ведут с libc++

И оптимизация, кстати, тоже. clang с ней может в простых случаях выкидывать выделения памяти на куче.

anonymous
()

конечно быстрее и лучше, поэтому все дистрибутивы удалили гэцэцэ и перешли на шланг.

splinter ★★★★★
()

libreoffice и firefox у меня цлангом собирались почти в 2 раза быстрее

Alyssa
()
Ответ на: комментарий от splinter

епстать! кто-то перевел мой дебиан на кланг, пока я спал!

anonymous
()
Ответ на: комментарий от facelift

Ты тупой? Универсального ответа быть не может, у каждого свой код, своя пдатформа и свой набор опций.

anonymous
()
Ответ на: комментарий от alexanius

Адаптирующих код к особенностям компиляторов надо убивать.

anonymous
()
Ответ на: комментарий от anonymous

Без gccшных computed goto не обойтись. Хорошо, что это расширение почти все поддерживают.

anonymous
()

Точно так же

Я как-то проверял (во времена clang-3.3) на своем проекте. Мой проект собирается где-то 1.5 минуты с нуля, и что clang, что gcc показывали одинаковое время +- пара секунд.

В обще какого-то особенного ускорения в компиляции или в скорости компилируемого кода не нашел.

Единственное, в чем clang на порядок превосходил gcc это «вменяемые» сообщения об ошибках при компилировании кода на c++ со сложными шаблонами .

fghj ★★★★★
()
Ответ на: комментарий от splinter

там религия ещё может играть роль: разные лицензии компиляторов

next_time ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.