Статус готовности CLang к сборке ядра Linux

>на самом деле clang + llvm имеют свои плюшки

Почему ни один фанатик до сих пор не сказал, что же за мифически плюшки оно имеет?

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

> Почему ни один фанатик до сих пор не сказал, что же за мифически плюшки оно имеет?

я хоть и не фанатик, но:

- статический анализ кода;
- скорость компиляции быстрее раза в два;
- вменяемые сообщения об ошибках;
- JIT;

и пр.

> Почему ни один фанатик до сих пор не сказал, что же за мифически плюшки оно имеет?

Откуда столько дебилов, не умеющих читать?

У gcc множество архитектурных недостатков:

- Слишком много промежуточных представлений. В llvm же только один уровень.

- Отсутствие единообразного метода для написания преобразований

- Не разделяется код между языковыми frontend-ами

- Много древнего кода, который уже давно никто не понимает

- Написано на Си, с множеством костылей

- Платформозависимые части размазаны по всем уровням

В clang и llvm все эти недостатки отсутствуют. Очень четкое разделение по уровням абстракции. Легко добавляются произвольные преобразования между этими уровнями. Как результат - есть довольно мощный и легкоуправляемый статистический анализатор кода. Есть полноценная, работающая link time optimization (то убожество, что есть в gcc, еще лет 5 допиливать до рабочего состояния будут). Clang и llvm очень маленькие и понятные, один разработчик легко может добавить новую функциональность, не тратя годы на разборки с нагромождениями древнего хлама.

А вы, придурки, все про лицензии бухтите. Не важно это. Важны только технические характеристики.

>Очень четкое разделение по уровням абстракции. Легко добавляются произвольные преобразования между этими уровнями. Как результат - есть довольно мощный и легкоуправляемый статистический анализатор кода. Есть полноценная, работающая link time optimization (то убожество, что есть в gcc, еще лет 5 допиливать до рабочего состояния будут).

Ну оочень неочевидные «преимущества». Тем более, они все нивелируются, если вспомнить, что Clang в сравнении с GCC ничего не умеет.

ничего не умеет из gcc-измов?

> Ну оочень неочевидные «преимущества»

LTO - это «неочевидное преимущество»? Что тогда преимущество, по твоему? Ты вообще хоть что-либо в компиляторах понимаешь, чтобы нести такую чушь? Много своего кода в gcc и в clang закоммитил?

Ну оочень неочевидные «преимущества»

И чего он такого нужного не умеет? Fortran77?

наоборот, это GCC не умеет, например, блоки http://en.wikipedia.org/wiki/Blocks_(C_language_extension)
ну их можно до какой-то степени эмулировать вложенными функциями, но блоки — это почти полноценные замыкания, в отличие от.

>Blocks are a nonstandard extension added by Apple Inc.

Что-то ещё?

Не разработчик вообще, поэтому всё это(в том числе и педантичная поддержка стандартов) мне до лампочки, в отличие от скорости и работоспособности скомпилированного кода.

> Что-то ещё?

Дадада, нестандартные расширения от gcc все конечно же полезные и нужные, а если от Apple, то сразу нунах?

Ты давай, сначала за LTO, static analysis и code completion отчитайся, ламерье ущербное.

> Не разработчик вообще,

А по какому праву тогда вообще хлебало раззявил и вякаешь? Компилятор - инструмент для разработчиков. Разработчикам и обсуждать, какой компилятор выбрать. Юзерам же - молчать в тряпочку.

поэтому всё это(в том числе и педантичная поддержка стандартов) мне до лампочки, в отличие от скорости и работоспособности скомпилированного кода.

А скорость и качество кода как раз от качества отпимизаций и анализа и зависит.

тебе привести список всех нестандартных расширений в GCC, или сам найдёшь?
в чём поинт использования каждого такого расширения, например, в ядре Linux?
если можно писать на plain C99 как те же BSD?
в чём поинт такого сравнения вообще, меряемся у кого список нестандартных расширений толще?
или нужен список того, что «просто работает»?

У тебя бугурт, уйди.

А скорость и качество кода как раз от качества отпимизаций и анализа и зависит.

Только вот почему-то так всё выглядит только в теории, а на практике старый, жирный и непонятный GCC по производительности скомпилированного кода уделывает все остальные opensource-компиляторы.

> У тебя бугурт, уйди.

Продолжаешь тявкать, животное? Усохни.

Только вот почему-то так всё выглядит только в теории, а на практике старый, жирный и непонятный GCC по производительности скомпилированного кода уделывает все остальные opensource-компиляторы.

На практике, с LTO у clang+llvm бинарники получаются иногда в два раза меньше, чем у gcc. А для всяких embedded и mobile устройств это весьма важно.

Да и что ты такое, чтобы вякать про «практику», а, не-разработчик? Ты ж тупой и не знаешь вообще ни черта.

И еще, придурок. Догадайся, почему разработчики под Mac OS X предпочитают пользоваться clang при отладке, и только release собирают gcc.

> в отличие от скорости и работоспособности скомпилированного кода.

ты будешь смеяться, но на похорониксе (можно уже сразу /0) интересная статья вышла. Про сравнение тёплого с мягким. На форумах. В общем, человек поставил себе С компиляторы pcc, tcc, open64, gcc, llvm (clang), icc. И устроил бенчмарк, ггг, скомпилированного кода. Жаль, в openwatcom поддержки x86_64 нет и не предвидится (хотя я собрал x86 компилятор на x86_64 линуксе, там не очень сложно) — тоже было бы полезно сравнить (только вот найти такой тест, который openwatcom собирает).
Похороникс тут хорош тем, что у них есть openbenchmarking.org, как раз про сравнение тёплого с мягким. Можно скачать phoronix-test-suite, запустить у себя, потом в настройках указать профиль на openbenchmarking.org, он сам закачает на сайт. Можно набигать на сайт и сравнивать результаты, отбирая других тестеров с похожим железом.

В общем, результаты тестов весёлые у него получились — tcc и pcc вообще без оптимизаций всех зарулили. Не по скорости конпеляции, а по скорости сконпелированного кода. Если добавлять оптимизации, картина немного меняется. Но осложняется тем, что для каждого отдельного конпелятора нужно подбирать свой набор флагов оптимизации.

В итоге, чёго он там своим тестом мерил — никто так и не понял. Хорошая иллюстрация про сравнение яблоков с апельсинами. Опять же, разница в производительности кода сферического бенчмарка, собранного pcc/tcc/gcc не столь велика, как казалось, если уж код вообще собрался из-за отсутствия gcc-измов и различий в понимании того же С++ (поэтому сравнения С компиляторов адекватнее).

http://phoronix.com/forums/showthread.php?29090-CompilerDeathMatch-surprising...

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

Недоумок, да кого колышет производительность?

Clang нужен разработчикам. Чтобы проще было ядро, блин, разрабатывать. Компили его потом чем хочешь, придурок.

> Clang в любом случае проигрывает в производительности

/0
странно у тебя понималка работает.

Он не может собрать ядро -> разработка невозможна -> он не нужен. И да, производительность волнует всех, кроме тебя. А теперь уйди.

Ну оно же тут уже призналось, что «вообще не разработчик». Добавь к этому тот факт, что оно все же осмелилось всунуться в дискуссию о компиляторах, и получишь адекватное представление об интеллектуальном уровен этого убожества.

> Он не может собрать ядро -> разработка невозможна -> он не нужен.

Да, пациент однозначно невменяемый.

Оно может собрать ядро. В достаточном для как минимум статического анализа объеме. А уж про всякий там code completion и говорить нечего, все хедеры парсятся отлично.

И да, производительность волнует всех, кроме тебя.

Ты тупой. Производительность release build - да, всех волнует. А вот производительность заинструментированного по самые гланды отладочного build-а не колышет вообще никого.

А теперь уйди.

Что-то сявка совсем развякалась. Даже не осознаешь, чмо, насколько ты себя уже опозорило.

Просто у поциента гента (головного моска).

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

Тогда просто покажи, в каком месте Clang ориентирован на разработчиков, в их роадмапе во главу угла поставлены end-user features.

> в каком месте Clang ориентирован на разработчиков

посмотри как просто прикрутили clang к vim, а теперь посмотри на потуги навроде gcc-xml, которые так и закончились ничем

> Тогда просто покажи, в каком месте Clang ориентирован на разработчиков, в их роадмапе во главу угла поставлены end-user features.

Ну ты баран. Для компилятора разработчики - это и есть end users.

В clang есть static code analysis, в gcc его нет. Эта фича разработчикам совершенно необходима.

В clang намного более вменяемые сообщения об ошибках, что облегчает жизнь разработчикам.

С llvm намного проще делать произвольное инструментирование кода - это абсолютно необходимо для разработчиков (и разработчиков ядра в особенности).

Clang элементарно интегрируется с IDE - а gcc не интегрируется никак.

Мало тебе этого, не-разработчик?

>Для компилятора разработчики - это и есть end users.

End-User Features:

* Fast compiles and low memory use

* Expressive diagnostics (examples)

* GCC compatibility

Да ну? Впрочем, предыдущий чуть менее хамоватый анонимус к месту дал ссылку на коллекцию пхорониксовских тестов, там у Clang'а почти везде неплохой выигрыш в работе с аудио и видео, надо будет попробовать.

Да-да, дурень, конечно же expressive diagnostics - это не для разработчика, а для пользователя скомпилированного clang-ом бинарника. Скорость компиляции тоже очень нужна конечно же пользователям бинарника, а не разработчикам, ага.

Ну признай наконец, что ты совершенно тупой, и запомни на будущее, что прежде чем влезать со своим очень-ценным-мнением надо сначала подумать, а имеешь ли ты на это самое мнение какое либо право.

> посмотри на потуги навроде gcc-xml, которые так и закончились ничем

Ты просто не в теме. gcc-xml стал полезным инструментом.

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

> Ты просто не в теме. gcc-xml стал полезным инструментом.

конечно не в теме, конечно стал, а то что он «мертв» - это дело такое, со всеми полезными инструментами бывает

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

Я, если ты не заметил, аноним. Так что уж поверь на слово - коммиты мои есть и в gcc (начиная еще с egcs, если помнишь, что это такое), и в llvm, и в clang. Правда, не ясно, какое это имеет отношение к обсуждаемой теме - ты ты тут херню несешь вполне себе прямым текстом, легко проверяемую. Никаких внешних пруфлинков не надо - ты тупой хотя бы просто по результатам этой дискуссии.

И, эцсамое, ты про низкое потребление памяти забыл, которое так важно разработчикам.

Естественно это важно разработчикам. Не забывай, что clang - модульный компилятор. Его часто встраивают в другие приложения (да в те же IDE, хотя бы), и конечно же разработчикам важно, чтобы он жрал поменьше памяти. Я уж молчу про всякую экзотику вроде реализаций OpenCL на основе clang (а все, кроме nvidia, именно на clang и сделаны) - там чем памяти меньше, тем лучше.

Ну ладно, ты меня почти убедил. Обещаю никогда больше не спорить о компиляторах.

Пикрелейтед. http://s53.radikal.ru/i139/1105/ad/b23d70b98ae0.jpg

> а то что он «мертв» - это дело такое, со всеми полезными инструментами бывает

Инструмент жив, пока им пользуются. Так что gcc-xml вполне жив, а ты сказал две глупости.

> Инструмент жив, пока им пользуются. Так что gcc-xml вполне жив, а ты сказал две глупости.

нет - прокомментировал одну твою, win95, например, тоже еще пользуются, если ты считаешь ее нужной и живой - дело твое конечно, можешь быть ее персональным фанатом и продлевать ее «нужность» вплоть до конца своей жизни своим существованием ( это образно было сказано )

> а теперь посмотри на потуги навроде gcc-xml, которые так и закончились ничем

ну почему сразу ничем. очень знатный велосипед получился, можно сравнить тот же «REPL для C» : на GCCXML.hs http://neugierig.org/software/c-repl и на базе LLVM: http://code.google.com/p/ccons/

другое дело, что GCCXML как бы немного сдох.

а то говорят тут, нет дескать, репла для C. просто C для репла не очень-то и подходит.

> можно сравнить тот же «REPL для C» : на GCCXML.hs http://neugierig.org/software/c-repl

видел его - до чего-либо рабочего оно так и не доросло

> И еще, придурок. Догадайся, почему разработчики под Mac OS X предпочитают пользоваться clang при отладке, и только release собирают gcc.

Разработчики под что ? Ты приводишь закрытую, тормозную х-ню в качестве примера для подражания ?

> Разработчики под что ? Ты приводишь закрытую, тормозную х-ню в качестве примера для подражания ?

Почему кот лижет яйца? Потому что может. Были бы такие же удобные тулзы, как в XCode, во всяких там еклипсах, разработчики под лялих делали бы ровно то же самое.

> Почему кот лижет яйца? Потому что может. Были бы такие же удобные тулзы, как в XCode, во всяких там еклипсах, разработчики под лялих делали бы ровно то же самое.

Ну.. раз пошла такая песня. Xcode не видел. Он лучше Visual Studio ?

> Ну.. раз пошла такая песня. Xcode не видел. Он лучше Visual Studio ?

http://developer.apple.com/technologies/mac/snowleopard/static.html

в VC2010 тоже есть статический анализ

да и в 2008-м тоже был

> в VC2010 тоже есть статический анализ

Для Си? Нету.

> Для Си? Нету.

http://msdn.microsoft.com/en-us/library/6yz6c9dy(v=VS.100).aspx

он петушиный и находит только совсем тривиальные вещи (насколько хорошо с этим в хкоде увы не смотрел).

> он петушиный и находит только совсем тривиальные вещи

в Xcode 3.х тоже был не фонтан, в четверке еще не смотрел

>http://developer.apple.com/technologies/mac/snowleopard/static.html

Продвинутая защита от опечаток ? От логических ошибок это все равно не защитит :)

то есть даже повторное освобождение указателя он не находил.

>в чём поинт использования каждого такого расширения, например, в ядре Linux?

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

если можно писать на plain C99 как те же BSD?

А зачем? Чтобы получилась еще одна ненужная недоось лайк БЗД? Зачем подражать лузерам?

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

Похоже на костыль для ленящихся писать юнит-тесты и не знающих про valgrind и про проблему останова.

Тем более, они все нивелируются, если вспомнить, что Clang в сравнении с GCC ничего не умеет.

То, что им собирается 90% софта, называется «ничего не умеет»?

Clang в среднем выигрывает у GCC по быстродействии скомпилированного бинарника, но очень слабо выигрывает.

А кто, по вашему, end-user компилятора?

А что, разработчик должен все собирать на супер-производительном компьютере с 8 GB оперативки? :D

90% какого софта, если он только минимальную FreeBSD может собрать? А выигрыш действительно слишком маленький, да и то не везде(в основном в кодеках и архиваторах, но там лучше себя показал ICC).

>То, что им собирается 90% софта, называется «ничего не умеет»?

и что-то даже работает...

90% какого софта

Обычного. Не собирается только то, что юзает гну-расширения. Много что собирал им.

PS. Все сказанное мной относится к 2.8 и новее.