forum.opennet.ru - "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" (49)

"Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	+/–
Сообщение от opennews (??), 08-Ноя-10, 17:48
Ресурс Phoronix представил (http://www.phoronix.com/scan.php?page=article&item=llvm_gcc_...) результаты тестирования производительности GCC (4.2.1, 4.3.0, 4.4.0, 4.5.1, 4.6-20101030) и основанных на LLVM 2.8 проектов LLVM-GCC, DragonEgg и Clang. По сравнению с GCC проекты на основе LLVM показали более высокую скорость компиляции, оказавшись впереди в оценивающих скорость сборки тестах (сборка apache и ImageMagic). В 8 тестах (Apache benchmark, Gcrypt, OpenSSL, Himeno, MAFFT, 7-Zip, LAME MP3, x264), оценивающих производительность различных приложений, расхождения в показателях были незначительными, хотя собранный в GCC код как правило продемонстрировал немного более высокую скорость работы. Значительный провал в производительности Clang и LLVM-GCC наблюдался в тестах John The Ripper Blowfish (отставание 40%), HMMer (10-18%), GraphicsMagick (20-50%). В тесте C-Ray Clang и LLVM-GCC оказались быстрее GCC на 10-20%. URL: http://www.phoronix.com/scan.php?page=article&item=llvm_gcc_... Новость: http://www.opennet.ru/opennews/art.shtml?num=28569
Ответить \| Правка \| Cообщить модератору

Оглавление

Бессмысленный тест Тут главное не скорость компиляции, а качество полученного к, Аноним (1), 17:48 , 08-Ноя-10, (1) +3

Читаем снова , pavlinux (ok), 17:56 , 08-Ноя-10, (3) +4

Читаем снова , Аноним (1), 18:32 , 08-Ноя-10, (5)

Да уж Лишнее подтверждение тому, что большинство потребителей сделанного кем-то, simpler (?), 19:51 , 08-Ноя-10, (7) +1

Да, давайте подумаем еще о чем-нибудь Например, о том что некоторые тесты вообщ, User294 (ok), 21:51 , 08-Ноя-10, (10) –3

Ну со сливом в ImageMagic то же понятно LLVM до сих пор не поддерживает OpenMP,, cdome (ok), 22:10 , 08-Ноя-10, (12)
Единственное, что привлекло мое внимание в этом тесте, так это Himeno Benchmark, cdome (ok), 22:19 , 08-Ноя-10, (13) +3
Ну хотя бы уже что-то Т е вы хотите, чтобы clang сразу моментально был похож на, simpler (?), 22:31 , 08-Ноя-10, (14)

опа тонкий намёк на правьте свой линух под шланг а оно кому нужно то , ананим (?), 22:55 , 08-Ноя-10, (15)

То есть вы только сейчас поняли, что такой вариант возможен и даже более вероят, simpler (?), 23:22 , 08-Ноя-10, (19) +2

неа не понял Dвот когда весь будет собираться, тогда смело напишем - собирает, ананим (?), 01:27 , 09-Ноя-10, (21)

зы во фантазёр прям аш зависть берёт Dвсё завтра сношу линух и ставлю оси, , ананим (?), 01:30 , 09-Ноя-10, (22)

Вообще, правильные вещи говорит человек Нефига писать непереносимый код Левые , анонимус (??), 21:06 , 09-Ноя-10, (39)

Я вообще-то как раз переносинмость саму по себе в виду не имел Поскольку перено, simpler (?), 22:52 , 09-Ноя-10, (41)
ты считал в каком месте бОльшая , pavel_simple (ok), 23:20 , 09-Ноя-10, (43)
http www opennet ru opennews art shtml num 28418Я не считал Может даже и не б, simpler (?), 23:51 , 09-Ноя-10, (44)
так и запишем -- фантазёр, pavel_simple (ok), 16:18 , 10-Ноя-10, (45) –1
Так и запишем - для вас важнее количество строк кода и показатели скорости, неже, simpler (?), 03:38 , 11-Ноя-10, (46)
для меня важно -- чтобы всякие мимопролетающие трололо сливали за пизд Wничем не, pavel_simple (ok), 07:05 , 11-Ноя-10, (47)
Ну конечно По-вашему получается, что содержимое всех новостей о си-ланге - тоже, simpler (?), 10:41 , 11-Ноя-10, (48)

Вы так обоснованно аргументируете свою позицию, что нам, адекватным людям, даже , Аноним (1), 04:48 , 09-Ноя-10, (26) +1

То, что вам нечего возразить - это понятно Собственную адекватность вы считаете , simpler (?), 05:17 , 09-Ноя-10, (27) +1

Человек адекватен, если не доказано обратное Своим постом вы доказали свою неад, Unforgiven (??), 14:43 , 09-Ноя-10, (34) –1

Тем, кому в свое время с большим трудом удалось чему-то с грехом пополам научить, simpler (?), 16:40 , 09-Ноя-10, (36)

Ну, вообще, я почему-то нескромно считаю что если проводится бенчмарк - было бы , User294 (ok), 14:27 , 09-Ноя-10, (31) –3

А в моем понимании в подобных вопросах надо смотреть на качество конкретного код, simpler (?), 16:27 , 09-Ноя-10, (35)

А четкие критерии качества - можно в студию Кстати да, для кодека требование , User294 (ok), 22:45 , 09-Ноя-10, (40) –4

Сюдя по всему, вы все-таки осознали реальность того, что под clang начнут собира, simpler (?), 23:12 , 09-Ноя-10, (42)

GCC 4 6 x заруливает - Intel ы не зря старались , Иван Иванович Иванов (?), 17:50 , 08-Ноя-10, (2)
Может я заблуждаюсь, но там чёртова куча ассемблерных вставок, так что мерить на, Аноним (-), 18:04 , 08-Ноя-10, (4) +2

Для начала - x264 вообще LLVM-based не собрался Сравнения вообще не вышло А ме, User294 (ok), 21:55 , 08-Ноя-10, (11) –3

В заголовке туманно улавливается Phoronix В теле новости и правда - он , анон (?), 18:42 , 08-Ноя-10, (6)

в чем проблема, проведи и опубликуй свои тесты лучше них, анон , Толстый (ok), 20:29 , 08-Ноя-10, (8)
Ну, фороникс А чем их набор тестов плох в данном случае И, наверное, вы тогда , User294 (ok), 23:16 , 08-Ноя-10, (16) –5

Просто Фороникс что-то типа Радуловой - пёрнет в лужу, а потом тысячи леммингов , Кодир (?), 23:21 , 08-Ноя-10, (18)
то что они сделали тесты - хорошо, но плохо что они берут 0 версии компиляторов, Sylvia (ok), 00:24 , 09-Ноя-10, (20)

у меня вот что получилось по диаграмме на 7 странице сборка Apache на время Ap, Sylvia (ok), 02:43 , 09-Ноя-10, (25)

Попробую угадать у вас наверное гента или что-то подобное Потому что только ге, User294 (ok), 14:40 , 09-Ноя-10, (33) –3

в плане дистрибутива угадали,но волнует не столько скорость сборки, сколько отно, Sylvia (ok), 17:31 , 09-Ноя-10, (37)

PS по производительности получаемого кода тесты в целом сложнее,тут с флагами с, Sylvia (ok), 17:35 , 09-Ноя-10, (38)

А где же компилятор от Intel Да, он несвободен - но всё же он один такой, можно, Zenitur (?), 20:32 , 08-Ноя-10, (9)

Почему один Есть еще pathscaleовский path64, который только недавно стал свобо, анонимус (??), 01:41 , 09-Ноя-10, (23) +1

Какова бы ни была скорость, ставку надо делать на ИЗНАЧАЛЬНО ПРОДУМАННЫЙ llvm В, Kodir (?), 23:19 , 08-Ноя-10, (17) –2

вот-вот даёшь релиз gcc 4 6 , ананим (?), 01:52 , 09-Ноя-10, (24) +1

не нашел какие были оптимизацииА в реальности надо просто убрать С С с его ин, Аноним (-), 09:30 , 09-Ноя-10, (28)
дополнение И переписать на новый язык Фришку и Линукс, Аноним (-), 09:40 , 09-Ноя-10, (29)
Люди Кто пользуеться LLVM, скажите как у него с поддержкой Windows , cdome (ok), 10:34 , 09-Ноя-10, (30)

o_Oа у GCC как с поддержкой виндоус Только не надо всякие cygwin, mingw и т д , Аноним (-), 14:37 , 09-Ноя-10, (32)

Чем mingw не угодил Всяк уж получше MSVC по качеству компиляции , анонимус (??), 19:34 , 17-Фев-23, (50)

Сообщения [Сортировка по времени | RSS]

1. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +3 +/–

Сообщение от Аноним (1), 08-Ноя-10, 17:48

Бессмысленный тест. Тут главное не скорость компиляции, а качество полученного кода и качество поддержки спецификаций языка.
Лучше бы они попробовали этими компиляторами собрать скажем debian репозиторий и написали сколько пакетов завалилось.

Ответить | Правка | Наверх | Cообщить модератору

3. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +4 +/–

Сообщение от pavlinux (ok), 08-Ноя-10, 17:56

Читаем снова:

>хотя собранный в GCC код как правило продемонстрировал немного более высокую скорость
> работы. Значительный провал в производительности Clang и LLVM-GCC наблюдался в тестах
> John The Ripper Blowfish (отставание 40%), HMMer (10-18%), GraphicsMagick (20-50%).
> В тесте C-Ray Clang и LLVM-GCC оказались быстрее GCC на 10-20%.

Ответить | Правка | Наверх | Cообщить модератору

5. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от Аноним (1), 08-Ноя-10, 18:32

Читаем снова:
>качество поддержки спецификаций языка.
>Лучше бы они попробовали этими компиляторами собрать скажем debian репозиторий и написали сколько пакетов завалилось.

Ответить | Правка | Наверх | Cообщить модератору

7. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +1 +/–

Сообщение от simpler (?), 08-Ноя-10, 19:51

Да уж. Лишнее подтверждение тому, что большинство потребителей сделанного кем-то для них ПО ни о чем кроме скорости думать не могут.
И даже когда прочитают, просто ничего друго не воспринимают. И не могут себе представить, как можно о чем-то, кроме скорости, думать.

Ответить | Правка | Наверх | Cообщить модератору

10. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" –3 +/–

Сообщение от User294 (ok), 08-Ноя-10, 21:51

Да, давайте подумаем еще о чем-нибудь. Например, о том что некоторые тесты вообще шлангом не собрались (точнее, если уж не собирается  то как правило всеми LLVM-based сразу). О чем в новости почему-то стыдливенько заскипано. Среди не скомпилившихся шлангом тестов кроме всего прочего был и x264, например. Очень уж это все напоминает "зато мы делаем ракеты и перекрыли Енисей" в свете недавних трублений про сборку ядра линуха :). Ради справедливости замечу что девеловской веткой гцц x264 тоже не собрался, но там хотя-бы честно указано что оно девел ;)
Также как-то стыдливо заскипан аццкий слив, местами почти в три (!!!) раза в графикc магике. Интересно, как получается "20-50% отставание" при 53 попугаях максимум у LLVM-based vs 138 попугаев у GCC? Ну ладно, пусть 131 попугае - для последней релизной версии гцц. Ну-ка расскажите, математики, это как? Автору новости 2 балла - за неумение пользоваться калькулятором, или того хуже "гетзефаксы".

Ответить | Правка | Наверх | Cообщить модератору

12. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от cdome (ok), 08-Ноя-10, 22:10

Ну со сливом в ImageMagic то же понятно. LLVM до сих пор не поддерживает OpenMP, который во всю использует ImageMagic

Ответить | Правка | Наверх | Cообщить модератору

13. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +3 +/–

Сообщение от cdome (ok), 08-Ноя-10, 22:19

Единственное, что привлекло мое внимание в этом тесте,  так это Himeno Benchmark. Когда на интеле gcc и clang идут практически вровень, но на AMD Opteron - clang в два раза быстрее gcc и вообще быстрее core i7.
Не происки ли это инженеров интела, которые сейчас занимаются gcc в плотную. Надо попробывать повторить и зафайлить баг репорт в gcc.

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

14. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от simpler (?), 08-Ноя-10, 22:31

> Да, давайте подумаем еще о чем-нибудь.
Ну хотя бы уже что-то.
> Например, о том что некоторые тесты вообще шлангом не собрались (точнее, если уж не собирается  то как правило всеми LLVM-based сразу).
Т.е. вы хотите, чтобы clang сразу моментально был похож на gcc один в один.
Не смотря на общую динамику развития.
Просто разработчики сосредоточились на выявлении конкретных несовместимостей при сборке конкретного ПО. А не просто на тестах ради тестов.
Кроме того, те фичи, допустим в Линукс-ядре, которые собираются ценой уродства архитектуры gcc - можно выкинуть из самого (например) Линукса, а не пытаться портить новый компилятор ради поддержки дурных решений.
Просто многоие поклонники этих gcc-ориентированных убогостей из-за шаблонности своего мышления не догадываются, что у разработчиков компиляторов всегда есть такой ход, как не поддерживать те фичи, которые им не нравятся. Что неминуемо повлечет за собой переделку самого софта, который подобные угробищные фичи поддерживает. А вовсе не допиливания самого компилятора в целях соответствия какому-то очередному убожетсву.

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

15. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от ананим (?), 08-Ноя-10, 22:55

>Кроме того, те фичи, допустим в Линукс-ядре, которые собираются ценой уродства архитектуры gcc - можно выкинуть из самого (например) Линукса, а не пытаться портить новый компилятор ради поддержки дурных решений.
опа. тонкий намёк на "правьте свой линух под шланг".
а оно кому нужно то?

Ответить | Правка | Наверх | Cообщить модератору

19. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +2 +/–

Сообщение от simpler (?), 08-Ноя-10, 23:22

> опа. тонкий намёк на "правьте свой линух под шланг".
То есть вы только сейчас поняли, что такой вариант возможен (и даже более вероятен).
> а оно кому нужно то?
Тем, кому нужно, те и будут делать.
Большая часть Линукса уже собирается под clang.
Скоро начнут появляться дистрибутивы Линукса, полностью собранные clang, в которых просто не будет угробищных фич, которые clang'ом не собираются. Для этих фич просто будут делать замены.
Кроме того, те оси, ядра которых легче собираются под clang получат дополнительное преимущество над Linux, а не наоборот.
Вы то ждали, что разработчики clang будут гоняться за gcc в стремлении собрать весь Линукс до последней строчки исходного кода. А окажется, что это Линуксу придется гоняться за совместимостью с другими компиляторами.
Вы то думали, что это будет проблемой clang и llvm, что они что-то не собирают. А оказывается это будет проблемой того софта, который не собирается под clang.
Другой вопрос, что это все повлечет за собой очередную волну изменений, и появятся новые возможности для выбора. А кое-кому очень трудно переучиваться. А ввиду того, что они обычно выбирают, глядя на общественное мнение и на "скорость", и не способны анализировать архитектуру ПО, большая часть привязанностей таких вот потребителей состоит именно из подобных угробищных фич.

Ответить | Правка | Наверх | Cообщить модератору

21. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от ананим (?), 09-Ноя-10, 01:27

>То есть вы только сейчас поняли, что такой вариант возможен (и даже более вероятен).
неа. не понял. :D
>Тем, кому нужно, те и будут делать.
>Большая часть Линукса уже собирается под clang.
вот когда весь будет собираться, тогда смело напишем - собирается шлангом. мы молодцы.

Ответить | Правка | Наверх | Cообщить модератору

22. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от ананим (?), 09-Ноя-10, 01:30

зы:
>Кроме того, те оси, ядра которых легче собираются под clang получат дополнительное преимущество над Linux, а не наоборот.
>Вы то ждали, что разработчики clang будут гоняться за gcc в стремлении собрать весь Линукс до последней строчки исходного кода. А окажется, что это Линуксу придется гоняться за совместимостью с другими компиляторами.
во фантазёр! прям аш зависть берёт! :D
всё! завтра сношу линух и ставлю "оси, ядра которых легче собираются под clang".

Ответить | Правка | Наверх | Cообщить модератору

39. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от анонимус (??), 09-Ноя-10, 21:06

Вообще, правильные вещи говорит человек. Нефига писать непереносимый код. Левые фишки не нужны.

Ответить | Правка | Наверх | Cообщить модератору

41. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от simpler (?), 09-Ноя-10, 22:52

> Вообще, правильные вещи говорит человек. Нефига писать непереносимый код. Левые фишки не нужны.
Я вообще-то как раз переносинмость саму по себе в виду не имел. Поскольку переносимость ради переносимости "серебряной пулей" не является.
Я говорил о том, что у gcc очень долго не было альтернатив в мире свободного софта. И теперь появилась качественная альтернатива.
А также о том, что поскольку бОльшая часть ядра Линукса уже собирается под clang, в скором времени стоит ожидать появление дистрибутивов, основанных на llvm. Не говоря уже о FreeBSD.
А те куски, которые под clang не собираются никто не мешает заменить. Причем вовсе не обязательно _переносимым_ образом. И скорее всего так оно и будет. Один раз кто-то начнет - потом уже не остановишь.
И еще о том, что судя по всему, разработчики clang не пытаются подгонять новый компилятор под все существующие стандарты и под все проекты с сомнительным качеством кода.
В чем я их и поддерживаю.
Я считаю, что важнее свобода выбора, чем абстрактная переносимость. И это совсем разные вещи. Важнее качественные языки и инструменты программирования, чем нереализованные или плохо реализованные стандарты на прораммирование.
Никто не запрещает делать форки вместо переносимости. Хотя многих это и раздражает, тех кто хочет, чтобы у всех все было одинаково.

Ответить | Правка | Наверх | Cообщить модератору

43. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от pavel_simple (ok), 09-Ноя-10, 23:20

> А также о том, что поскольку бОльшая часть ядра Линукса уже собирается
> под clang,
ты считал?
в каком месте бОльшая?

Ответить | Правка | Наверх | Cообщить модератору

44. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от simpler (?), 09-Ноя-10, 23:51

> ты считал?
> в каком месте бОльшая?
http://www.opennet.ru/opennews/art.shtml?num=28418
Я не считал. Может даже и не бОльшая, если тупо считать по количеству строк кода. А может и действительно бОльшая, судя по тексту - не принципиально.
В любом случае - самодостаточная часть. Достигнуто состояние self-hosting.
Это означает, что в скором времени следует ожидать появление основанных на clang дистрибутивов. Дистрибутивов, где clang будет основным компилятором. Как бы это некоторых не раздражало.

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

45. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" –1 +/–

Сообщение от pavel_simple (ok), 10-Ноя-10, 16:18

> Я не считал.
так и запишем -- фантазёр

Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

46. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от simpler (?), 11-Ноя-10, 03:38

> так и запишем -- фантазёр
Так и запишем - для вас важнее количество строк кода и показатели скорости, нежели качественный результат.
То, что ядро Linux собирается си-лангом - это уже подтвержденный факт, а вы все никак в это поверить не можете.

Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

47. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от pavel_simple (ok), 11-Ноя-10, 07:05

>> так и запишем -- фантазёр
> Так и запишем - для вас важнее количество строк кода и показатели
> скорости, нежели качественный результат.
> То, что ядро Linux собирается си-лангом - это уже подтвержденный факт, а
> вы все никак в это поверить не можете.
для меня важно -- чтобы всякие мимопролетающие трололо сливали за пизд^Wничем не прикрытое враньё -- пошло уже

Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

48. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от simpler (?), 11-Ноя-10, 10:41

Ну конечно. По-вашему получается, что содержимое всех новостей о си-ланге - тоже вранье.
Или вообще по-вашему си-ланга не существует, это лишь "фантазия".
Да продолжайте пользоваться gcc. Кто-то запрещает что-ли.
Что так волноваться-то из-за того, что у других появится возможность им не пользоваться.

Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

26. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +1 +/–

Сообщение от Аноним (1), 09-Ноя-10, 04:48

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

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

27. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +1 +/–

Сообщение от simpler (?), 09-Ноя-10, 05:17

> Вы так обоснованно аргументируете свою позицию, что нам, адекватным людям, даже возразить нечего.
То, что вам нечего возразить - это понятно.
Собственную адекватность вы считаете при этом само собой разумеющимся фактом, не требующим аргументации.
Что же касается моей позиции, то я ее особо обосновывать не старался - я ее просто высказал.
Обоснование - это процесс скрупулезный. И если вы ищите обоснований на форумах по обсуждению новостей, то видимо вы плохо представляете себе, что же такое обоснования.
Суть же моей позиции очень проста.
Если разработан компилятор с более качественной модульной архитектурой, то его не будут подгонять под какой попало код, лишь бы отчитаться, что он может компилировать что угодно.
И даже без моего старания это обосновать, вам, как это видно, возразить нечего.

Ответить | Правка | Наверх | Cообщить модератору

34. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" –1 +/–

Сообщение от Unforgiven (??), 09-Ноя-10, 14:43

> Собственную адекватность вы считаете при этом само собой разумеющимся фактом, не требующим аргументации.
Человек адекватен, если не доказано обратное. Своим постом вы доказали свою неадекватность и этого достаточно.
> Если разработан компилятор с более качественной модульной архитектурой, то его не будут подгонять под какой попало код, лишь бы отчитаться, что он может компилировать что угодно.
И часто мсье занимался разработкой компиляторов? Судя по постам - даже не пользовался.
> И даже без моего старания это обосновать, вам, как это видно, возразить нечего.
А вы будете возражать лающей собаке?

Ответить | Правка | Наверх | Cообщить модератору

36. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от simpler (?), 09-Ноя-10, 16:40

Тем, кому в свое время с большим трудом удалось чему-то с грехом пополам научиться, но при этом уже не дано изучить что-то новое - только и остается утешать себя подобным образом.
Рассуждая о сферической адекватности в вакууме. Ну и еще о скорости. Больше им не о чем говорить.

Ответить | Правка | Наверх | Cообщить модератору

31. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" –3 +/–

Сообщение от User294 (ok), 09-Ноя-10, 14:27

> Т.е. вы хотите, чтобы clang сразу моментально был похож на gcc один в один.
Ну, вообще, я почему-то нескромно считаю что если проводится бенчмарк - было бы хорошо если бы участники оного не фэйлили тесты для начала. На GCC тоже можно в принципе понаезжать за это, но меньше и в основном на девел версию.
> Не смотря на общую динамику развития.
Динамика - это хорошо. Кто б спорил. Вот только учтя что почти все разработчики в эппле - вопрос в том в чью пользу эта динамика будет.
> Просто разработчики сосредоточились на выявлении конкретных несовместимостей при сборке
> конкретного ПО. А не просто на тестах ради тестов.
Ну, в моем понимании, компилер претендующий на полноценность все-таки должен осиливать сборку софта типа x264.
> Кроме того, те фичи, допустим в Линукс-ядре, которые собираются ценой уродства
> архитектуры gcc - можно выкинуть из самого (например) Линукса, а не пытаться
> портить новый компилятор ради поддержки дурных решений.
Нет, безусловно, идеальный мир - это хорошо. Вот только понятия о "дурных решениях" может и не совпадать у разных индивидуалов. Это вас не смущает? :) И, собссно, а что убедит ядерщиков проделать этот объем работ? Заява каких-то конкретных индивидуалов "%s - дурное решение" имхо вообше не котируется, как минимум без хорошего технического обоснования.
> Просто многоие поклонники этих gcc-ориентированных убогостей
А на основании чего - "убогостей"? То что для вас - убогости, для других может быть и рулезом. А истина - как обычно где-то посередине.
> из-за шаблонности своего мышления не догадываются, что у разработчиков
> компиляторов всегда есть такой ход, как не поддерживать те фичи, которые  им не нравятся.
А знаете, у разработчиков софта есть такой ход как потребовать пререквизиты для сборки. И можно указать среди них конкретный компилер с конкретными фичами, например, если разработчики других компилеров не хотят идти навстречу и реализовывать фичи а эти фичи используются. И, кстати, оснований у разработчиков ядра потребовать фичи от компилера - ровно столько же сколько у разработчиков компилера на это положить с прибором :).
Можно, конечно, понаезжать что это портит портабельность. Но гцц есть под все платформы под которые есть LLVM и еще под кучу, под которые LLVM еще и в проекте нет. Так что наезд не очень то и сильный. Да и все другие мало-мальски крупные ядра компилятся 1-2 компилерами без больших плясок с бубнами, так что опять же. Можно конечно по этому поводу заявить что "все пи..сы!", но на этот счет есть довольно жизненный анекдот.
> Что неминуемо повлечет за собой переделку самого софта,
И что же НЕМИНУЕМО сподвигнет разработчиков? Нож? Или пистолет? oO
> который подобные угробищные фичи поддерживает.
Опять же - понятия о прекрасном у всех разные. Как-то за всех решать что для них угробищно а что нет - некультурно, знаете ли. Готов поспорить что разработчики сами выберут для себя - что угробищно, а что - нет. Можете попробовать обосновать почему те или иные фичи угробищны, однако врядли кого-то убедят сами по себе вопли "%s - угробище!". Если кто-то поюзал фичу - очевидно, он не считал ее угробищной.
> А вовсе не допиливания самого компилятора в целях соответствия какому-то очередному
> убожетсву.
Ну, если считается что линуксное ядро - убожество, недостойное нормально компилиться Единственно Правильным Компилером (тм), то что же тогда сподвигнет разработчиков этого ядра шевелиться насчет поддержки этого компилера? Как-то ну совсем нелогично, вы не находите? oO

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

35. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от simpler (?), 09-Ноя-10, 16:27

> Ну, в моем понимании, компилер претендующий на полноценность все-таки должен осиливать сборку софта типа x264.
А в моем понимании в подобных вопросах надо смотреть на качество конкретного кода, а не на названия брендов.
> Вот только понятия о "дурных решениях" может и не совпадать у разных индивидуалов.
> А на основании чего - "убогостей"? То что для вас - убогости, для других может быть и рулезом. А истина - как обычно где-то посередине.
> Опять же - понятия о прекрасном у всех разные.
Я уже сказал выше, что я высказал свое личное мнение.
Кому нравятся фичи от gcc, и код на них основанный, могут продолжать им пользоваться, gcc ведь никто не закрывал.
Просто некоторых очень беспокоит, что появились возможности не пользоваться gcc, и этих возможностей становится все больше и больше в самых разных проектах.
> Ну, если считается что линуксное ядро - убожество, недостойное нормально компилиться Единственно Правильным Компилером (тм), то что же тогда сподвигнет разработчиков этого ядра шевелиться насчет поддержки этого компилера? Как-то ну совсем нелогично, вы не находите? oO
Я вообще-то говорил об отдельных частях Линукс-ядра, а не об ядре в целом.
Или для вас часть эквивалентна целому? Либо все, либо ничего?
Как-то ну совсем нелогично, вы не находите? oO
Ведь бо'льшая часть Линукс-ядра ведь уже собирается с помощью clang.
Вот еще бо'льшую часть кода binutils и coreutils соберут (а во FreeBSD их аналоги уже собрали).
И ничто не помешает создавать дистрибутивы Линукса, полностью основанные на clang.
А те исключения кода (кода, а не проекты целиком), что не соберутся - анализируются, почему не собрались. И что лучше в каждом конкретном случае - добавлять в clang какую-то сомнительную фичу, или просто заменить фичу в конкретном проекте.
Взять хотя бы SELinux. Система громоздкая и неуклюжая. Еще польшой вопрос, стоит ли беспокоиться о ее поддержке новым компилятором.
С другой стороны сам Linux все-таки постепенно допиливают до модульной поддержки систем безопасности. Так что, глядя на новый модульный компилятор, у разработчиков Линукса будет лишний повод задуматься об архитектуре ядра.
> И что же НЕМИНУЕМО сподвигнет разработчиков? Нож? Или пистолет? oO
Общие тенденции в сторону повышения модульности и гибкости при проектировании.
Хотя конечно для многих ввиду шаблонности и монолитности их мышления - это равносильно ножу или пистолету.

Ответить | Правка | Наверх | Cообщить модератору

40. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" –4 +/–

Сообщение от User294 (ok), 09-Ноя-10, 22:45

> А в моем понимании в подобных вопросах надо смотреть на качество конкретного
> кода, а не на названия брендов.
А четкие критерии качества - можно в студию? Кстати да, для *кодека* требование вида "строгий ANSI C" - не обязательно катят. Если вам кодек H.264 на строгом анси цэ написать, без асмовых кусков (которые по определению не описаны в стандартах на си) - вы же и будете рыдать от производительности такого кодека.
> Я уже сказал выше, что я высказал свое личное мнение.
> Кому нравятся фичи от gcc, и код на них основанный, могут продолжать
> им пользоваться, gcc ведь никто не закрывал.
Отлично. Но вы даже не обругали нормально фичи. Более того - вы как-то упустили моменты что бывают нужные фичи которые по определению специфичны для компилера/набора тулсов, но тем не менее нужны. Например, как-то так уж вышло что стандарты не определяют например как делать в сишную программу асмовые вставки. И еще немало моментов.
> Просто некоторых очень беспокоит, что появились возможности не пользоваться gcc, и этих
> возможностей становится все больше и больше в самых разных проектах.
Я вижу даже некий плюс - GCC явно не помешает пинок для ускорения развития :-).
> Я вообще-то говорил об отдельных частях Линукс-ядра, а не об ядре в целом.
Ну, кому надо - может ипстись с выборкой из ядра "неправильных" кусков. Мне не жалко. А у меня и более интересные дела есть. Подозреваю что у аффтаров майнлайнового ядра - тоже.
> Или для вас часть эквивалентна целому? Либо все, либо ничего?
Ядро поставляется как некий продукт. Дальше я выбираю какие его субкомпоненты мне нужны. И мне как-то ну совсем не прикольно выкидывать компоненты не потому что "так лучше" и "это хорошо для решения задачи", а потому что ... "компилер не может это сжевать". А зачем мне геморрой на ровном месте? oO
> Как-то ну совсем нелогично, вы не находите? oO
Нет, я не нахожу. Если мне приспичило пересобрать ядро - то по каким-то веским причинам, к которым расовая (не)верность компилеров ни разу не относится. Благо, я ни разу в жизни не ощущал на своем заду никаких ограничений от гцц, даже собирая им нахрен проприетарную фирмварину защищенную от чтения, что вполне допустимо его лицензией. А возможность всяких там япплов зажопить код инструментария и устроить всем при случае кидок а-ля дарвинское ядро меня как-то интересует вообще в последнюю очередь. Я просто в меру возможностей не буду закладываться на тулзы которые зависят от 1 коммерческой конторы - нафиг-нафиг лишние риски. Вон жабисты уже на своем заду ощущают последствия такой практики :-).
> Ведь бо'льшая часть Линукс-ядра ведь уже собирается с помощью clang.
Есть такая весьма правдивая байка, которая гласит что 80% работы обычно делается за 20% времени. Весь компот портят остальные 20%, на выполнение которых уходит оставшиеся 80% времени :)
> Вот еще бо'льшую часть кода binutils и coreutils соберут (а во FreeBSD
> их аналоги уже собрали).
Шланг с бинутилсами? Это видимо из разряда "без порток, а в шляпе". Благо бинутилсы тоже под расово-неверной лицензией, вызывающией батхерт у бсдшников и эппла. :)
> И ничто не помешает создавать дистрибутивы Линукса, полностью основанные на clang.
Как бы флаг в руки тем кому это надо. Будет любопытно посмотреть на то что получится.
> А те исключения кода (кода, а не проекты целиком), что не соберутся
> - анализируются, почему не собрались. И что лучше в каждом конкретном
> случае - добавлять в clang какую-то сомнительную фичу, или просто заменить
> фичу в конкретном проекте.
Ну, как бы, вы не можете диктовать всем авторам проектов что им и как делать и за них решать - нужна им та или иная фича. ИМХО, с практической точки зрения - допилить 1 компилер явно проще чем сотни тысяч программ по всему миру.
> Взять хотя бы SELinux. Система громоздкая и неуклюжая. Еще польшой вопрос, стоит
> ли беспокоиться о ее поддержке новым компилятором.
Мне он не нравится. Как раз этим самым. Мне проще сделать сравнимую изоляцию и паранойю совершенно иными методами. Однако редхатчики и федористы вас имхо не поймут. Кроме того, серьезные (гос)конторы и т.п. имеют как правило вполне конкретный регламент работы с секретными документами, где четко прописаны все процедуры. Регламент большинства таких контор - явно требует обязательное наличие системы мандатного контроля доступа (как минимум, у нас и в сша оно АФАЙК вот так, да и другие наверное не сильно отличаются). Без реализации системы мандатного контроля доступа ваша система просто-напросто никогда не попадет в такие конторы, не пройдя сертификацию. А это как ни крути - один из рубежей признания системы "взрослой". Это, конечно, формальности, однако ж появились они в таких конторах не просто так для красоты.
> С другой стороны сам Linux все-таки постепенно допиливают до модульной поддержки систем
> безопасности. Так что, глядя на новый модульный компилятор, у разработчиков Линукса
> будет лишний повод задуматься об архитектуре ядра.
У меня почему-то такое ощущение что они не будут сильно дергаться ради поддержки какого-то (довольно сырого) компилера неизвестно ради чего. В мире как бы много разных компилеров. На все все-равно не надергаешься. Например, есть ICC. Некоторые джедаи им даже что-то собирают. Однако врядли кого в майнлайне интересует объем потребных для этого плясок. Особенно когда интель сам в гцц впихивает патчи для улучшения поддержки своих процов т.к. ему это тоже стало надо :)
>> И что же НЕМИНУЕМО сподвигнет разработчиков? Нож? Или пистолет? oO
> Общие тенденции в сторону повышения модульности и гибкости при проектировании.
А в каком месте упомянутые факторы гарантируют какую-то там неминуемость чего либо? И откуда это следует?
> равносильно ножу или пистолету.
Только для школоло, бегающих за тенденциями и модой.

Ответить | Правка | Наверх | Cообщить модератору

42. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от simpler (?), 09-Ноя-10, 23:12

Сюдя по всему, вы все-таки осознали реальность того, что под clang начнут собирать самодостаточные комплекты ПО, всключая ядра ОСей, гораздо раньше, чем на нем пересоберут весь существующий в Мире код.
И что многие проекты сомнительного качества просто не станут поддерживать. Так и оставят, чтобы их авторы сами думали, осваивать им новый компилятор или нет.
Просто вы до этого о такой возможности даже не подозревали. И думали, что единственным путем развития для нового компилятора (кроме еще гонки за скоростью), будет пересборка всего кода, доставшегося ему в наследство от старого. Потому что "скорость" и "пересборка всего кода" - это наиболее доступные для потребительского понимания темы.
А тут вдруг неожиданно видите, сколько вариантов может еще оказаться. Вот до чего стереотипы доводят. И просто придумываете всякие отмазки для самоутешения.

Ответить | Правка | Наверх | Cообщить модератору

2. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от Иван Иванович Иванов (?), 08-Ноя-10, 17:50

GCC 4.6.x заруливает - Intel'ы не зря старались.

Ответить | Правка | Наверх | Cообщить модератору

4. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +2 +/–

Сообщение от Аноним (-), 08-Ноя-10, 18:04

>7-Zip, LAME MP3, x264
>расхождения в показателях были незначительны
Может я заблуждаюсь, но там чёртова куча ассемблерных вставок, так что мерить на них компилятор С как-то глупо, ИМХО.

Ответить | Правка | Наверх | Cообщить модератору

11. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" –3 +/–

Сообщение от User294 (ok), 08-Ноя-10, 21:55

Для начала - x264 вообще LLVM-based не собрался. Сравнения вообще не вышло. А мерять компилятор на них вполне можно - кроме асмовых вставок роялит все-таки и остальной код. Меньше, но все-таки. Сами понимаете - весь H.264 на гольном асме выписывать вы "немного" устанете :)

Ответить | Правка | Наверх | Cообщить модератору

6. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от анон (?), 08-Ноя-10, 18:42

В заголовке туманно улавливается ...Phoronix... В теле новости: и правда - он. :)

Ответить | Правка | Наверх | Cообщить модератору

8. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от Толстый (ok), 08-Ноя-10, 20:29

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

Ответить | Правка | Наверх | Cообщить модератору

16. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" –5 +/–

Сообщение от User294 (ok), 08-Ноя-10, 23:16

Ну, фороникс. А чем их набор тестов плох в данном случае? И, наверное, вы тогда можете предложить какие-то тесты лучше?

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

18. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от Кодир (?), 08-Ноя-10, 23:21

Просто Фороникс что-то типа Радуловой - пёрнет в лужу, а потом тысячи леммингов обсуждают. Тесты прежде всего должны быть профессиональными, подтверждёнными сотнями программеров. А просто вылезти из болота и посчитать факториал - это любой м__к может!

Ответить | Правка | Наверх | Cообщить модератору

20. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от Sylvia (ok), 09-Ноя-10, 00:24

то что они сделали тесты - хорошо, но плохо что они берут .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 и к релизу его должны бы оптимизировать немного.

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

25. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от Sylvia (ok), 09-Ноя-10, 02:43

у меня вот что получилось по диаграмме на 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
хотела опровергнуть вороникс ) а получилось практически также

Ответить | Правка | Наверх | Cообщить модератору

33. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" –3 +/–

Сообщение от User294 (ok), 09-Ноя-10, 14:40

Попробую угадать: у вас наверное гента или что-то подобное. Потому что только гентушников время компиляции волнует больше чем все остальные параметры компилера, типа качества кодогенерации.

Ответить | Правка | Наверх | Cообщить модератору

37. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от Sylvia (ok), 09-Ноя-10, 17:31

в плане дистрибутива угадали,
но волнует не столько скорость сборки, сколько отношение скорости сборки к получаемой производительности скомпилированой программы, если компилятор скушал на 40% больше времени при сборке, а код получился такой же по скорости, то "зачем платить больше, если не видно разницы ?" (tm)

Ответить | Правка | Наверх | Cообщить модератору

38. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от Sylvia (ok), 09-Ноя-10, 17:35

PS: по производительности получаемого кода тесты в целом сложнее,
тут с флагами стоит поразбираться, учесть возможную нестабильность в случае экстремальных флажков, наличие inline asm оптимизаций и много чего еще, Clang же в общем случае вполне уже наступает GCC на пятки ;)

Ответить | Правка | Наверх | Cообщить модератору

9. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от Zenitur (?), 08-Ноя-10, 20:32

А где же компилятор от Intel? Да, он несвободен - но всё же он один такой, можно было бы и протестировать.

Ответить | Правка | Наверх | Cообщить модератору

23. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +1 +/–

Сообщение от анонимус (??), 09-Ноя-10, 01:41

Почему один ? Есть еще pathscaleовский path64, который только недавно стал свободным. Кстати, по некоторым вещам здорово уделывает icc.

Ответить | Правка | Наверх | Cообщить модератору

17. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" –2 +/–

Сообщение от Kodir (?), 08-Ноя-10, 23:19

Какова бы ни была скорость, ставку надо делать на ИЗНАЧАЛЬНО ПРОДУМАННЫЙ llvm. Впоследствии все гццшные трюки можно точно так же перенести в clang, так что проблем со скоростью не будет.
Надо уметь отметать старое, пока старое как снежный ком не смяло вас самих (см. историю Линукс).

Ответить | Правка | Наверх | Cообщить модератору

24. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +1 +/–

Сообщение от ананим (?), 09-Ноя-10, 01:52

вот-вот! даёшь релиз gcc 4.6!

Ответить | Правка | Наверх | Cообщить модератору

28. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от Аноним (-), 09-Ноя-10, 09:30

не нашел какие были оптимизации
А в реальности надо просто убрать С/С++ (с его инклудами и разделением на заголовок и реализацию) и заменить на более быстрый для компиляции язык более подверженный оптимизации.

Ответить | Правка | Наверх | Cообщить модератору

29. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от Аноним (-), 09-Ноя-10, 09:40

дополнение. И переписать на новый язык Фришку и Линукс

Ответить | Правка | Наверх | Cообщить модератору

30. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от cdome (ok), 09-Ноя-10, 10:34

Люди!
Кто пользуеться LLVM, скажите как у него с поддержкой Windows?

Ответить | Правка | Наверх | Cообщить модератору

32. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от Аноним (-), 09-Ноя-10, 14:37

o_O
а у GCC как с поддержкой виндоус? Только не надо всякие cygwin, mingw и т.д.

Ответить | Правка | Наверх | Cообщить модератору

50. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang" +/–

Сообщение от анонимус (??), 17-Фев-23, 19:34

Чем mingw не угодил? Всяк уж получше MSVC по качеству компиляции.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	+3 +/–
Сообщение от Аноним (1), 08-Ноя-10, 17:48
Бессмысленный тест. Тут главное не скорость компиляции, а качество полученного кода и качество поддержки спецификаций языка. Лучше бы они попробовали этими компиляторами собрать скажем debian репозиторий и написали сколько пакетов завалилось.
Ответить \| Правка \| Наверх \| Cообщить модератору


	3. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	+4 +/–
	Сообщение от pavlinux (ok), 08-Ноя-10, 17:56
	Читаем снова: >хотя собранный в GCC код как правило продемонстрировал немного более высокую скорость > работы. Значительный провал в производительности Clang и LLVM-GCC наблюдался в тестах > John The Ripper Blowfish (отставание 40%), HMMer (10-18%), GraphicsMagick (20-50%). > В тесте C-Ray Clang и LLVM-GCC оказались быстрее GCC на 10-20%.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	+/–
	Сообщение от Аноним (1), 08-Ноя-10, 18:32
	Читаем снова: >качество поддержки спецификаций языка. >Лучше бы они попробовали этими компиляторами собрать скажем debian репозиторий и написали сколько пакетов завалилось.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	+1 +/–
	Сообщение от simpler (?), 08-Ноя-10, 19:51
	Да уж. Лишнее подтверждение тому, что большинство потребителей сделанного кем-то для них ПО ни о чем кроме скорости думать не могут. И даже когда прочитают, просто ничего друго не воспринимают. И не могут себе представить, как можно о чем-то, кроме скорости, думать.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	10. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	–3 +/–
	Сообщение от User294 (ok), 08-Ноя-10, 21:51
	Да, давайте подумаем еще о чем-нибудь. Например, о том что некоторые тесты вообще шлангом не собрались (точнее, если уж не собирается то как правило всеми LLVM-based сразу). О чем в новости почему-то стыдливенько заскипано. Среди не скомпилившихся шлангом тестов кроме всего прочего был и x264, например. Очень уж это все напоминает "зато мы делаем ракеты и перекрыли Енисей" в свете недавних трублений про сборку ядра линуха :). Ради справедливости замечу что девеловской веткой гцц x264 тоже не собрался, но там хотя-бы честно указано что оно девел ;) Также как-то стыдливо заскипан аццкий слив, местами почти в три (!!!) раза в графикc магике. Интересно, как получается "20-50% отставание" при 53 попугаях максимум у LLVM-based vs 138 попугаев у GCC? Ну ладно, пусть 131 попугае - для последней релизной версии гцц. Ну-ка расскажите, математики, это как? Автору новости 2 балла - за неумение пользоваться калькулятором, или того хуже "гетзефаксы".
	Ответить \| Правка \| Наверх \| Cообщить модератору


	12. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	+/–
	Сообщение от cdome (ok), 08-Ноя-10, 22:10
	Ну со сливом в ImageMagic то же понятно. LLVM до сих пор не поддерживает OpenMP, который во всю использует ImageMagic
	Ответить \| Правка \| Наверх \| Cообщить модератору


	13. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	+3 +/–
	Сообщение от cdome (ok), 08-Ноя-10, 22:19
	Единственное, что привлекло мое внимание в этом тесте, так это Himeno Benchmark. Когда на интеле gcc и clang идут практически вровень, но на AMD Opteron - clang в два раза быстрее gcc и вообще быстрее core i7. Не происки ли это инженеров интела, которые сейчас занимаются gcc в плотную. Надо попробывать повторить и зафайлить баг репорт в gcc.
	Ответить \| Правка \| К родителю #10 \| Наверх \| Cообщить модератору


	14. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	+/–
	Сообщение от simpler (?), 08-Ноя-10, 22:31
	> Да, давайте подумаем еще о чем-нибудь. Ну хотя бы уже что-то. > Например, о том что некоторые тесты вообще шлангом не собрались (точнее, если уж не собирается то как правило всеми LLVM-based сразу). Т.е. вы хотите, чтобы clang сразу моментально был похож на gcc один в один. Не смотря на общую динамику развития. Просто разработчики сосредоточились на выявлении конкретных несовместимостей при сборке конкретного ПО. А не просто на тестах ради тестов. Кроме того, те фичи, допустим в Линукс-ядре, которые собираются ценой уродства архитектуры gcc - можно выкинуть из самого (например) Линукса, а не пытаться портить новый компилятор ради поддержки дурных решений. Просто многоие поклонники этих gcc-ориентированных убогостей из-за шаблонности своего мышления не догадываются, что у разработчиков компиляторов всегда есть такой ход, как не поддерживать те фичи, которые им не нравятся. Что неминуемо повлечет за собой переделку самого софта, который подобные угробищные фичи поддерживает. А вовсе не допиливания самого компилятора в целях соответствия какому-то очередному убожетсву.
	Ответить \| Правка \| К родителю #10 \| Наверх \| Cообщить модератору


	15. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	+/–
	Сообщение от ананим (?), 08-Ноя-10, 22:55
	>Кроме того, те фичи, допустим в Линукс-ядре, которые собираются ценой уродства архитектуры gcc - можно выкинуть из самого (например) Линукса, а не пытаться портить новый компилятор ради поддержки дурных решений. опа. тонкий намёк на "правьте свой линух под шланг". а оно кому нужно то?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	+2 +/–
	Сообщение от simpler (?), 08-Ноя-10, 23:22
	> опа. тонкий намёк на "правьте свой линух под шланг". То есть вы только сейчас поняли, что такой вариант возможен (и даже более вероятен). > а оно кому нужно то? Тем, кому нужно, те и будут делать. Большая часть Линукса уже собирается под clang. Скоро начнут появляться дистрибутивы Линукса, полностью собранные clang, в которых просто не будет угробищных фич, которые clang'ом не собираются. Для этих фич просто будут делать замены. Кроме того, те оси, ядра которых легче собираются под clang получат дополнительное преимущество над Linux, а не наоборот. Вы то ждали, что разработчики clang будут гоняться за gcc в стремлении собрать весь Линукс до последней строчки исходного кода. А окажется, что это Линуксу придется гоняться за совместимостью с другими компиляторами. Вы то думали, что это будет проблемой clang и llvm, что они что-то не собирают. А оказывается это будет проблемой того софта, который не собирается под clang. Другой вопрос, что это все повлечет за собой очередную волну изменений, и появятся новые возможности для выбора. А кое-кому очень трудно переучиваться. А ввиду того, что они обычно выбирают, глядя на общественное мнение и на "скорость", и не способны анализировать архитектуру ПО, большая часть привязанностей таких вот потребителей состоит именно из подобных угробищных фич.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	21. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	+/–
	Сообщение от ананим (?), 09-Ноя-10, 01:27
	>То есть вы только сейчас поняли, что такой вариант возможен (и даже более вероятен). неа. не понял. :D >Тем, кому нужно, те и будут делать. >Большая часть Линукса уже собирается под clang. вот когда весь будет собираться, тогда смело напишем - собирается шлангом. мы молодцы.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	22. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	+/–
	Сообщение от ананим (?), 09-Ноя-10, 01:30
	зы: >Кроме того, те оси, ядра которых легче собираются под clang получат дополнительное преимущество над Linux, а не наоборот. >Вы то ждали, что разработчики clang будут гоняться за gcc в стремлении собрать весь Линукс до последней строчки исходного кода. А окажется, что это Линуксу придется гоняться за совместимостью с другими компиляторами. во фантазёр! прям аш зависть берёт! :D всё! завтра сношу линух и ставлю "оси, ядра которых легче собираются под clang".
	Ответить \| Правка \| Наверх \| Cообщить модератору


	39. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	+/–
	Сообщение от анонимус (??), 09-Ноя-10, 21:06
	Вообще, правильные вещи говорит человек. Нефига писать непереносимый код. Левые фишки не нужны.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	41. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	+/–
	Сообщение от simpler (?), 09-Ноя-10, 22:52
	> Вообще, правильные вещи говорит человек. Нефига писать непереносимый код. Левые фишки не нужны. Я вообще-то как раз переносинмость саму по себе в виду не имел. Поскольку переносимость ради переносимости "серебряной пулей" не является. Я говорил о том, что у gcc очень долго не было альтернатив в мире свободного софта. И теперь появилась качественная альтернатива. А также о том, что поскольку бОльшая часть ядра Линукса уже собирается под clang, в скором времени стоит ожидать появление дистрибутивов, основанных на llvm. Не говоря уже о FreeBSD. А те куски, которые под clang не собираются никто не мешает заменить. Причем вовсе не обязательно _переносимым_ образом. И скорее всего так оно и будет. Один раз кто-то начнет - потом уже не остановишь. И еще о том, что судя по всему, разработчики clang не пытаются подгонять новый компилятор под все существующие стандарты и под все проекты с сомнительным качеством кода. В чем я их и поддерживаю. Я считаю, что важнее свобода выбора, чем абстрактная переносимость. И это совсем разные вещи. Важнее качественные языки и инструменты программирования, чем нереализованные или плохо реализованные стандарты на прораммирование. Никто не запрещает делать форки вместо переносимости. Хотя многих это и раздражает, тех кто хочет, чтобы у всех все было одинаково.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	43. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	+/–
	Сообщение от pavel_simple (ok), 09-Ноя-10, 23:20
	> А также о том, что поскольку бОльшая часть ядра Линукса уже собирается > под clang, ты считал? в каком месте бОльшая?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	44. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	+/–
	Сообщение от simpler (?), 09-Ноя-10, 23:51
	> ты считал? > в каком месте бОльшая? http://www.opennet.ru/opennews/art.shtml?num=28418 Я не считал. Может даже и не бОльшая, если тупо считать по количеству строк кода. А может и действительно бОльшая, судя по тексту - не принципиально. В любом случае - самодостаточная часть. Достигнуто состояние self-hosting. Это означает, что в скором времени следует ожидать появление основанных на clang дистрибутивов. Дистрибутивов, где clang будет основным компилятором. Как бы это некоторых не раздражало.
	Ответить \| Правка \| К родителю #43 \| Наверх \| Cообщить модератору


	45. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	–1 +/–
	Сообщение от pavel_simple (ok), 10-Ноя-10, 16:18
	> Я не считал. так и запишем -- фантазёр
	Ответить \| Правка \| К родителю #44 \| Наверх \| Cообщить модератору


	46. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	+/–
	Сообщение от simpler (?), 11-Ноя-10, 03:38
	> так и запишем -- фантазёр Так и запишем - для вас важнее количество строк кода и показатели скорости, нежели качественный результат. То, что ядро Linux собирается си-лангом - это уже подтвержденный факт, а вы все никак в это поверить не можете.
	Ответить \| Правка \| К родителю #45 \| Наверх \| Cообщить модератору


	47. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	+/–
	Сообщение от pavel_simple (ok), 11-Ноя-10, 07:05
	>> так и запишем -- фантазёр > Так и запишем - для вас важнее количество строк кода и показатели > скорости, нежели качественный результат. > То, что ядро Linux собирается си-лангом - это уже подтвержденный факт, а > вы все никак в это поверить не можете. для меня важно -- чтобы всякие мимопролетающие трололо сливали за пизд^Wничем не прикрытое враньё -- пошло уже
	Ответить \| Правка \| К родителю #46 \| Наверх \| Cообщить модератору


	48. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	+/–
	Сообщение от simpler (?), 11-Ноя-10, 10:41
	Ну конечно. По-вашему получается, что содержимое всех новостей о си-ланге - тоже вранье. Или вообще по-вашему си-ланга не существует, это лишь "фантазия". Да продолжайте пользоваться gcc. Кто-то запрещает что-ли. Что так волноваться-то из-за того, что у других появится возможность им не пользоваться.
	Ответить \| Правка \| К родителю #47 \| Наверх \| Cообщить модератору


	26. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	+1 +/–
	Сообщение от Аноним (1), 09-Ноя-10, 04:48
	>уродства архитектуры gcc >gcc-ориентированных убогостей >подобные угробищные фичи поддерживает. >соответствия какому-то очередному убожетсву. Вы так обоснованно аргументируете свою позицию, что нам, адекватным людям, даже возразить нечего.
	Ответить \| Правка \| К родителю #14 \| Наверх \| Cообщить модератору


	27. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	+1 +/–
	Сообщение от simpler (?), 09-Ноя-10, 05:17
	> Вы так обоснованно аргументируете свою позицию, что нам, адекватным людям, даже возразить нечего. То, что вам нечего возразить - это понятно. Собственную адекватность вы считаете при этом само собой разумеющимся фактом, не требующим аргументации. Что же касается моей позиции, то я ее особо обосновывать не старался - я ее просто высказал. Обоснование - это процесс скрупулезный. И если вы ищите обоснований на форумах по обсуждению новостей, то видимо вы плохо представляете себе, что же такое обоснования. Суть же моей позиции очень проста. Если разработан компилятор с более качественной модульной архитектурой, то его не будут подгонять под какой попало код, лишь бы отчитаться, что он может компилировать что угодно. И даже без моего старания это обосновать, вам, как это видно, возразить нечего.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	34. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	–1 +/–
	Сообщение от Unforgiven (??), 09-Ноя-10, 14:43
	> Собственную адекватность вы считаете при этом само собой разумеющимся фактом, не требующим аргументации. Человек адекватен, если не доказано обратное. Своим постом вы доказали свою неадекватность и этого достаточно. > Если разработан компилятор с более качественной модульной архитектурой, то его не будут подгонять под какой попало код, лишь бы отчитаться, что он может компилировать что угодно. И часто мсье занимался разработкой компиляторов? Судя по постам - даже не пользовался. > И даже без моего старания это обосновать, вам, как это видно, возразить нечего. А вы будете возражать лающей собаке?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	36. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	+/–
	Сообщение от simpler (?), 09-Ноя-10, 16:40
	Тем, кому в свое время с большим трудом удалось чему-то с грехом пополам научиться, но при этом уже не дано изучить что-то новое - только и остается утешать себя подобным образом. Рассуждая о сферической адекватности в вакууме. Ну и еще о скорости. Больше им не о чем говорить.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	31. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	–3 +/–
	Сообщение от User294 (ok), 09-Ноя-10, 14:27
	> Т.е. вы хотите, чтобы clang сразу моментально был похож на gcc один в один. Ну, вообще, я почему-то нескромно считаю что если проводится бенчмарк - было бы хорошо если бы участники оного не фэйлили тесты для начала. На GCC тоже можно в принципе понаезжать за это, но меньше и в основном на девел версию. > Не смотря на общую динамику развития. Динамика - это хорошо. Кто б спорил. Вот только учтя что почти все разработчики в эппле - вопрос в том в чью пользу эта динамика будет. > Просто разработчики сосредоточились на выявлении конкретных несовместимостей при сборке > конкретного ПО. А не просто на тестах ради тестов. Ну, в моем понимании, компилер претендующий на полноценность все-таки должен осиливать сборку софта типа x264. > Кроме того, те фичи, допустим в Линукс-ядре, которые собираются ценой уродства > архитектуры gcc - можно выкинуть из самого (например) Линукса, а не пытаться > портить новый компилятор ради поддержки дурных решений. Нет, безусловно, идеальный мир - это хорошо. Вот только понятия о "дурных решениях" может и не совпадать у разных индивидуалов. Это вас не смущает? :) И, собссно, а что убедит ядерщиков проделать этот объем работ? Заява каких-то конкретных индивидуалов "%s - дурное решение" имхо вообше не котируется, как минимум без хорошего технического обоснования. > Просто многоие поклонники этих gcc-ориентированных убогостей А на основании чего - "убогостей"? То что для вас - убогости, для других может быть и рулезом. А истина - как обычно где-то посередине. > из-за шаблонности своего мышления не догадываются, что у разработчиков > компиляторов всегда есть такой ход, как не поддерживать те фичи, которые им не нравятся. А знаете, у разработчиков софта есть такой ход как потребовать пререквизиты для сборки. И можно указать среди них конкретный компилер с конкретными фичами, например, если разработчики других компилеров не хотят идти навстречу и реализовывать фичи а эти фичи используются. И, кстати, оснований у разработчиков ядра потребовать фичи от компилера - ровно столько же сколько у разработчиков компилера на это положить с прибором :). Можно, конечно, понаезжать что это портит портабельность. Но гцц есть под все платформы под которые есть LLVM и еще под кучу, под которые LLVM еще и в проекте нет. Так что наезд не очень то и сильный. Да и все другие мало-мальски крупные ядра компилятся 1-2 компилерами без больших плясок с бубнами, так что опять же. Можно конечно по этому поводу заявить что "все пи..сы!", но на этот счет есть довольно жизненный анекдот. > Что неминуемо повлечет за собой переделку самого софта, И что же НЕМИНУЕМО сподвигнет разработчиков? Нож? Или пистолет? oO > который подобные угробищные фичи поддерживает. Опять же - понятия о прекрасном у всех разные. Как-то за всех решать что для них угробищно а что нет - некультурно, знаете ли. Готов поспорить что разработчики сами выберут для себя - что угробищно, а что - нет. Можете попробовать обосновать почему те или иные фичи угробищны, однако врядли кого-то убедят сами по себе вопли "%s - угробище!". Если кто-то поюзал фичу - очевидно, он не считал ее угробищной. > А вовсе не допиливания самого компилятора в целях соответствия какому-то очередному > убожетсву. Ну, если считается что линуксное ядро - убожество, недостойное нормально компилиться Единственно Правильным Компилером (тм), то что же тогда сподвигнет разработчиков этого ядра шевелиться насчет поддержки этого компилера? Как-то ну совсем нелогично, вы не находите? oO
	Ответить \| Правка \| К родителю #14 \| Наверх \| Cообщить модератору


	35. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	+/–
	Сообщение от simpler (?), 09-Ноя-10, 16:27
	> Ну, в моем понимании, компилер претендующий на полноценность все-таки должен осиливать сборку софта типа x264. А в моем понимании в подобных вопросах надо смотреть на качество конкретного кода, а не на названия брендов. > Вот только понятия о "дурных решениях" может и не совпадать у разных индивидуалов. > А на основании чего - "убогостей"? То что для вас - убогости, для других может быть и рулезом. А истина - как обычно где-то посередине. > Опять же - понятия о прекрасном у всех разные. Я уже сказал выше, что я высказал свое личное мнение. Кому нравятся фичи от gcc, и код на них основанный, могут продолжать им пользоваться, gcc ведь никто не закрывал. Просто некоторых очень беспокоит, что появились возможности не пользоваться gcc, и этих возможностей становится все больше и больше в самых разных проектах. > Ну, если считается что линуксное ядро - убожество, недостойное нормально компилиться Единственно Правильным Компилером (тм), то что же тогда сподвигнет разработчиков этого ядра шевелиться насчет поддержки этого компилера? Как-то ну совсем нелогично, вы не находите? oO Я вообще-то говорил об отдельных частях Линукс-ядра, а не об ядре в целом. Или для вас часть эквивалентна целому? Либо все, либо ничего? Как-то ну совсем нелогично, вы не находите? oO Ведь бо'льшая часть Линукс-ядра ведь уже собирается с помощью clang. Вот еще бо'льшую часть кода binutils и coreutils соберут (а во FreeBSD их аналоги уже собрали). И ничто не помешает создавать дистрибутивы Линукса, полностью основанные на clang. А те исключения кода (кода, а не проекты целиком), что не соберутся - анализируются, почему не собрались. И что лучше в каждом конкретном случае - добавлять в clang какую-то сомнительную фичу, или просто заменить фичу в конкретном проекте. Взять хотя бы SELinux. Система громоздкая и неуклюжая. Еще польшой вопрос, стоит ли беспокоиться о ее поддержке новым компилятором. С другой стороны сам Linux все-таки постепенно допиливают до модульной поддержки систем безопасности. Так что, глядя на новый модульный компилятор, у разработчиков Линукса будет лишний повод задуматься об архитектуре ядра. > И что же НЕМИНУЕМО сподвигнет разработчиков? Нож? Или пистолет? oO Общие тенденции в сторону повышения модульности и гибкости при проектировании. Хотя конечно для многих ввиду шаблонности и монолитности их мышления - это равносильно ножу или пистолету.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	40. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	–4 +/–
	Сообщение от User294 (ok), 09-Ноя-10, 22:45
	> А в моем понимании в подобных вопросах надо смотреть на качество конкретного > кода, а не на названия брендов. А четкие критерии качества - можно в студию? Кстати да, для кодека требование вида "строгий ANSI C" - не обязательно катят. Если вам кодек H.264 на строгом анси цэ написать, без асмовых кусков (которые по определению не описаны в стандартах на си) - вы же и будете рыдать от производительности такого кодека. > Я уже сказал выше, что я высказал свое личное мнение. > Кому нравятся фичи от gcc, и код на них основанный, могут продолжать > им пользоваться, gcc ведь никто не закрывал. Отлично. Но вы даже не обругали нормально фичи. Более того - вы как-то упустили моменты что бывают нужные фичи которые по определению специфичны для компилера/набора тулсов, но тем не менее нужны. Например, как-то так уж вышло что стандарты не определяют например как делать в сишную программу асмовые вставки. И еще немало моментов. > Просто некоторых очень беспокоит, что появились возможности не пользоваться gcc, и этих > возможностей становится все больше и больше в самых разных проектах. Я вижу даже некий плюс - GCC явно не помешает пинок для ускорения развития :-). > Я вообще-то говорил об отдельных частях Линукс-ядра, а не об ядре в целом. Ну, кому надо - может ипстись с выборкой из ядра "неправильных" кусков. Мне не жалко. А у меня и более интересные дела есть. Подозреваю что у аффтаров майнлайнового ядра - тоже. > Или для вас часть эквивалентна целому? Либо все, либо ничего? Ядро поставляется как некий продукт. Дальше я выбираю какие его субкомпоненты мне нужны. И мне как-то ну совсем не прикольно выкидывать компоненты не потому что "так лучше" и "это хорошо для решения задачи", а потому что ... "компилер не может это сжевать". А зачем мне геморрой на ровном месте? oO > Как-то ну совсем нелогично, вы не находите? oO Нет, я не нахожу. Если мне приспичило пересобрать ядро - то по каким-то веским причинам, к которым расовая (не)верность компилеров ни разу не относится. Благо, я ни разу в жизни не ощущал на своем заду никаких ограничений от гцц, даже собирая им нахрен проприетарную фирмварину защищенную от чтения, что вполне допустимо его лицензией. А возможность всяких там япплов зажопить код инструментария и устроить всем при случае кидок а-ля дарвинское ядро меня как-то интересует вообще в последнюю очередь. Я просто в меру возможностей не буду закладываться на тулзы которые зависят от 1 коммерческой конторы - нафиг-нафиг лишние риски. Вон жабисты уже на своем заду ощущают последствия такой практики :-). > Ведь бо'льшая часть Линукс-ядра ведь уже собирается с помощью clang. Есть такая весьма правдивая байка, которая гласит что 80% работы обычно делается за 20% времени. Весь компот портят остальные 20%, на выполнение которых уходит оставшиеся 80% времени :) > Вот еще бо'льшую часть кода binutils и coreutils соберут (а во FreeBSD > их аналоги уже собрали). Шланг с бинутилсами? Это видимо из разряда "без порток, а в шляпе". Благо бинутилсы тоже под расово-неверной лицензией, вызывающией батхерт у бсдшников и эппла. :) > И ничто не помешает создавать дистрибутивы Линукса, полностью основанные на clang. Как бы флаг в руки тем кому это надо. Будет любопытно посмотреть на то что получится. > А те исключения кода (кода, а не проекты целиком), что не соберутся > - анализируются, почему не собрались. И что лучше в каждом конкретном > случае - добавлять в clang какую-то сомнительную фичу, или просто заменить > фичу в конкретном проекте. Ну, как бы, вы не можете диктовать всем авторам проектов что им и как делать и за них решать - нужна им та или иная фича. ИМХО, с практической точки зрения - допилить 1 компилер явно проще чем сотни тысяч программ по всему миру. > Взять хотя бы SELinux. Система громоздкая и неуклюжая. Еще польшой вопрос, стоит > ли беспокоиться о ее поддержке новым компилятором. Мне он не нравится. Как раз этим самым. Мне проще сделать сравнимую изоляцию и паранойю совершенно иными методами. Однако редхатчики и федористы вас имхо не поймут. Кроме того, серьезные (гос)конторы и т.п. имеют как правило вполне конкретный регламент работы с секретными документами, где четко прописаны все процедуры. Регламент большинства таких контор - явно требует обязательное наличие системы мандатного контроля доступа (как минимум, у нас и в сша оно АФАЙК вот так, да и другие наверное не сильно отличаются). Без реализации системы мандатного контроля доступа ваша система просто-напросто никогда не попадет в такие конторы, не пройдя сертификацию. А это как ни крути - один из рубежей признания системы "взрослой". Это, конечно, формальности, однако ж появились они в таких конторах не просто так для красоты. > С другой стороны сам Linux все-таки постепенно допиливают до модульной поддержки систем > безопасности. Так что, глядя на новый модульный компилятор, у разработчиков Линукса > будет лишний повод задуматься об архитектуре ядра. У меня почему-то такое ощущение что они не будут сильно дергаться ради поддержки какого-то (довольно сырого) компилера неизвестно ради чего. В мире как бы много разных компилеров. На все все-равно не надергаешься. Например, есть ICC. Некоторые джедаи им даже что-то собирают. Однако врядли кого в майнлайне интересует объем потребных для этого плясок. Особенно когда интель сам в гцц впихивает патчи для улучшения поддержки своих процов т.к. ему это тоже стало надо :) >> И что же НЕМИНУЕМО сподвигнет разработчиков? Нож? Или пистолет? oO > Общие тенденции в сторону повышения модульности и гибкости при проектировании. А в каком месте упомянутые факторы гарантируют какую-то там неминуемость чего либо? И откуда это следует? > равносильно ножу или пистолету. Только для школоло, бегающих за тенденциями и модой.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	42. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	+/–
	Сообщение от simpler (?), 09-Ноя-10, 23:12
	Сюдя по всему, вы все-таки осознали реальность того, что под clang начнут собирать самодостаточные комплекты ПО, всключая ядра ОСей, гораздо раньше, чем на нем пересоберут весь существующий в Мире код. И что многие проекты сомнительного качества просто не станут поддерживать. Так и оставят, чтобы их авторы сами думали, осваивать им новый компилятор или нет. Просто вы до этого о такой возможности даже не подозревали. И думали, что единственным путем развития для нового компилятора (кроме еще гонки за скоростью), будет пересборка всего кода, доставшегося ему в наследство от старого. Потому что "скорость" и "пересборка всего кода" - это наиболее доступные для потребительского понимания темы. А тут вдруг неожиданно видите, сколько вариантов может еще оказаться. Вот до чего стереотипы доводят. И просто придумываете всякие отмазки для самоутешения.
	Ответить \| Правка \| Наверх \| Cообщить модератору

2. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	+/–
Сообщение от Иван Иванович Иванов (?), 08-Ноя-10, 17:50
GCC 4.6.x заруливает - Intel'ы не зря старались.
Ответить \| Правка \| Наверх \| Cообщить модератору

4. "Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang"	+2 +/–
Сообщение от Аноним (-), 08-Ноя-10, 18:04
>7-Zip, LAME MP3, x264 >расхождения в показателях были незначительны Может я заблуждаюсь, но там чёртова куча ассемблерных вставок, так что мерить на них компилятор С как-то глупо, ИМХО.
Ответить \| Правка \| Наверх \| Cообщить модератору