1.1, Аноним (1), 17:48, 08/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Бессмысленный тест. Тут главное не скорость компиляции, а качество полученного кода и качество поддержки спецификаций языка.
Лучше бы они попробовали этими компиляторами собрать скажем debian репозиторий и написали сколько пакетов завалилось.
| |
|
2.3, pavlinux (ok), 17:56, 08/11/2010 [^] [^^] [^^^] [ответить]
| +4 +/– |
Читаем снова:
>хотя собранный в GCC код как правило продемонстрировал немного более высокую скорость
> работы. Значительный провал в производительности Clang и LLVM-GCC наблюдался в тестах
> John The Ripper Blowfish (отставание 40%), HMMer (10-18%), GraphicsMagick (20-50%).
> В тесте C-Ray Clang и LLVM-GCC оказались быстрее GCC на 10-20%. | |
|
3.5, Аноним (1), 18:32, 08/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
Читаем снова:
>качество поддержки спецификаций языка.
>Лучше бы они попробовали этими компиляторами собрать скажем debian репозиторий и написали сколько пакетов завалилось. | |
|
4.7, simpler (?), 19:51, 08/11/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
Да уж. Лишнее подтверждение тому, что большинство потребителей сделанного кем-то для них ПО ни о чем кроме скорости думать не могут.
И даже когда прочитают, просто ничего друго не воспринимают. И не могут себе представить, как можно о чем-то, кроме скорости, думать.
| |
|
5.10, User294 (ok), 21:51, 08/11/2010 [^] [^^] [^^^] [ответить]
| –3 +/– |
Да, давайте подумаем еще о чем-нибудь. Например, о том что некоторые тесты вообще шлангом не собрались (точнее, если уж не собирается то как правило всеми LLVM-based сразу). О чем в новости почему-то стыдливенько заскипано. Среди не скомпилившихся шлангом тестов кроме всего прочего был и x264, например. Очень уж это все напоминает "зато мы делаем ракеты и перекрыли Енисей" в свете недавних трублений про сборку ядра линуха :). Ради справедливости замечу что девеловской веткой гцц x264 тоже не собрался, но там хотя-бы честно указано что оно девел ;)
Также как-то стыдливо заскипан аццкий слив, местами почти в три (!!!) раза в графикc магике. Интересно, как получается "20-50% отставание" при 53 попугаях максимум у LLVM-based vs 138 попугаев у GCC? Ну ладно, пусть 131 попугае - для последней релизной версии гцц. Ну-ка расскажите, математики, это как? Автору новости 2 балла - за неумение пользоваться калькулятором, или того хуже "гетзефаксы".
| |
|
6.12, cdome (ok), 22:10, 08/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
Ну со сливом в ImageMagic то же понятно. LLVM до сих пор не поддерживает OpenMP, который во всю использует ImageMagic
| |
6.13, cdome (ok), 22:19, 08/11/2010 [^] [^^] [^^^] [ответить]
| +3 +/– |
Единственное, что привлекло мое внимание в этом тесте, так это Himeno Benchmark. Когда на интеле gcc и clang идут практически вровень, но на AMD Opteron - clang в два раза быстрее gcc и вообще быстрее core i7.
Не происки ли это инженеров интела, которые сейчас занимаются gcc в плотную. Надо попробывать повторить и зафайлить баг репорт в gcc.
| |
6.14, simpler (?), 22:31, 08/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
> Да, давайте подумаем еще о чем-нибудь.
Ну хотя бы уже что-то.
> Например, о том что некоторые тесты вообще шлангом не собрались (точнее, если уж не собирается то как правило всеми LLVM-based сразу).
Т.е. вы хотите, чтобы clang сразу моментально был похож на gcc один в один.
Не смотря на общую динамику развития.
Просто разработчики сосредоточились на выявлении конкретных несовместимостей при сборке конкретного ПО. А не просто на тестах ради тестов.
Кроме того, те фичи, допустим в Линукс-ядре, которые собираются ценой уродства архитектуры gcc - можно выкинуть из самого (например) Линукса, а не пытаться портить новый компилятор ради поддержки дурных решений.
Просто многоие поклонники этих gcc-ориентированных убогостей из-за шаблонности своего мышления не догадываются, что у разработчиков компиляторов всегда есть такой ход, как не поддерживать те фичи, которые им не нравятся. Что неминуемо повлечет за собой переделку самого софта, который подобные угробищные фичи поддерживает. А вовсе не допиливания самого компилятора в целях соответствия какому-то очередному убожетсву.
| |
|
7.15, ананим (?), 22:55, 08/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Кроме того, те фичи, допустим в Линукс-ядре, которые собираются ценой уродства архитектуры gcc - можно выкинуть из самого (например) Линукса, а не пытаться портить новый компилятор ради поддержки дурных решений.
опа. тонкий намёк на "правьте свой линух под шланг".
а оно кому нужно то?
| |
|
8.19, simpler (?), 23:22, 08/11/2010 [^] [^^] [^^^] [ответить] | +2 +/– | То есть вы только сейчас поняли, что такой вариант возможен и даже более вероят... текст свёрнут, показать | |
|
7.26, Аноним (1), 04:48, 09/11/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
>уродства архитектуры gcc
>gcc-ориентированных убогостей
>подобные угробищные фичи поддерживает.
>соответствия какому-то очередному убожетсву.
Вы так обоснованно аргументируете свою позицию, что нам, адекватным людям, даже возразить нечего.
| |
|
8.27, simpler (?), 05:17, 09/11/2010 [^] [^^] [^^^] [ответить] | +1 +/– | То, что вам нечего возразить - это понятно Собственную адекватность вы считаете... текст свёрнут, показать | |
|
7.31, User294 (ok), 14:27, 09/11/2010 [^] [^^] [^^^] [ответить] | –3 +/– | Ну, вообще, я почему-то нескромно считаю что если проводится бенчмарк - было бы ... большой текст свёрнут, показать | |
|
8.35, simpler (?), 16:27, 09/11/2010 [^] [^^] [^^^] [ответить] | +/– | А в моем понимании в подобных вопросах надо смотреть на качество конкретного код... большой текст свёрнут, показать | |
|
9.40, User294 (ok), 22:45, 09/11/2010 [^] [^^] [^^^] [ответить] | –4 +/– | А четкие критерии качества - можно в студию Кстати да, для кодека требование ... большой текст свёрнут, показать | |
|
|
|
|
|
|
|
|
1.4, Аноним (-), 18:04, 08/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
>7-Zip, LAME MP3, x264
>расхождения в показателях были незначительны
Может я заблуждаюсь, но там чёртова куча ассемблерных вставок, так что мерить на них компилятор С как-то глупо, ИМХО.
| |
|
2.11, User294 (ok), 21:55, 08/11/2010 [^] [^^] [^^^] [ответить]
| –3 +/– |
Для начала - x264 вообще LLVM-based не собрался. Сравнения вообще не вышло. А мерять компилятор на них вполне можно - кроме асмовых вставок роялит все-таки и остальной код. Меньше, но все-таки. Сами понимаете - весь H.264 на гольном асме выписывать вы "немного" устанете :)
| |
|
1.6, анон (?), 18:42, 08/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
В заголовке туманно улавливается ...Phoronix... В теле новости: и правда - он. :)
| |
|
2.8, Толстый (ok), 20:29, 08/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
в чем проблема, проведи и опубликуй свои тесты лучше них, анон.
| |
2.16, User294 (ok), 23:16, 08/11/2010 [^] [^^] [^^^] [ответить]
| –5 +/– |
Ну, фороникс. А чем их набор тестов плох в данном случае? И, наверное, вы тогда можете предложить какие-то тесты лучше?
| |
|
3.18, Кодир (?), 23:21, 08/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
Просто Фороникс что-то типа Радуловой - пёрнет в лужу, а потом тысячи леммингов обсуждают. Тесты прежде всего должны быть профессиональными, подтверждёнными сотнями программеров. А просто вылезти из болота и посчитать факториал - это любой м__к может!
| |
3.20, Sylvia (ok), 00:24, 09/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
то что они сделали тесты - хорошо, но плохо что они берут .0 версии компиляторов,
нужно брать текущие релизы в каждой ветке - 4.1.2 , 4.2.4 , 4.3.5 , 4.4.5 , 4.5.1, последний снапшот 4.6.0-prerelease
если комментировать результаты , то странно что они все LLVM записали в одну кучу
по времени сборки apache у них dragonegg оказался быстрее GCC 4.5.0 , на котором он собственно как плагин и работает, у меня получалось что медленнее
по части же 4.6.0pre - все очень показательно, несмотря на заявленную оптимизацию в производительности компилятора , он тормоз, хотя он только только перешел в Stage3 и к релизу его должны бы оптимизировать немного.
| |
|
4.25, Sylvia (ok), 02:43, 09/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
у меня вот что получилось по диаграмме на 7 странице (сборка Apache на время):
Apache 2.2.17 ./configure --with-included-apr
Gentoo ~x86, Core2Duo 3.00 Ghz
GCC 4.1.2-27 REDHAT
real 0m30.206s
user 0m40.791s
sys 0m5.012s
GCC 4.2.4
real 0m32.142s
user 0m44.680s
sys 0m4.634s
GCC 4.3.5
real 0m31.798s
user 0m43.355s
sys 0m4.993s
GCC 4.4.5
real 0m32.667s
user 0m44.385s
sys 0m5.178s
GCC 4.5.2-pre20101105
real 0m34.554s
user 0m47.673s
sys 0m5.210s
GCC 4.6-prerelease-20101007
real 0m46.991s
user 1m8.754s
sys 0m5.250s
Intel C v11.1
real 0m31.523s
user 0m40.798s
sys 0m6.867s
clang 2.8
real 0m27.711s
user 0m36.800s
sys 0m4.584s
llvm-gcc (llvm 2.8)
real 0m29.369s
user 0m39.399s
sys 0m5.179s
dragonegg 2.8 @ GCC 4.5.2-pre20101105
real 0m30.172s
user 0m39.898s
sys 0m5.792s
хотела опровергнуть вороникс ) а получилось практически также
| |
|
5.33, User294 (ok), 14:40, 09/11/2010 [^] [^^] [^^^] [ответить]
| –3 +/– |
Попробую угадать: у вас наверное гента или что-то подобное. Потому что только гентушников время компиляции волнует больше чем все остальные параметры компилера, типа качества кодогенерации.
| |
|
6.37, Sylvia (ok), 17:31, 09/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
в плане дистрибутива угадали,
но волнует не столько скорость сборки, сколько отношение скорости сборки к получаемой производительности скомпилированой программы, если компилятор скушал на 40% больше времени при сборке, а код получился такой же по скорости, то "зачем платить больше, если не видно разницы ?" (tm)
| |
|
7.38, Sylvia (ok), 17:35, 09/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
PS: по производительности получаемого кода тесты в целом сложнее,
тут с флагами стоит поразбираться, учесть возможную нестабильность в случае экстремальных флажков, наличие inline asm оптимизаций и много чего еще, Clang же в общем случае вполне уже наступает GCC на пятки ;)
| |
|
|
|
|
|
|
1.9, Zenitur (?), 20:32, 08/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А где же компилятор от Intel? Да, он несвободен - но всё же он один такой, можно было бы и протестировать.
| |
|
2.23, анонимус (??), 01:41, 09/11/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
Почему один ? Есть еще pathscaleовский path64, который только недавно стал свободным. Кстати, по некоторым вещам здорово уделывает icc.
| |
|
1.17, Kodir (?), 23:19, 08/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Какова бы ни была скорость, ставку надо делать на ИЗНАЧАЛЬНО ПРОДУМАННЫЙ llvm. Впоследствии все гццшные трюки можно точно так же перенести в clang, так что проблем со скоростью не будет.
Надо уметь отметать старое, пока старое как снежный ком не смяло вас самих (см. историю Линукс).
| |
1.28, Аноним (-), 09:30, 09/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
не нашел какие были оптимизации
А в реальности надо просто убрать С/С++ (с его инклудами и разделением на заголовок и реализацию) и заменить на более быстрый для компиляции язык более подверженный оптимизации.
| |
1.30, cdome (ok), 10:34, 09/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Люди!
Кто пользуеться LLVM, скажите как у него с поддержкой Windows?
| |
|
2.32, Аноним (-), 14:37, 09/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
o_O
а у GCC как с поддержкой виндоус? Только не надо всякие cygwin, mingw и т.д.
| |
|
|