После 7 месяцев разработки представлен (http://lists.cs.uiuc.edu/pipermail/llvm-announce/2013-June/0... релиз проекта LLVM 3.3 (http://llvm.org) (Low Level Virtual Machine) - GCC совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный биткод (http://llvm.org/docs/BitCodeFormat.html) RISC подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизации). Сгенерированный платформонезависимый псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы.
Новая версия примечательна интеграцией поддержки целевых платформ AArch64 и AMD R600 GPU, поддержкой систем IBM S390 на базе архитектуры z, значительным улучшением поддержки платформ PowerPC и MIPS. За счёт увеличение качества реализации автоматической векторизации циклов и реализации серии общих оптимизаций заметно увеличена производительность кода, генерируемого LLVM 3.3. В Clang доведена до готовности поддержка стандарта C++11, расширены возможности статического анализатора кода, добавлен инструментарий для автоматического преобразования кода C++ в вид, соответствующий спецификации C++11, подготовлены плагины для автоформатирования кода в vim и emacs.Основные новшества (http://llvm.org/releases/3.3/docs/ReleaseNotes.html) LLVM 3.3:
- Поддержка 64-разрядной архитектуры AArch64 (ARM64) в качестве целевой платформы. Архитектура AArch64 включает в себя новый набор команд A64, примечательный расширением числа регистров, новыми командами для вычислений с плавающей запятой (FP) и новыми векторными SIMD-инструкциями NEON. В настоящее время работа по реализации порта AArch64 ещё полностью не завершена, но уже поддерживается сборка приложений, написанных в соответствии со стандартами C99 и C++03, для платформы Linux.
- Интеграция бэкэнда для использования в качестве целевой платформы GPU семейства R600 (HD2XXX - HD7XXX). Изначально бэкенд развивался в репозитории проекта Mesa, но был перенесён в кодовую базу LLVM. Бэкэнд необходим для компилятора шейдеров LLVM, который в свою очередь требуется для открытой реализации стандарта OpenCL;
- Увеличено качество кода, генерируемого при использовании автоматической векторизации циклов (Loop Vectorizer), которая теперь включена по умолчанию при выборе режима оптимизации "-O3". Распараллеливание циклов позволяет заметно поднять производительность кода, генерируемого LLVM 3.3. В итоге независимые тесты производительности фиксируют более высокую производительность кода, собранного c использованием LLVM 3.3, по сравнению с LLVM 3.2;
- Представлен новый SLP векторизатор, который пока не используется по умолчанию и требует для своего включения указания опции "-fslp-vectorize". Поддержка ранее доступного векторизатора BB сохранена и может быть активирована при указании опции "-fslp-vectorize-aggressive";
- Значительно улучшена реализация бэкенда для процессоров PowerPC, в том числе поддержка наборов инструкций PowerPC 2.04/2.05/2.06 и обеспечение поддержки интегрированного ассемблера;- Улучшен бэкенд для архитектуры MIPS, добавлена поддержка инструментария Sourcery CodeBench, добавлены новые опции командной строки (-mxgot/-mno-xgot, -EL/-EB, -mmicromips/-mno-micromips, -msingle-float/-mdouble-float, -mabi=32 (o32 abi) и -mabi=64 (n64 abi)), улучшено качество генерации кода DSP-ASE;
- Из состава удалён порт CellSPU и прекращена поддержка API для расширенной линковки на уровне промежуточного представления кода. В бэкенде для целевой платформы Hexagonv прекращена поддержка устаревших архитектур hexagonv2 и hexagonv3 (поддержка hexagonv4 и hexagonv5 сохранена).
Основные новшества (http://llvm.org/releases/3.3/docs/ReleaseNotes.html) субпроектов LLVM 3.3:- В компиляторе Clang полностью завершена (http://llvm.org/releases/3.3/tools/clang/docs/ReleaseNotes.h... реализация поддержки всех компонентов стандарта C++11, в том числе новых библиотек, таких как std::regex. В анонсе отмечается, что Clang является первым компилятором, поддерживающим в полной мере стандарт C++'11 (разработчики GCC выступали (http://www.opennet.me/opennews/art.shtml?num=37070) с похожим заявлением). Для упрощения миграции на C++11 в состав включен новый инструмент "C++'11 Migrator", позволяющий автоматически конвертировать код C++ в представление, использующее элементы C++11. Кроме того, в Clang 3.3 добавлена возможность использования символов Unicode в идентификаторах.
В Clang Static Analyzer добавлены дополнительные проверки, позволяющие выполнять межпроцедурный статический анализ кода, выходящий за границы отдельных C++ конструкторов/деструкторов. Для разработчиков, использующих vim и emacs, представлен плагин "Clang Format", выполняющий функции интеллектуальной системы автоматического форматирования кода.
В состав Clang включены патчи, необходимые для обеспечения сборки ядра Linux, что позволило (http://events.linuxfoundation.org/images/stories/slides/lfcs... приблизиться к состоянию, когда немодифицированное ядро Linux можно будет пересобрать штатным компилятором Clang. До сих пор для подобной сборки требовалось применение серии патчей, как к ядру, так и к Clang;
- Отмечен прогресс в реализации проекта Portable Computing Language OpenCL (PoCL (http://pocl.sourceforge.net/)), в рамках которого ведётся разработка полностью открытой реализации стандарта OpenCL, независимой от производителей графических ускорителей. PoCL позволит (http://www.opennet.me/opennews/art.shtml?num=32092) разработчикам не задумываться об особенностях той или иной реализации стандарта и использовать предоставляемые компилятором оптимизации вместо применения специфических для каждой платформы техник ручной оптимизации. PoCL реализован по модульному принципу, позволяющему использовать различные бэкенды для выполнения OpenCL-ядер на разных типах графических и центральных процессоров;- Представлен проект Jade (https://github.com/orcc/jade) (Just-in-time Adaptive Decoder Engine), в рамках которого развивается универсальный движок для декодирования видео, использующих LLVM для JIT-компиляции адаптивных конфигураций декодера видео, определённых комитетом MPEG Reconfigurable Video Coding (RVC);
- Обновлена реализация LDC - компилятора для языка программирования D (http://ru.wikipedia.org/wiki/D_%28%D1%8F%... комбинирующего фронтэнд из состава эталонного компилятора D с бэкендом на базе LLVM, позволяющим генерировать эффективный нативный код. LDC поддерживает генерацию кода для систем x86/x86_64 Linux, Mac OS X и Windows, и PPC64 для Linux. В разработке находится создание генератора кода для архитектуры ARM.
Из параллельно развивающихся проектов, основанных на LLVM, можно отметить:
- KLEE (http://klee.llvm.org/) - символьный анализатор и генератор тестовых наборов;- Runtime-библиотека compiler-rt (http://compiler-rt.llvm.org/);
- llvm-mc (http://llvm.org/releases/2.6/docs/ReleaseNotes.html#mc) - автогенератор ассемблера, дизассемблера и других, связанных с машинным кодом компонентов, на основе описаний параметров LLVM-совместимых платформ.
- VMKit (http://vmkit.llvm.org/) - виртуальная машина для Java и .NET;
- Реализация функционального языка программирования Pure (http://pure-lang.googlecode.com/);
- LDC (http://www.dsource.org/projects/ldc) - компилятор для языка D;
- Roadsend PHP (http://code.roadsend.com/rphp) - оптимизатор, статический и JIT компилятор для языка PHP;
- Виртуальные машины для Ruby: Rubinius (http://rubini.us/) и MacRuby (http://www.macruby.org/);
- Unladen Swallow (http://code.google.com/p/unladen-swallow/) - реализация языка Python;
- LLVM-Lua (http://code.google.com/p/llvm-lua/)
- FlashCCompiler (http://llvm.org/devmtg/2008-08/Petersen_FlashCCompiler.pdf) - средст...
URL: http://lists.cs.uiuc.edu/pipermail/llvm-announce/2013-June/0...
Новость: http://www.opennet.me/opennews/art.shtml?num=37200
Оптимизирует так круто, что даже бесконечный loop выполняется за пару секунд.
бесконечный loop выполняется на пару секунд быстрее :)
> бесконечный loop выполняется на пару секунд быстрее :)В два раза быстрее!
при значении бесконечности равном двум секундам
> Мы все знаем, что Linux — это круто… он выполняет бесконечные циклы за 5 секунд.
> Линус Торвальдсlinux был первым кто выполнял бесконечные цыклы, наверное потому что программа падала в core )))
> linux был первым кто выполнял бесконечные цыклы,А что ваша система делает когда не озадачена? Грузит ящики бочками? :)
>> linux был первым кто выполнял бесконечные цыклы,
> А что ваша система делает когда не озадачена? Грузит ящики бочками? :)Перестукивается с серверами майкрософта.
>> linux был первым кто выполнял бесконечные цыклы,
> А что ваша система делает когда не озадачена? Грузит ящики бочками? :)вин9x, например, любила странички в свопе перекладывать. нет, серьёзно.
> странички в свопе перекладыватьПасьянс?
> В компиляторе Clang полностью завершена реализация поддержки всех компонентов стандарта C++11, в том числе новых библиотек, таких как std::regex. В анонсе отмечается, что Clang является первым компилятором, поддерживающим в полной мере стандарт C++'11Они теперь в каждом релизе будут это заявлять?
> Они теперь в каждом релизе будут это заявлять?А они это заявляли в предыдущем релизе? По-моему прошлая новость относилась к ветке 3.3 из которой как раз и отпочковался этот релиз.
ага :)
"В компиляторе Clang полностью завершена реализация поддержки всех компонентов стандарта C++11, в том числе новых библиотек, таких как std::regex. В анонсе отмечается, что Clang является первым компилятором, поддерживающим в полной мере стандарт C++'11"> Они теперь в каждом релизе будут это заявлять?
Ну наверное до тех пор, пока не появится другой такой компилятор, в отношении которого можно будет заявить то же самое.
Мне кажется это справедливым.
> Ну наверное до тех пор, пока не появится другой такой компилятор, в
> отношении которого можно будет заявить то же самое.боюсь, что не появится никогда. как может появиться ещё один компилятор, которы «первый в полной мере поддерживает», если один уже есть?
> как может появиться ещё один компилятор, которы «первый в полной мере поддерживает», если один уже есть?Проблема в том, что таких «первых» уже два.
При том у обоих чего-нибудь да не хватает. Но пузомерка зато уже о-го-го :)
>> как может появиться ещё один компилятор, которы «первый в полной мере поддерживает», если один уже есть?
> Проблема в том, что таких «первых» уже два.FIGHT!
> Они теперь в каждом релизе будут это заявлять?Будут. И правильно.
Разработчикам gcc очень не хватает хорошего пинка под зад, чтобы прекратить мастурбировать и начать работать.
> Разработчикам gcc очень не хватает хорошего пинка под зад, чтобы прекратить мастурбировать
> и начать работать.У разработчиков GCC кодогенерация уже намного лучше чем в шланге. Особенно если посмотреть на всякие там ARM и MIPS, где шланг вообще генерит нечто жуткое, а зачастую и просто глючное. А то что начиная с некоего момента сильно оптимизировать становится намного труднее - так это логично.
Легко ускорить в 2 раза паршивый кодогенератор. А вот ускорить в 2 раза близкий к оптимальному кодогенератор - уже ой. Что логично.
> У разработчиков GCC кодогенерация уже намного лучше чем в шланге. Особенно если посмотреть на всякие там ARM и MIPS, где шланг вообще генерит нечто жуткое, а зачастую и просто глючное. А то что начиная с некоего момента сильно оптимизировать становится намного труднее - так это логично.Мы еще помним когда ядро собранное gcc отказывалось грузиться на x86. А вы не помните этого ?
> Разработчикам gcc очень не хватает хорошего пинка под зад, чтобы прекратить мастурбировать
> и начать работать.ты, без сомнения, можешь подробно рассказать, что именно тебя не устраивает в gcc и над чем стоило бы поработать.
нет, поддержка цыпыпыадынадын — не интересует. тебя, кстати, тоже не интересует, потому что всё равно ты на нём если и пишешь, то максимум «приветмиры». а вот что не так с поддержкой разных архитектур и с кодогенерацией? пока что тут отстаёт именно clang/llvm, и это им надо работать-работать-работать, чтобы догнать.
и да, LTO в gcc есть. polyhedral model для оптимизации тоже есть. с gold'ом вообще весьма неплохо всё выходит. а превращать gcc в библиотеку для jit-компиляции никто не будет, потому что изначально это не входило в цели проекта.
а как на нём писать, если он не поддерживается?
> а как на нём писать, если он не поддерживается?кем?
На чём?
> ты, без сомнения, можешь подробно рассказать, что именно тебя не устраивает в gcc
> и над чем стоило бы поработать.Об этом могут рассказать сами разработчики LLVM: http://llvm.org/docs/GettingStarted.html#broken-versions-of-...
Из версии в версию у GCC грабли и баги.
> Об этом могут рассказать сами разработчики LLVM: http://llvm.org/docs/GettingStarted.html#broken-versions-of-...
> Из версии в версию у GCC грабли и баги.отличная ссылка. прелестная просто. хорошо иллюстрирует отсутствие мозга у фанбоев llvm и у бздешников в частности.
>> Об этом могут рассказать сами разработчики LLVM: http://llvm.org/docs/GettingStarted.html#broken-versions-of-...
>> Из версии в версию у GCC грабли и баги.
> отличная ссылка. прелестная просто. хорошо иллюстрирует отсутствие мозга у фанбоев llvm
> и у бздешников в частности.Угу. Штаб-квартира рассказала Кольчугину, чем _его не устраивает GCC. Чем его не устраивает LLVM штаб-квартира не рассказала -- вывод очевиден! LLVM чудо как устраивает Кольчугина. ---Желееезные нервы, трусца.
> нет, поддержка цыпыпыадынадын — не интересует.Не интересует функциональность компилятора, интересует функциональность мастурбатора? Проход, не задерживайся.
>> нет, поддержка цыпыпыадынадын — не интересует.
> Не интересует функциональность компилятора, интересует функциональность мастурбатора?
> Проход, не задерживайся.сколько и какого софта *ты лично* написал на адынадын? без каких его фич, которые не реализваны в gcc, ты не можешь жить? вангую, что внятного ответа не будет. зато поорать про «поддержку и развитие» — завсегда готов, не так ли?
С выходом gcc 4.8 жаловаться действительно (почти) не на что.Только вот поддержка бажная — например, в 4.7 (который до сих пор в продакшене), есть довольно стремный баг, когда нельзя захватить лямбду в другую лямбду по значению, если другая лямбда используется в списке инициализации. Кое-какие проблемы с шаблонами есть.
Впрочем, в clang тоже багов хватает, и даже поболе, чем в gcc.
Не буду, впрочем, упоминать софт, который я на 11 пишу.
я ж у анонимуса спрашивал, а не у человека, который действительно код пишет.> в продакшене), есть довольно стремный баг, когда нельзя захватить лямбду в
> другую лямбду по значению, если другая лямбда используется в списке инициализации.неоригинально скажу, что причина — в изначальной кривости самой фичи. не надо было пихать в стандарт невпихуемое, вот и всё.
> Кое-какие проблемы с шаблонами есть.
тоже фича та ещё. декларативный тюринг-полный язык, причём атомно неудобный — крутизна просто. чем меньше эта фигня используется — тем лучше. жуть.
> неоригинально скажу, что причина — в изначальной кривости самой фичи. не надо
> было пихать в стандарт невпихуемое, вот и всё.Причина — в одном gcc'изме, как который парсится такая лямбда. Правда, я gcc'шный багтрекер по диагонали читал, так что, может, что неправильно понял.
А называть лямбды кривыми — так, простите, тут недалеко и до того, чтобы сами плюсы кривыми назвать. Впрочем, сегодняшние лямбды действительно кривоваты — ни полиморфизма тебе, ничего. В C++14 починят, впрочем (и, кстати, где-то в шланге это тоже уже реализовано).
>> Кое-какие проблемы с шаблонами есть.
> тоже фича та ещё. декларативный тюринг-полный язык, причём атомно неудобный — крутизна
> просто. чем меньше эта фигня используется — тем лучше. жуть.ХЗ, я на темплейтах написал генератор запросов и функторов для недоORM на плюсах. Удобно и красиво и функционально, да. Любитель хаскеля во мне радуется.
При должном владении шаблоны вообще существенно сокращают время разработки.
> А называть лямбды кривыми — так, простите, тут недалеко и до того,
> чтобы сами плюсы кривыми назвать.ТЫ ЗНАЛ!
> При должном владении шаблоны вообще существенно сокращают время разработки.
а также помогают писать неподдерживаемый код. пардон, книга Александреску, например, выглядит как гримуар, написаный на неземном языке.
>> При должном владении шаблоны вообще существенно сокращают время разработки.
> а также помогают писать неподдерживаемый код. пардон, книга Александреску, например, выглядит
> как гримуар, написаный на неземном языке.Книга на китайском для меня тоже не очень отличается от какого-нибудь произведения на неземном языке, но это же не повод говорить, что китайский — криво и не нужно.
Условный перлокод тоже выглядит весьма страшно для неподготовленного читателя, но и там сферы применения есть. «Не нужно» не нужно :3
применить можно почти любую фигню, но фигнёй-то от этого она быть не перестаёт, увы. и я не то, чтобы совсем уж «неподготовленый читатель». но всё равно гримуар.
p.s. Александреску-то не зря на D убежал. :3
p.s. а всякие генераторы и прочее пишутся на DSL. который потом при необходимости транслируется в целевой язык. всё равно шаблонная магия хреново отлаживается.
>>первым компилятором, поддерживающим в полной мере стандарт C++'11
> Они теперь в каждом релизе будут это заявлять?Ты не понял _тонкого _слегка рекурсивного юмора автора *этих* новостей:
Почувствуй переход от полной _цены к полной _мере, переход первого места от конкурсанта к конкурсанту! Чувствуешь? Чувствуешь!!?
18.06.2013 13:34 Новая версия набора компиляторов LLVM 3.3
...отмечается, что Clang является первым компилятором, поддерживающим в полной мере стандарт C++'11 (разработчики GCC выступали с похожим заявлением)31.05.2013 23:20 Обновление набора компиляторов GCC 4.8.1
...сделало G++ первым компилятором C++, реализовавшим все значительные возможности стандарта C++11
20.04.2013 23:45 В Clang доведена до готовности поддержка стандарта C++11
...полностью завершена реализация поддержки всех компонентов стандарта C++11. Статус полной совместимости с C++11 был достигнут ... Примечательно, что проектом GCC реализация стандарта C++11 ещё не завершена.21.12.2012 14:23 Новая версия набора компиляторов LLVM 3.2
...Clang обеспечена полноценная поддержка стандарта C++'11.
> Они теперь в каждом релизе будут это заявлять?И, главное, опять соврали - ниже перечислено то чего не хватает.
Главное преимуществ LLVM в скорости компиляции. Но это нужно только программисту пишущему программу, для программистов живущих в сферическом вакууме и создающих уникальные "вещи сами в себе" с точки зрения архитектуры и элегантности найденных решений. Кто вычислит взаимосвязь между скоростью компиляции и временем необходимым для создания программы?
> Главное преимуществ LLVM в скорости компиляции.Ты зря стесняешься, сходи по ссылке http://llvm.org/ - там тебе расскажут в чем преимущества и зачем оно нужно.
И заодно Apple Developers Kit предложат за недорого?
> И заодно Apple Developers Kit предложат за недорого?Вы так говорите, как будто это что-то плохое.
> Вы так говорите, как будто это что-то плохое.Грeбля под одну контору - да, это плохое. Это вендорлоком попахивает.
Intel, AMD, ARM, Qualcom, MIPS (part of Imagination Technologies), как-то слишком много названий у одной конторы.
Ах да, и всеми вами любимый Google, и немного IBM.
> Intel, AMD, ARM, Qualcom, MIPS (part of Imagination Technologies), как-то слишком много названий у одной конторы.Контора зовется Apple, а те, кого ты перечислил - это свадебные генералы.
Таким образом, разработчики из этих компаний, которые коммитят код в LLVM просто тратят оплаченное их компанией время?
> Таким образом, разработчики из этих компаний, которые коммитят код в LLVM просто
> тратят оплаченное их компанией время?примерно так, да.
Финансы, подсказывают мне, что если бы эти работы не окупались в перспективе, то никто бы за них не взялся. Учи NPV.
> Учи NPV.а ты — русский.
Чистая приведенная стоимость (ЧПС), тебе нравится больше?
> Чистая приведенная стоимость (ЧПС), тебе нравится больше?MBA-спиик в любом виде _не лучше.
> Чистая приведенная стоимость (ЧПС), тебе нравится больше?мне без разницы, я намекал, что запятая лишняя.
> Это вендорлоком попахивает.Ты так говоришь, как будто это что-то плохое.
Противники LLVM после каждой новости о нем, с очередным достижением, в очередной раз в чем-то утираются, и каждый раз что-то злобно квакают не в тему.
А яблофилы громко об этом кричат :)
> Противники LLVMУ LLVM нет противников.
Есть только здравомыслящие люди, которые настороженно относятся к использованию в опенсорсе технологии, полностью контролируемой известной проприетарной компанией.
> Есть только здравомыслящие люди, которые настороженно относятся к использованию в опенсорсе технологии, полностью контролируемой известной проприетарной компанией.Впрочем, на них найдутся не менее здравомыслящие люди, считающие, что опенсорс должен существовать только на подачки проприетарных корпораций, и только под их жестким контролем. И ни в коему случае не пытался конкурировать с их продукцией.
>> Противники LLVM
> У LLVM нет противников.
> Есть только здравомыслящие люди, которые настороженно относятся к использованию в опенсорсе
> технологии, полностью контролируемой известной проприетарной компанией.у тебя что, исходники отберут, что ли? даже если и закроют новые версии, старые наработки отстанутся.
а проект, тем не менее, очень достойный. и как минимум один из его плюсов — это конкуренция с gcc. потому что без конкурентов разработчики могут и забить: «всё равно мы единственные, а потому — лучшие».
хотя вот идиотскую caret, которую впилили в gcc 4.8 — так лучше бы забили.
> у тебя что, исходники отберут, что ли? даже если и закроют новые
> версии, старые наработки отстанутся.Ну да. Вот только как ты относишься к всяким некрофагам, уцепившимся за gcc 2.95 или 4.2 накрайняк? Вот ты будешь вообще проверять как твоя программа билдуется в gcc 2.95? :)
> Вот ты будешь вообще проверять как
> твоя программа билдуется в gcc 2.95? :)на 4.6 приходилось. хреново билдится. :3
> на 4.6 приходилось. хреново билдится. :3По сравнению с перспективой билдить 4.2 (который умеет валиться с internal error без особых на то причин) и тем паче 2.95 - не так уж 4.6 и плох :). Хотя спору нет, 4.7-4.8 лучше.
но использовали же. -O0 наш друг, если что.
Код открыт. Форкни - контролируй сам.
> Код открыт. Форкни - контролируй сам.- А 20 гопников могут дать мне в табло...
- Но ты же тоже можешь дать в лицо 20 гопникам! Все честно!
>> Код открыт. Форкни - контролируй сам.
> - А 20 гопников могут дать мне в табло...
> - Но ты же тоже можешь дать в лицо 20 гопникам! Все
> честно!Во как. Оказывается GPL уже не работает?
>>> Код открыт. Форкни - контролируй сам.
>> - А 20 гопников могут дать мне в табло...
>> - Но ты же тоже можешь дать в лицо 20 гопникам! Все
>> честно!
> Во как. Оказывается GPL уже не работает?Работает! Требуй у 20 гопников, давших тебе в лицо, передать тебе также все исходные удары в их лицца. И через суд, если не!!
> Код открыт. Форкни - контролируй сам.udev уже как-то форкнули. Можно не напоминать, чем это закончилось?
Помимо желания форкать, нужна еще и квалификация.И авторитет. Если Вася Пупкин форкнет LLVM и начнет запиливать фичи, а яббл начнет запиливать свои (не спеша делиться кодом) - чьими фичами будут пользоваться в 99.99999% проектов?
>> Код открыт. Форкни - контролируй сам.
> udev уже как-то форкнули. Можно не напоминать, чем это закончилось?
> Помимо желания форкать, нужна еще и квалификация.
> И авторитет. Если Вася Пупкин форкнет LLVM и начнет запиливать фичи, а
> яббл начнет запиливать свои (не спеша делиться кодом) - чьими фичами
> будут пользоваться в 99.99999% проектов?давайте начнем разделять - что Apple просто спонсирует разработку. Вам никто не мешает спонсировать тоже. Возможно ваши деньги будут решающими для выбора той или иной фичи :)
а сутенер просто спонсирует благродных дам.
> а сутенер просто спонсирует благродных дам.страшно представить, как выглядит GPL в таких аналогиях.
>> а сутенер просто спонсирует благродных дам.
> страшно представить, как выглядит GPL в таких аналогиях.Сутенёры предоставляют справку из докома о том, что они являются полностью оригинальным Произведением, рождены без исходников, просто Чудом.
Не разочаровал.
>> Код открыт. Форкни - контролируй сам.
> udev уже как-то форкнули. Можно не напоминать, чем это закончилось?
> Помимо желания форкать, нужна еще и квалификация.Так внезапно выяснится, что GPL не спасает...
> И авторитет. Если Вася Пупкин форкнет LLVM и начнет запиливать фичи, а
> яббл начнет запиливать свои (не спеша делиться кодом) - чьими фичами
> будут пользоваться в 99.99999% проектов?...дважды выяснится.
И вдруг выяснится, просто нужна контора, которая делится открытым кодом. Опачки, для LLVM такая - есть.
>> Помимо желания форкать, нужна еще и квалификация.
> Так внезапно выяснится, что GPL не спасает...
>> И авторитет. Если Вася Пупкин форкнет LLVM и начнет запиливать фичи, а
> ...дважды выяснится.С чего ты взял, что _GPL_ должна скасать от отсутствия квалификации и как-то помогать распространять неработающий код?? Ударился, не иначе.
> И вдруг выяснится, просто нужна контора, которая делится открытым кодом. Опачки, для
> LLVM такая - есть.Ойдаладно?? Одна Правильная Контора? Марш в приёмную ФСБ за Самым Правильным Кодом.
> С чего ты взял, что _GPL_ должна скасать от отсутствия квалификацииЯ? это жплботы тут верещат, что gpl от всех напастей.
> Ойдаладно?? Одна Правильная Контора?
Код открыт. Подключай свою, будет второй. И более того, форкни и закрой исходники - накажи проклятых Эпплов.
> Марш в приёмную ФСБ за Самым Правильным Кодом.
Ударился, не иначе.
>> Противники LLVM
> У LLVM нет противников. Есть только здравомыслящие люди, которые настороженно относятся к использованию в опенсорсе технологии, полностью контролируемой известной проприетарной компанией.Это называется - "Я не трус, но я боюсь" (С).
> чем преимущества и зачем оно нужно.Ага, ты еще предложи на сайте майкрософта преимущества винды смотреть. А это карманный проектик эппла, который по маркетинговому буллшиту спец великий.
>> чем преимущества и зачем оно нужно.
> Ага, ты еще предложи на сайте майкрософта преимущества винды смотреть. А это
> карманный проектик эппла, который по маркетинговому буллшиту спец великий.Ага, а так же карманный проектик Intel, AMD, Qualcom, ARM, MIPS...
>>> чем преимущества и зачем оно нужно.
>> Ага, ты еще предложи на сайте майкрософта преимущества винды смотреть. А это
>> карманный проектик эппла, который по маркетинговому буллшиту спец великий.
> Ага, а так же карманный проектик Intel, AMD, Qualcom, ARM, MIPS...чтро за бред? У Intel - ICC, у AMD open64.
Угу, а драйвер Intel OpenCL использует LLVM, HSA компилятор от AMD использует LLVM. nVidia использует LLVM для CUDA.
> Угу, а драйвер Intel OpenCL использует LLVM,И где у интеля LLVM в драйвере? И где, собственно. сам драйвер с opencl? Им все ипут на этот счет мозг, но готового результата нет.
>Главное преимуществ LLVM в скорости компиляции.В свое время я это проверял,
взял свой проект(c++), благо там билд система основана на cmake,
и собрал с помощью clang и gcc, время было практически одинаково: 1 мин 40 сек на 4 ядерном проце +- 5 сек,
так что с учетом того, что и код он оптимизирует похуже использовать его не вижу смысла.
Во-первых, на богатом темплейтами коде clang из svn месячной давности c -O2 у меня компилирует куда шустрее, чем gcc 4.7 с -O2, процентов на 20. Правда, тут уже смотреть надо, что именно включает -O2 для каждого из компиляторов.Во-вторых, у clang куда понятнее сообщения об ошибках, это надо признать. Особенно с теми же темплейтами. Даже gcc 4.7 пока еще не сравнится (4.8 не пробовал, впрочем).
> Главное преимуществ LLVM в скорости компиляции.Преимущество LLVM перед чем? Может, ты имел в виду "преимущество clang перед gcc и g++"? Так новость не о нём вообще-то, а об LLVM. Если говорить о преимуществах LLVM перед GCC (который GNU Compiler Collection, а не GNU C Compiler), как минимум одно очевидно — GCC нельзя использовать в качестве JIT-компилятора, в отличии от.
Если, конечно, считать это преимуществом.
> Если, конечно, считать это преимуществом.Иногда это может и преимуществом быть. Но очень нишевым. Ну да, из GCC неудобно делать генерилку кода для GPU, а самолично писать парсер opencl-ного диалекта си может и подзадолбать. Вот где-то там оно даже осмысленно. Хотя даже там с ним амд намучались по полной программе, с превышением.
вообще-то одно из нехилых преимуществ *llvm* в том, что это очень неплохая библиотека для jit- и aot- компиляции, которую можно встраивать в свои проекты. а так — я не знаю, пишет ли кто-то вручную на ассемблере llvm. вряд ли.а clang — это немного другой проект, вообще-то.
> вообще-то одно из нехилых преимуществ *llvm* в том, что это очень неплохая
> библиотека для jit- и aot- компиляции, которую можно встраивать в свои проекты.Кстати да, как портабельная генерилка кода для всяких там GPU и прочая - ну вроде нормально смотрится. Если разовьется до достойного уровня как кодогенератор представляющий ценность - так оно и к gcc через плагины привинчивается. Другое дело что качество кодогенерации там оставляет желать и смысл этим пользоваться - в районе нуля.
>> вообще-то одно из нехилых преимуществ *llvm* в том, что это очень неплохая
>> библиотека для jit- и aot- компиляции, которую можно встраивать в свои проекты.
> Кстати да, как портабельная генерилка кода для всяких там GPU и прочая
> - ну вроде нормально смотрится. Если разовьется до достойного уровня как
> кодогенератор представляющий ценность - так оно и к gcc через плагины
> привинчивается. Другое дело что качество кодогенерации там оставляет желать и смысл
> этим пользоваться - в районе нуля.А будет пример тестов (кроме OpenMP) в которых Clang/LLVM, DragonEgg/LLVM, сильно проигрывают GCC?
> А будет пример тестов (кроме OpenMP) в которых Clang/LLVM, DragonEgg/LLVM, сильно проигрывают
> GCC?да запросто. берём MIPS. собираем что-нибудь при помощи gcc. запускаем. собираем что-нибудь… wait! oh, shi~~~
Вы лично работаете с MIPS? Или ARM, в крайнем случае?Хотите пользоваться GCC пользуйтесь, или кто-то не дает? А орать, что что-то не нужно, по причине, что оно вам не нравится, не стоит
> Хотите пользоваться GCC пользуйтесь, или кто-то не дает? А орать, что что-то
> не нужно, по причине, что оно вам не нравится, не стоитarisu тут один из немногих вменяемых, который не орёт "не надо". пройдитесь по треду.
> А орать, что что-то не нужно, по причине, что оно вам не нравится, не стоити где я орал «не нужно»? ты попросил показать, когда clang/llvm сильно проигрывает. я показал: проигрыш бесконечен. с чего ты решил, что это равносильно «не нужно» — я не знаю.
> А будет пример тестов (кроме OpenMP)Ага, сразу отмазки начались - видио вы в курсе что в ряде проектов слив в разы :)
> в которых Clang/LLVM, DragonEgg/LLVM, сильно проигрывают GCC?
Для начала можно посмотреть как с этим амдшники мумукались. Там просто получить технически валидный поток команд для VLIW - целая эпопея. Про оптимизацию речь вообще не идет!
Крутая архитектура, крутые концепции, а про то что бывают VLIW-образные процессоры авторы этой поделки не просто не слышали но и в своих архитектурах и концепциях не допустили ни малейшей возможности что такое может существовать. Поэтому кодогенерация VLIW привинчена через феерические костыли. Отдельная фаза постпроцессинга разбирает тот бред который нагенерил LLVM и переупорядочивает код до состояния когда он хотя-бы будет технически валиден. Сам по себе LLVM этого вообще не может. Про то чтобы оптимально группировать команды в группы - речь и вовсе не идет.
В результате через 2 года траха у амдшников привели к тому что оно после этого на генерации шейдеров не очень сливает местечковому самопальному кодогенератору, куда более простому. Итого? Два года въе нескольких разработчиков vs НУЛЕВОЙ видимый юзеру результат. Налицо success story из разряда "как дурной прожект менеджмент может все хорошенько отфакапнуть".
>> А будет пример тестов (кроме OpenMP)
> Ага, сразу отмазки начались - видио вы в курсе что в ряде
> проектов слив в разы :)На самом деле все из-за того, что OpenMP доступен не под gpl только для GCC:
http://habrahabr.ru/post/184096/
А как это происходит в Open64, или в другом многоархитектурном компиляторе?
> CUDA Compiler - позволяет сгенерировать GPU-инструкции из кода, написанного на языках Си, Си++ и Fortran;Не понял, безотносительно к типу GPU (производителю)?
Да, если этот производитель nvidia.зыж
по ссылке уже что ли шлёпнул бы.
а там и комменты почитал.
LLVM развивается в нужную сторону. Скоро он станет отличной альтернативой GCC, даже для сборки Linux. Интересно, какой дистрибутив первым наладит процесс сборки с использованием сабжа?
> LLVM развивается в нужную сторону. Скоро он станет отличной альтернативой GCC, даже
> для сборки Linux.
> Интересно, какой дистрибутив первым наладит процесс сборки с использованием сабжа?FreeBSD давно уже собирается LLVM/Clang, а линуксу нужны какие-то нанотехнологичные патчи в самом LLVM/Clang и в своих исходниках.
> давно уже собираетсяя давно уже собираюсь стать миллиардером
Очки протри. Уже собирается, а не собирается начать собираться.
всё, линуксокапец пришёл!
> Скоро он станет отличной альтернативой GCC,...и под всякую эмбедовку нас опять начнут пичкать проприетарными SDK? Спасибо, это мы уже проходили. Добавки не надо. Корпорасты - это такие существа, которым дай волю и они термоядерные ковровые бомбардировки учинят. Если это сулит профит.
> Интересно, какой дистрибутив первым наладит процесс сборки с использованием сабжа?
Гента какая-нибудь, которым вечно дурь разработчиковскую девать некуда.
> LLVM развивается в нужную сторону. Скоро он станет отличной альтернативой GCC, даже
> для сборки Linux. Интересно, какой дистрибутив первым наладит процесс сборки с
> использованием сабжа?Debian, где-то была новость, что они собрали 80%, или больше своего репозитория, кроме ядра.
"Для разработчиков, использующих vim и emacs, представлен плагин "Clang Format", выполняющий функции интеллектуальной системы автоматического форматирования кода."clang-format - это не плагин для вима с емаксом, а отдельная программа, выдающая отформатированный код в stdout
> В компиляторе Clang полностью завершена реализация поддержки всех
> компонентов стандарта C++11, в том числе новых библиотек, таких как std::regex.Врут.
Не реализовано:
1) Minimal support for garbage collection and reachability-based leak detection
2) Abandoning a process and at_quick_exit
3) Extended integral types
Ну а что вы ожидали от эппла? Громкий маркетинговый буллшит - штука такая.
> Ну а что вы ожидали от эппла? Громкий маркетинговый буллшит - штука
> такая.А может расскажешь нам, как компилятор может брать на себя работу стандартной библиотеки в случае at_quick_exit, или зачем делать "reachability-based leak detection," если уже есть инструмент основаный на LLVM, который реализует данную функциональность? От Apple там только 5 разработчиков, все остальное из других компаний индустрии.
Стандартная библиотека это часть языка. И у clang она своя. Это раз.Два - они же в анонсе хвастают в том числе и фичами стандартной библиотеки, например тем же std::regex.
Три - "reachability-based leak detection" нужен просто потому, что он есть в стандарте. Без него реализация не полна.
затем, чтобы не врать в заявлении о «полной реализации всех компонентов стандарта». если что-то не сделано, то это никак не «полная реализация». усёк?
Если что-то не нужно делать, его не нужно делать.И, arisu, меньше яду...
> Если что-то не нужно делать, его не нужно делать.вот именно. если полной реализации нет — не нужно писать, что она есть.
> А может расскажешь нам, как компилятор может брать на себя работу стандартной
> библиотеки в случае at_quick_exit,Внезапно, стандартная либа обычно с компилером поставляется. Или где-то рядом.
> или зачем делать "reachability-based leak detection,"
Хорошая отмазка - "это не нyжно, так яппл сказал" :). Так, а что там еще посчитали "лишним" в погоне за маркетинговым буллшитом? :)
> От Apple там только 5 разработчиков,
При том clang только они и пилят по сути. А остальные - ну да, там LLVM всякий пилят и что еще.
они уже запилили поддержку nested functions и http://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html ? или для qsort надо по-прежнему писать отдельную функцию, которой даже параметр не передашь?
> они уже запилили поддержку nested functions и http://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html
> ? или для qsort надо по-прежнему писать отдельную функцию, которой даже
> параметр не передашь?GNU C не является стандартом, и если вам нужно используйте, более человеко любивые языки
>GNU C не является стандартомОн очень туда просится, но в комитете к сожалению одни наркоманы.
> GNU C не является стандартомно это ни разу не причина не использовать удобства, оным предлагаемые. то, что в комитете по стандартизации сидят дауны — тем более не причина. особенно это не причина не реализовывать удобства. ибо две вещи, которые я назвал, при скрещивании дают офигенно удобные лямбды.
#define lambda(_return_type, _body_and_args) ({ \
_return_type __fn__ _body_and_args \
__fn__; \
})...
int ascending;
...
qsort(array, 42, sizeof (int), lambda (int, (const void *a, const void *b) { return (ascending ? (*(int*)a)-(*(int*)b) : (*(int*)b)-(*(int*)a)); }));разве не красота? особенно если учесть, что лямбда имеет доступ к переменным функции-родителя, как это показано в коде выше. понятно, что пример синтетический, первая придуманая иллюстрация.
и да, я это активно использую. именно потому, что удобно. я не прочь сравнивать gcc и clang/llvm, но последний никак не может собрать мой софт. пичалечка.
> разве не красота? особенно если учесть, что лямбда имеет доступ к переменным
> функции-родителя, как это показано в коде выше. понятно, что пример синтетический,
> первая придуманая иллюстрация.Хм, симпатичненько.
да и вообще, nested functions весьма способствуют удобной и красивой организации кода без геморроя с передачей кучи параметров и без загаживания namespace. макросы не предлагать, это ужос-ужос-ужос.
Обновился:
% cc --version
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
Target: x86_64-unknown-freebsd9.1
Thread model: posix