Clang и LLVM: предыстория
Содержание:
1. Матчасть;
2.Предыстория (Вы читаете данный раздел);
3. Настоящее и итоги.
В мире UNIX-подобных систем стандартом де-факто стал GCC. Сложно представить себе, что можно для практических нужд, для сборки программ на C/C++ использовать нечто другое. В мире свободного ПО и ПО с открытым кодом пригодность компилятора для работы определяется его способностью собирать из исходного кода как можно большее количество программ. Если компилятор, даже сверхбыстрый и поддерживающий но-вейшие технологии, умеет компилировать одну-две программы, в интересах, скажем, определенной компании или некоего сообщества, это не означает, что этот компилятор - «замена» более распространенному. Альтернативы возникают, когда некий продукт становится по каким-либо причинам неудобным группе пользователей. Кому и почему стал неудобен GCC, и что стало причиной возникновения Clang?
Компания Apple использовала в своих разработках LLVM и фронтэнд от GCC. Собственно, изначально LVVM был создан в 2000 году без поддержки Apple, но в 2005 году Apple наняла для его разработки на постоянной основе целую команду. Итак, LLVM функционировал в связке с GCC. Но GCC, как известно, ориентирован на Си и С++, в то время как Apple была нужна хорошая поддержка Objective C. Кроме того, внутри «группы LLVM» сочли, что GCC слишком громоздкий, да к тому же плохо стыкуется с IDE от Apple. И даже это еще не всё: GCC лицензирован под GPL, а согласно GPL разработчики обязаны открывать код своих дополнений к компилятору, в то время как, допустим, в BSD-подобных лицензиях это не требуется.
Так и возник компилятор Clang, код которого был открыт в 2007 году под лицензией University of Illinois/NCSA Open Source License. В сети (http://llvm.org/devmtg/2007-05/09-Naroff-CFE.pdf) лежат слайды для прошедшего тогда собрания разработчиков LLVM. На слайдах крупными надписями выражается необходимость в новом фронтэнде. Выражается и «мотивация», почему не подходит GCC. «Кривая изучения слишком сложна для многих разработчиков» (замечу, что кроме кривых изучения, можно двигаться по прямой), «политика ограничивает инновацию» и так далее. Приводятся примеры, как Clang и GCC по-разному сообщают об ошибках - дескать, Clang понятнее. Даются графики скорости работы на примере, как происходит компиляция carbon.h (API на Си для Mac OS X; на то время - исходники размером в 12,3 Мб) - в самом деле, Clang в 2,5 раза быстрее справился с этим. Собственно, никто никогда не штрафовал GCC за превышение скорости. Зачем это ставить в упрек? Недавно, 29 октября этого года, в бывшем Trolltech собрали Qt полностью на Clang, и вот сравнительные графики с GCC: http://labs.qt.nokia.com/2010/10/29/compiling-qt-with-clang. При этом у Clang размеры бинарников под Mac оказались меньше, чем собранные в GCC, а под Linux наоборот - GCC сделал меньшими бинарни-ки. Кроме того, полученные с помощью Clang бинарники оказались на 16% медленнее под Linux и на 6 - под Mac. Что важнее пользователю: скорость компиляции или скорость работы уже собранной программы?
В том же октябре при помощи Clang собрали и относительно рабочее ядро Linux (http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-October/011711.html). В сети время от времени появляются радост-ные сообщения о том, что под Clang теперь собираются то библиотека Boost C++, то HelenOS. Бродят мысли о том, чтобы Clang сделать основным компилятором для сборки FreeBSD. Хорошо бы еще появилась мысль сделать дизайн сайта Clang (http://clang. llvm.org) рабочим, а то меню слева у меня на экране помещается не полностью и при этом не прокручивается, а иногда и вовсе мешает просмотру материалов, перекрывая их...
Гораздо больше, чем система анализа, трансформации и оптимизации программ LLVM, Вас интересует строительное оборудование (http://www.tehnofond.ru) высочайшего качества? Тогда я настоятельно советую Вам обратиться к специалистам компании "Технофонд". Только здесь Вы сможете приобрести все необходимое Вам оборудование по максимально выгодной для себя цене!
1. Матчасть;
2.
3. Настоящее и итоги.
В мире UNIX-подобных систем стандартом де-факто стал GCC. Сложно представить себе, что можно для практических нужд, для сборки программ на C/C++ использовать нечто другое. В мире свободного ПО и ПО с открытым кодом пригодность компилятора для работы определяется его способностью собирать из исходного кода как можно большее количество программ. Если компилятор, даже сверхбыстрый и поддерживающий но-вейшие технологии, умеет компилировать одну-две программы, в интересах, скажем, определенной компании или некоего сообщества, это не означает, что этот компилятор - «замена» более распространенному. Альтернативы возникают, когда некий продукт становится по каким-либо причинам неудобным группе пользователей. Кому и почему стал неудобен GCC, и что стало причиной возникновения Clang?
Компания Apple использовала в своих разработках LLVM и фронтэнд от GCC. Собственно, изначально LVVM был создан в 2000 году без поддержки Apple, но в 2005 году Apple наняла для его разработки на постоянной основе целую команду. Итак, LLVM функционировал в связке с GCC. Но GCC, как известно, ориентирован на Си и С++, в то время как Apple была нужна хорошая поддержка Objective C. Кроме того, внутри «группы LLVM» сочли, что GCC слишком громоздкий, да к тому же плохо стыкуется с IDE от Apple. И даже это еще не всё: GCC лицензирован под GPL, а согласно GPL разработчики обязаны открывать код своих дополнений к компилятору, в то время как, допустим, в BSD-подобных лицензиях это не требуется.
Так и возник компилятор Clang, код которого был открыт в 2007 году под лицензией University of Illinois/NCSA Open Source License. В сети (http://llvm.org/devmtg/2007-05/09-Naroff-CFE.pdf) лежат слайды для прошедшего тогда собрания разработчиков LLVM. На слайдах крупными надписями выражается необходимость в новом фронтэнде. Выражается и «мотивация», почему не подходит GCC. «Кривая изучения слишком сложна для многих разработчиков» (замечу, что кроме кривых изучения, можно двигаться по прямой), «политика ограничивает инновацию» и так далее. Приводятся примеры, как Clang и GCC по-разному сообщают об ошибках - дескать, Clang понятнее. Даются графики скорости работы на примере, как происходит компиляция carbon.h (API на Си для Mac OS X; на то время - исходники размером в 12,3 Мб) - в самом деле, Clang в 2,5 раза быстрее справился с этим. Собственно, никто никогда не штрафовал GCC за превышение скорости. Зачем это ставить в упрек? Недавно, 29 октября этого года, в бывшем Trolltech собрали Qt полностью на Clang, и вот сравнительные графики с GCC: http://labs.qt.nokia.com/2010/10/29/compiling-qt-with-clang. При этом у Clang размеры бинарников под Mac оказались меньше, чем собранные в GCC, а под Linux наоборот - GCC сделал меньшими бинарни-ки. Кроме того, полученные с помощью Clang бинарники оказались на 16% медленнее под Linux и на 6 - под Mac. Что важнее пользователю: скорость компиляции или скорость работы уже собранной программы?
В том же октябре при помощи Clang собрали и относительно рабочее ядро Linux (http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-October/011711.html). В сети время от времени появляются радост-ные сообщения о том, что под Clang теперь собираются то библиотека Boost C++, то HelenOS. Бродят мысли о том, чтобы Clang сделать основным компилятором для сборки FreeBSD. Хорошо бы еще появилась мысль сделать дизайн сайта Clang (http://clang. llvm.org) рабочим, а то меню слева у меня на экране помещается не полностью и при этом не прокручивается, а иногда и вовсе мешает просмотру материалов, перекрывая их...
Гораздо больше, чем система анализа, трансформации и оптимизации программ LLVM, Вас интересует строительное оборудование (http://www.tehnofond.ru) высочайшего качества? Тогда я настоятельно советую Вам обратиться к специалистам компании "Технофонд". Только здесь Вы сможете приобрести все необходимое Вам оборудование по максимально выгодной для себя цене!
