Дэвид Малколм (David Malcolm), активный разработчик GCC из компании Red Hat, опубликовал (http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00228.html) прототип библиотеки libgccjit.so с реализацией встраиваемого в приложения JIT-компилятора, использующего GCC в качестве бэкенда. Данная библиотека может быть динамически связана с интерпретаторами байткода и другими программами, которым необходима генерации машинного кода на лету, во время выполнения.Идея проекта состоит в том, что GCC собирается в форме позиционно-независимого кода (http://ru.wikipedia.org/wiki/%D0%9C%D0%B... который присоединяется к библиотеке libgccjit.so, что позволяет обеспечить возможность выполнения GCC в одном процессе с генерируемым машинным кодом. Инициирование компиляции и выполнения откомпилированных на лету блоков кода производится приложением при помощи специально предоставленного библиотекой API. Первый прототип проекта поддерживает JIT-компиляцию кода на языке Си, но уже началась подготовка биндинга для языка Python.
Другим интересным проектом, является опубликованный (http://gcc.gnu.org/ml/gcc/2013-09/msg00235.html) разработчиками из компании Samsung модифицированный вариант GCC с интегрированной поддержкой стандарта OpenACC 1.0 (http://ru.wikipedia.org/wiki/OpenACC). Указанный вариант GCC даёт возможность сформировать исполняемый файл, позволяющий в процессе работы программы вынести выполнение некоторых вычислительных операций на плечи GPU.
URL: http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00228.html
Новость: http://www.opennet.ru/opennews/art.shtml?num=38075
Чем оно лучше LLVM?
Килотонны петабайт исходников не надо будет переписывать.
> Килотонны петабайт исходников не надо будет переписывать.Правильно написанный исходник не нужно бывает переписывать.
> Правильно написанный исходник не нужно бывает переписывать.Да, в случае сферического коня в идеальном вакууме... (с) анекдот :)
Нет, в случае нерукожопого программиста. Переход FreeBSD на clang показал что таких, к счастью, большинство - clang'ом не собиралось не больше десятка процентов портов, из них большая часть исправлялась добавлением пропущенного #include (что, кстати, значит что в gcc'шной libstdc++ инклудится лишнее, если она это жрала), с USE_GCC остались единицы с реальными gcc'измами.
напомни, сколько шлангу пришлось из-за этого поддерживать гнутых/гцц-шных расширений?
> напомни, сколько шлангу пришлось из-за этого поддерживать гнутых/гцц-шных расширений?при этом две самые полезные фичи так и не поддерживает: nested functions и statement expressions.
оно понятно, что хардкорные фанаты тверды в своём принципе «что было хорошо для наших дедов и отцов — то хорошо и для нас», но эти две фичи, как я уже писал, без мегаусложнения компилятора дают приятные бонусы. например, удобные однострочные макросы min/max, вычисляющие аргументы ровно один раз, или нечто вроде лямбд для тех же qsort()/bsearch(), которые (вроде-лямбды) могут быть объявлены прямо параметром и напрямую обращаться к переменным родительской функции.
но это, конечно, не Ъ.
а так же дают постоянный исполняемый стек, что открывает простор для написания экслойтов :-)
пшёл вон, мразь.
> а так же дают постоянный исполняемый стек, что открывает простор для написания
> экслойтов :-)Пошёл gcc патчить, м*азь.
>при этом две самые полезные фичи так и не поддерживает: nested functions и statement expressions.Для кода, не соответствующего стандарту, не может быть оправданий. И пофиг, гнутые это расширения, или мелкософтовские.
мне как-то совершенно плевать на идиотские стандарты. стандарт на си особенно идиотский, с его «поведение неопределено» и принципиальным невключением удобных вещей. меня волнует не чтобы стандарту было хорошо, а чтобы мне было удобно. поэтому я использовал и буду использовать gcc-шные атрибуты (в частности, любимые constructor, destructor, cleanup), вложеные функции и выражения-операторы.в отличие от стандартов, которые придуманы космическими академиками для облегчения жизни компилерописателям, эти расширения были придуманы программистами для облегчения жизни себе и другим программистам. а также реализованы в самом распространённом компиляторе, который портировали на огромное количество систем. поэтому они — стандарт де-факто. кто не согласен — тот может ними не пользоваться, его право.
> И пофиг, гнутые это расширения, или мелкософтовские.GCC доступен под туеву хучу архитектур и желающие могут впилить туда свою новую архитектуру, если им это надо. MSVS этим похвастаться не может, что и является основной предъявой.
Да, gcc может мне код и для AVR'ки мелкотравчатой сгенерить. Будучи запущен в линухе, как 64-битный ELF-бинарник. MSVS так невозможно изогнуть в принципе, по поводу чего и предъявы, собственно.
> Нет, в случае нерукожопого программиста.Наверное это был сам Юрий Нежопорукий.
> Переход FreeBSD на clang показал что
...что они х#$рят на своей волне и ни с кем не считаются, ставя свои лицензионные бзики выше получаемого на выходе результата.
> ...что они х#$рят на своей волне и ни с кем не считаются,
> ставя свои лицензионные бзики выше получаемого на выходе результата.это вы о большинстве линуксоидных программистов? которые слов c-std .., POSIX, SUS боятся как огня ?:)
> это вы о большинстве линуксоидных программистов?Это о общей логике развития FBSD. Эталонный пример того как не надо рулить проектом - выбрасывать сие начали даже старые зубры типа ях и апачей, у которых оно по историческим причинам было. И как вы понимаете, если что-то выбрасывают - то в основном потому что много мороки с неочевидным результатом.
> которые слов c-std .., POSIX, SUS боятся как огня ?:)
Все это имеет довольно косвенное отношение к вменяемости управления проектом.
Выше скорость генерируемого кода, поддерживает большое количество платформ, нет зависимости от одной компании, свободная лицензия.
в общем, если поскипать бред, то получается, что преимуществ-то и нет. Сейчас все новые компиляторы, трансляторы и т.п. или пишутся с нуля, или используют LLVM в качестве бэкенда, а GCC с его обфусцированной архитектурой (привет параноику Столлману) никому нафиг не нужен :)
> никому нафиг не нужен :)Ну да, кроме вон той толпени корпорасов типа IBM, интелов и еще 100500 всяких, билдующих им себе линух для своих железяк.
Да ты что, а это что по твоему? http://www-03.ibm.com/software/products/us/en/ccompfami/
> Да ты что, а это что по твоему? http://www-03.ibm.com/software/products/us/en/ccompfami/Понятия не имею что это. Зато догадываюсь чем они собирают ядро линя и софт под свой любимый power, например. Наверняка это gcc, да :).
А почему Oracle Solaris Studio свой компилятор включает ?Зачем Intel свой компилятор продаёт ?
Зачем AMD пилит свой форк Open64 ?
Зачем IBM продаёт XL ?
Зачем The Portland Group продаёт свой компилятор ?
Это великие IT-компании, у которых достаточно компетенции для реализации своих собственных компиляторов. У Red Hat такой компетенции нет и они используют GCC.
GCC нужен ТОЛЬКО для компиляции ядра Linux и другого ПО, которое использует костыли от GCC (его очень мало). В ядре Linux содержатся куча костылей. Эти костыли используют костыли из GCC. Вот и всё.
Apple выкинула GCC и FreeBSD тоже.
Реально GCC НЕ НУЖЕН !
Лучше спросите зачем все это покупают.И кстати компилятор из Solaris Studio жуткое уе.ище.
Ну да. Давайте теперь каждую программу тестировать в разных компиляторах вместо одного и собирать не только для разной архитектуры, но и производителя, ура товарищи, ура!
А заодно напомните, кто реально для работы на ПК(а не узкоспециализированном железе одной фирмы) будет это делать, заранее спасибо.
> Ну да. Давайте теперь каждую программу тестировать в разных компиляторах вместо одного
> и собирать не только для разной архитектуры, но и производителя, ура
> товарищи, ура!Не "давайте", а все нормальные люди так и делали всегда, потому что это повышает шанс ловли ошибок и несовместимостей. Посмотрите хотя бы travis ci, оно по умолчанию давно поддерживает как минимум gcc и clang. Но куда GNU'шным проприетарщикам это понять - у них одна архитектура - бyбунту.
шланг с его хроническими болячками намного проще объявить неподдерживаемым и не заморачиваться. оно до сих пор в оптимизации inline-функций косячит, ну нафиг такие грабли.
> оно до сих пор в оптимизации inline-функций косячит,Жесть как она есть...
>> оно до сих пор в оптимизации inline-функций косячит,
> Жесть как она есть…справедливости ради: это скорее разница в поведении на сборке программы с неопределённым поведением, чем реальный косяк кланга. тем не менее, «принцип наименьшего удивления» кланг не соблюдает. по моему мнению — стоило бы.
> А почему Oracle Solaris Studio свой компилятор включает ?Потому что у санок вечно NIH был. Кстати, данный компилер - набор грабель и костылей, судя по отзывам "счастливчиков". Нафиг это ораклу? Думаю лишь потому что они по инерции катится с технологиями саней. Скорее всего они с их управлением сие утопят, вместе с солярисом. Барыжить базами можно и под линух, с ним даже удобнее: не надо пилить все в 1 рылo + под их базы лучше подойдет с btrfs-ом, в котором еще на этапе дизайна нужные ораклу рукоятки заложили, благо в те времена архитект у них и работал. Не вижу глобальных долговременных перспектив этого добра.
> Зачем Intel свой компилятор продаёт ?
Честно говоря - я не совсем понимаю. Наверное "они так привыкли". Ну то-есть начальная идея имела некий пойнт - генерация более качественного кода под их CPU. Но учитывая что они же стали коммитить оптимизацию и поддержку новых команд в GCC, я честно говоря все меньше понимаю смысл существования этой фигни. Судя по тому как много народа пользуется icc - не только я. Ну если полутора землекопам на всю планету оно полезно и интелу не в облом ради них это майнтайнить - да и флаг им в руки, вам жалко чтоли?
> Зачем AMD пилит свой форк Open64 ?
Еще одна загадка природы. Наверное их ответ чемберлену на icc. Реальных применений оного я вообще ни разу не встречал.
> Зачем IBM продаёт XL ?
Не знаю. Ну то-есть, могу предположить что они денег хотят, как и все корпорасы. Но если они хотят иметь дело с линухом и софтом в нем - там gcc и баста. И никто их спрашивать не будет. Т.к. для IBM компилеры явно не основная часть их бизнеса - думаю что они вполне себе будут допиливать gcc под свой power. Ну или их будут прижимать x86 и ARM, уж как им там удобнее.
> Зачем The Portland Group продаёт свой компилятор ?
Мало ли кто и чего продает в этом мире. Наверное тоже денег хочет. Ну, пусть хочет. Посмтрим много ли получит.
> Это великие IT-компании, у которых достаточно компетенции для реализации своих
> собственных компиляторов. У Red Hat такой компетенции нет и они используют GCC.А интель тогда с фига ли патчи в gcc шлет? Или там гугель например?
> GCC нужен ТОЛЬКО для компиляции ядра Linux и другого ПО, которое использует
> костыли от GCC (его очень мало). В ядре Linux содержатся куча
> костылей. Эти костыли используют костыли из GCC. Вот и всё.Уточним: gcc сроду использовался для всего этого. Это работает. При том довольно хорошо. За годы там более-менее поудавили баги и догнали оптимизацию до довольно приличного состояния, когда оно без проблем вставляет даже MSVS-у, считавшемуся когда-то лучшему по оптимизации.
> Apple выкинула GCC и FreeBSD тоже.
Я так рад за проприерасов и их подстилок. А мне какое до них дело?
> Реально GCC НЕ НУЖEН !
Кому? Проприерасам и их подстилкам? Окей, пусть идут на...й, я не возражаю :).
"gcc не нужен"... это... сильно. таких жирнючих троллей ещё не было. моё почтение.
> А почему Oracle Solaris Studio свой компилятор включает ?Исторические причины + значительно лучшая кодогенерация под SPARC. Впрочем, есть проект гибрида GCC и SunCC. К сожалению, компилятор Oracle последнее время развивается ужасно и c++11 ещё не поддерживает от слова совсем.
> Зачем Intel свой компилятор продаёт ?
Для лучшей оптимизации под свои процессоры. Относительно недавно был даже скандал, связанный с тем, что в сторонних процессорах эти компиляторы не включали возможные оптимизации.
> Зачем AMD пилит свой форк Open64 ?
См. выше - на icc далеко не уедешь.
Про остальных не знаю.
> Это великие IT-компании, у которых достаточно компетенции для реализации своих собственных
> компиляторов. У Red Hat такой компетенции нет и они используют GCC.Вообще-то, разработчики C++ тестируют перспективные фичи, вставляя их в код GCC. Скажем, непрошедшие в стандарт Concepts были реализованы для GCC.
> GCC нужен ТОЛЬКО для компиляции ядра Linux и другого ПО, которое использует
> костыли от GCC (его очень мало).Это компилятор по-умолчанию в Linux'ах. Т.е. на данный момент это основной C/C++ компилятор.
> Это компилятор по-умолчанию в Linux'ах. Т.е. на данный момент это основной C/C++
> компилятор.более того: это компилятор, вероятность наличия которого на какой-нибудь хитрой системе (или возможности поставить порт) очень близка к единице. поэтому имеет смысл писать код так, чтобы его мог прожевать gcc, а остальными компиляторами заморачиваться только по мере неленивости.
Хм, ну покажи мне хоть как-то живую систему, на которую не портирован GCC. Пусть даже из твоих полумертвых "каноничных" юниксов.
> да да.. это как писать сайты имеет смысл под IE, так как
> вероятность его наличия близка к 1..Это только если рассматриваем десктоп. На планшетах и телефонах вероятность наличия IE нулевая. Поэтому писать сайты имеет смысл под Chrome, правда не забывая про IE и FF.
> А всякие линуксоиды с их 1% рынка - не интересны не капли.. ведь верно ?
Для кого? Для общеупотребительного десктопного софта Linux неинтересен. Для серверов (в том числе и серверов приложений) - вполне. Для планшетов/смартфонов очень интересен.
> хотя если для тебя система ограничивается только Linux - то да вероятность
> gcc близка к 1.. А если посмотреть чуть чуть шире -
> то окажется что это далеко не так.Вопрос - по каким критериям отфильтровываем. См. выше.
> На планшетах и телефонах вероятность наличия IE нулевая.А как же виндовс фон? Хотя я согласен - лучше считать его за ноль :)
> Поэтому писать сайты имеет смысл под Chrome,
А я думал - по стандартам. А вот кто хреново поддерживает стандарты (да, я смотрю на вас, неуважаемые индусы из IE team) - сам себе злобный буратино.
> Для кого? Для общеупотребительного десктопного софта Linux неинтересен.
А valve в курсе этой фигни? :)
>> никому нафиг не нужен :)
> Ну да, кроме вон той толпени корпорасов типа IBM, интелов и еще
> 100500 всяких, билдующих им себе линух для своих железяк.Тем временем парни из IBM уже запилили LLVM и Clang для Power и System Z.
> Тем временем парни из IBM уже запилили LLVM и Clang для Power и System Z.Осталось всего ничего: спустить фанатизм в унитаз и честно сообщить нам сколько лет gcc так уже умеет.
Вам повторить про более лучшую оптимизацию и большее количество поддерживаемых платформ/архитектур?
> Вам повторить про более лучшую оптимизацию и большее количество поддерживаемых платформ/архитектур?бессмысленно, оно в этом ничего не понимает. достаточно пассажа про «обфусцированую архитектуру», чтобы это понять.
> бессмысленно, оно в этом ничего не понимает. достаточно пассажа про «обфусцированую
> архитектуру», чтобы это понять.Что-то НеОбфусцированная архитектура LLVM оказалась настолько не готова к тому что на этой планете бывает VLIW, что АМДшники 2 года долбались чтобы получить на выходе хотя-бы просто технически валидный код.
Итого? Два года долботни разработчиков с нулевым user-visible результатом. Потом приходит некий Vadim Girlin - "ребята, да вы офигели - два года въ...ть без результата видимого юзерям?" и за весьма короткий срок фиксит подобный булшит в отдельном довеске, который парсит код и оптимизирует его. Что характерно - оказалось проще сделать сие вообще без услуг LLVM, отдельной сущностью, так что этот бэкэнд работает и для LLVM и для местечкового кодогенератора. Такая супер-архитектура и success story от ее внедрежа...
да тут начинать надо с того, что никакой «обфусцированой архитектуры» в gcc нет: надо просто иметь рабочие мозги и понимать предметную область.llvm же вполне хорош — для своих применений. правда, там с дизайном совсем не радуга с поняшами, но и это тут обсуждать смысла нет: фанбои тупые, а те, кому интересно состояние дел, и так знают.
> llvm же вполне хорош — для своих применений.А с этим никто и не спорит. Просто объем маркетингового буллшита текущего из некоторых мозгов - утомил.
> А с этим никто и не спорит. Просто объем маркетингового буллшита текущего
> из некоторых мозгов — утомил.казалось бы: при чём тут огрызок…
Скоро окажется, что gpu работает наравне с cpu и последний можно убрать. Потом окажется, что gpu можно разгрузить, добавив cpu. Ну вы поняли.
> Скоро окажется, что gpu работает наравне с cpu ...Еще лет 7-8 назад один из разрабов Nvidia вывалил на сайте developer.nvidia.com,
что они запускали ядро Linux на GeForce, вроде 6800GT. Пост исчез в течении двух дней,
разраба никто больше не слышал. :)Чуть раньше, когда CUDA и OpenCL в планах даже не было, один чувак,
реализовал функции сортировки, сравнения строк на Жыфорсе. Его сайт
жил дольше, но не обновлялся ни разу.
Не в начале апреля пост был?
Симшьно, ща уписаюсь http://www.cs.utah.edu/~wbsun/gpustore.pdf
Кстати, на Опеннете новость была.
За вами тоже уже выехали.
Извинитесь.
http://www.opennet.ru/opennews/art.shtml?num=23833 nVidia Fermi сможет выполнять Linux
http://www.opennet.ru/opennews/art.shtml?num=30484 Проект KGPU позволяет задействовать GPU для выполнения фрагментов кода ядра Linux
Это завязано на CUDA и блободрайвере, что для ядра сильно-сильно не айс. Вот если будет VAAPI и nouveau (radeon), то тогда да.
> CUDA... VAAPI и nouveau (radeon)Какие еще слова знаешь?
Wiki всем доступно, можешь и ты просветиться :)
> Вот если будет VAAPIИ как именно апи для декодирования видео относится к вычислениям на GPU? :)
А ещё был более-менее реальный proof of concept червя, живущего исключительно в памяти GPU и в ROM'е broadcom'овской сетевухи (она там тоже такая типа вся программируемая), и слущающего трафик.
Это никогда не случится :) Вы не особо представляете как вообще GPU работает. Для некоторых алгоритмов намного быстрее, а для некоторых наоборот намного медленнее. А вот решения AMD CPU + GPU - APU вполне жизнеспособны, как в свое время CPU + FPU.
Странная эта борьба за новые языки и возможности. Все время пытаются сделать лазерный скальпель, когда вогруг все пилят только деревья. Надо бы культуру программирования и технологии в массы подтянуть, а не переизобретать очередной велосипед на очередном языке.
Речь скорее идет о изобретении инструментов переноса старого кода и инструментов в новые условия. Что с того, что новые условия это не лесопилка, а что то потоньше? Уровень среднего программера остается неизменным.
>но уже началась подготовка биндинга для языка Python.Отличненько, - горю желанием заценить!
забавно, конечно, но редкостные извращенцы. что этот, что llvm-щики.
На миллионyю по счету просьбу засветить свой код, который лучше, будет традиционное мужественное самоотверженное молчание ? Часто незнакомых людей "редкостными извращенцами" в лицо называешь?
> На миллионyю по счету просьбу засветить свой код, который лучше, будет традиционное
> мужественное самоотверженное молчание ? Часто незнакомых людей «редкостными извращенцами»
> в лицо называешь?проси на здоровье, за спрос денег не берут.
> забавно, конечно, но редкостные извращенцы. что этот, что llvm-щики.Предложи более прямой способ сгенерить шейдеры для GPU, например? Как ты понимаешь, заранее вообще неизвестно что там у юзеря: ати, нвидия, интел или вообще какой-нить ARM. Поэтому программа явно не может таскать с собой для этого предкомпилированный код.
>> забавно, конечно, но редкостные извращенцы. что этот, что llvm-щики.
> Предложи более прямой способ сгенерить шейдеры для GPU, например? Как ты понимаешь,
> заранее вообще неизвестно что там у юзеря: ати, нвидия, интел или
> вообще какой-нить ARM. Поэтому программа явно не может таскать с собой
> для этого предкомпилированный код.Вы прям так спрашиваете как будто arisu разбирается в компьютерах и не просто так брякнул.
не мешай ему дилетанствовать c самовлюбленным апломбом, вон уже чуть ниже поток полился про "ощущения чуйств" на тему GCC. Замени GCC и LLVM на Коллайдер и систему жизнеобеспечения автономного модуля на Марсе, впрочем и митохондрии подойдут - суть не поменяется. Костьми ляжет, но ни слова не дождешься о конкретных проверяемых сущностях.
(пожимает плечами) конкретная сущность — это намертво зависающий движок регулярок, нежно портированый из plan9 и допиленый. тупой шланг не врубается, что inline-функция может модифицировать некоторые переменные, передаваемые ей в структуре (хотя никакого const там нет), поэтому сначала переменную где-то кэширует, а потом использует её старое значение. в итоге получается бесконечный цикл вида «jmp $». чего лично я от компилятора такого возраста никак не ожидал и был несколько в офигее, когда софтина подвисла, слопав весь процессор.но я понимаю, что для тебя «я наступил на баг в компиляторе» — ситуация вообще невозможная, потому что твой «приветмир» без ворнингов вообще не собирается. какие уж там баги компилятора…
Красиво приложил :).
> нежно портированый из plan9 и допиленый. тyпой шланг не врубается,Мсье, что вы, как можно, эппл на такие навороты не рассчитывал. Так что будем слушать вопли фанатиков "это не нyжно!!!111".
вот, кстати, только что в списке рассылки Lua пришло:
> I got burned by that particular clang version. At least on 32-bit
> platforms, it makes a mess of compiling something relatively
> straightforward like Lua 5.2. You will have to switch off
> optimization for liolib.c for it to work.
> вот, кстати, только что в списке рассылки Lua пришло:Справедливости ради - почитай логи коммитов к амдшному окрытому драйверу :). GCC там тоже досталось на орехи, пришлось баг воркэраундить :)
так я и на gcc-шные баги наступал. как-нибудь под настроение — если вспомню — и его попинаю. но кланг пинать забавней.
> тупой шланг не врубается, что
> inline-функция может модифицировать некоторые переменные, передаваемые ей в структуреЭто какая версия компилятора? Т.е. код
struct z_t
{
int a;
int b;
};inline void f( z_t * z)
{
z.a = 1.0;
}он откомпилирует неправильно?
> Это какая версия компилятора?3.3.
> он откомпилирует неправильно?
не знаю и проверять лень. там функция несколько сложнее, возвращает тоже структуру и используется в виде funcall(ss)->fld = ss->fld1, при этом ss->fld1 внутри функции меняется. но шланг этого не понимает, и использует старое значение.
p.s. собственно, после раздумий я не уверен, ошибка ли это компилятора, или идиотизм стандарта с очередной «неопределённой последовательностью». но принцип least surprise явно поломан, это раз. и два — если поведение неопределено, то компилятор должен плюнуть предупреждением.
>> Это какая версия компилятора?
> 3.3.
>> он откомпилирует неправильно?
> не знаю и проверять лень. там функция несколько сложнее, возвращает тоже структуру
> и используется в виде funcall(ss)->fld = ss->fld1, при этом ss->fld1 внутри
> функции меняется. но шланг этого не понимает, и использует старое значение.Выкладывай отпрепроцессенный файл и опции компиляции, я проверю.
Не выложит, это принципиально. Будет тот же графоманский поток околокомпьютеорных мыслей. Очень правдоподобный для не слишком дотошных, но не практике принципе не проверяемый. Вся суть аризу. "я ощущаю что этот концептуальный подход нелогичен, скучен и приличный человек не будет пользоваться". Спроси про делали и конкретные строки кода или патч - получишь в ответ еще более пространный графоманский водевиль с оскорблениями. Гланвое - ни строки кода.
> Не выложит, это принципиально. Будет тот же графоманский поток околокомпьютеорных мыслей.Милый Аноним, вы тоже не понимаете, что заниматься социальными игрищами, надев маску, нельзя?
> Выкладывай отпрепроцессенный файл и опции компиляции, я проверю.http://www.opennet.ru/openforum/vsluhforumID3/91996.html#133
ты мне гешефт поломал, кстати: я-то надеялся, что денег дадут за сэмпл.
> p.s. собственно, после раздумий я не уверен, ошибка ли это компилятора, или
> идиотизм стандарта с очередной «неопределённой последовательностью». но принцип
> least surprise явно поломан, это раз. и два — если поведение
> неопределено, то компилятор должен плюнуть предупреждением.В том виде, что ты написал, это очень похоже на неопределённое поведение. Причём тут даже C++-ом не пахнет, чистый C.
И, мне кажется, что именно в таких местах мы и получаем пользу от clang'а.
> Причём тут даже C++-ом не пахнет, чистый C.я про си и говорил.
> И, мне кажется, что именно в таких местах мы и получаем пользу
> от clang'а.нулевую. польза — это если бы меня преупреждением обругали. а так — молча делают фигню. почему фигню? потому что принцип «наименьшего сюрприза» диктует ровно обратное тому, что делает кланг. я в упор не помню, что там в стандарте по этому поводу написано (там вообще фигни столько написано, что и у коня голова лопнет), но в приличных домах о явно неприличном поведении принято предупреждать. молчат же оба — и кланг, и гцц.
впрочем, я сильно подозреваю, что это действительно неопределённое поведение, просто у компиляторов не хватило сил его заметить. и, в общем-то, зря я на кланг накинулся — на то оно и неопределённое.
> нулевую. польза — это если бы меня преупреждением обругали.Стат. анализатор у clang'а говно, хотя попробуй, прогони его, авось ругнётся. А для предупреждения эта штука слишком сложна - нужно проанализировать код внутри функции и убедиться, что таки да - меняет поле.
> я в упор не помню, что там в стандарте по этому поводу написано (там вообще фигни столько написано, что и у коня голова лопнет)
Язык C староват очень.
>> нулевую. польза — это если бы меня преупреждением обругали.
> Стат. анализатор у clang'а говно, хотя попробуй, прогони его, авось ругнётся.его, вроде, отдельно собирать надо. потом попробую как-нибудь, git всё помнит, если что.
> для предупреждения эта штука слишком сложна — нужно проанализировать код внутри
> функции и убедиться, что таки да — меняет поле.ну, там сразу перед return'ом ++ стоит, в принципе, ничего заковыристого. обычный data flow analysis, его и так делают.
>> я в упор не помню, что там в стандарте по этому поводу написано (там вообще фигни столько написано, что и у коня голова лопнет)
> Язык C староват очень.дык вон недавно очередную ревизию стандарта приняли. фигни насовали, полезного — ноль. ну почему, например, не стандартизировать 2's-complement integer arithmetic? почему integer overflow не прописать? да куча софта пользуется тем, что это стандарт де-факто (хоть хэш-функции взять — куча на этом подвязана). почему не добавить конструкцию для проверки флажка переполнения, который есть у подавляющего большинства процессоров? это ведь офигенно упростило бы те же проверки на переполнение, которые можно было бы делать постфактум.
вот зачем в очередной раз пересматривать стандарт, чтобы бережно не добавлять туда ничего более-менее полезного irl? какого чёрта было плевать на уже введённый в ISO C90 __inline__ и сделать идиотское _Noreturn вместо __noreturn__? да ну их в анус, академиков сферических. я для себя давно решил, что стандарт — это gnu99, со всеми его вкусными расширениями.
> его, вроде, отдельно собирать надо. потом попробую как-нибудь, git всё помнит, если
> что.Уже не надо - http://www.opennet.ru/openforum/vsluhforumID3/91996.html#133
Программа:
8><----------------------------------------------><8typedef struct SSS
{
int a, b;
} SS;SS * f( SS* ss)
{
ss->a = 2;
return ss;
}int main( int argv, char ** argc)
{
SS ss;
ss.a = 1;
ss.b = 3;f( &ss)->b = ss.a;
return ss.b;
}8><----------------------------------------------><8
Компиляция:
[vkni@t60 Arisu.clang]$ gcc test.c -o gcc
[vkni@t60 Arisu.clang]$ clang test.c -o clangКак запускать:
[vkni@t60 Arisu.clang]$ ./gcc ; echo $?
2
[vkni@t60 Arisu.clang]$ ./clang ; echo $?
1Версия gcc: x86_64-alt-linux-gcc (GCC) 4.7.2 20121109 (ALT Linux 4.7.2-alt7)
Версия clang: clang version 3.3 (tags/RELEASE_33/final)
Анализатор clang'а ошибок не выявил: scan-build: No bugs found.
благодарю. могу от себя добавить, что gcc 4.8.1 на x86 тоже никаких ворнингов не даёт. я, кстати, с -O2 собирал.
> Предложи более прямой способ сгенерить шейдеры для GPU, например?предлагаю: унифицировать промежуточную VM для оных GPU, а драйвера пусть при необходимости «докомпиливают» её в родной код. причём поскольку GPU — штуки специфические, то и VM можно сдизайнить соответствующим образом, чтобы на стадии «компиляция в код VM» делалось побольше всего.
но, конечно, наименее костыльный метод — это, я так понимаю, таскать с собой всю механику GCC (которая изначально не предназначена была для подобного использования). или монстра-переростка llvm.
и да: я не уточнил, что подразумеваю использование gcc/llvm именно как jit. это и есть мегаизвращение. что, собственно, доказывает нам Mike Pall со своим LuaJIT2.
> предлагаю: унифицировать промежуточную VM для оных GPU,Уже была попытка, кстати. Называлось сие TGSI, см. http://people.freedesktop.org/~csimpson/gallium-docs/tgsi.html - и оно местами таки юзается. Но на общие вычисления не особо заточено, тому что сейчас в GPU не очень соответствует, и вообще имеет кучу грабель и все на это подзабили. К тому же еще парсить код шейдеров кто-то должен, в том числе и выислительный, а OpenCL уже достаточно приличный кусок от си. Собственно из каких-то таких соображений LLVM нынче и юзают нынче: парсер и генератор кода.
> то и VM можно сдизайнить соответствующим образом, чтобы на стадии «компиляция
> в код VM» делалось побольше всего.Уже было и уже частично пострадало за свою специфичность, т.к. TGSI был слишком ориентирован на графику, а на GPGPU - как-то не особо. А тут до народа дошло что раз есть столько числокрушилок - хорошо бы на них не только графику считать :). Ну вот народ и возится теперь кто с чем.
В конечном итоге это нынче выглядит так: на вход дается сорц шейдера или вычислительного кернела а как оно там его перегонит сие в нативный код GPU - уже проблемы драйвера. При этом виртуальный набор команд не навязывается, там могут быть грабли еще и в том что этот набор менее фичаст чем свойства конкретного GPU который умеет больше нежели это. При компиляции из сорца такая проблема не возникает ессно. А вот внутрях там уже кто как делает. В открытых дровах интел пилит свою собственную реализацию opencl, амдшники поюзали некоторые части gallium и LLVM как генератор кода, etc. Что там у нуво - хрен их знает. Проприерасы IIRC целиком запилили с нуля свои реализации.
> но, конечно, наименее костыльный метод — это, я так понимаю, таскать с
> собой всю механику GCC (которая изначально не предназначена была для подобного
> использования). или монстра-переростка llvm.Сдается мне что gcc не сильно меньше LLVM будет в этом плане. Ну и да, gcc на такое изначально никто вообще не рассчитывал, хотя то что его таки прикрутили и для этого, да еще довольно быстро - внушает. Яблочно-бздoтные фанаты бы оборались тут уже если б их фетиш с такой скоростью кто-то допиливал под разные задачи.
> и да: я не уточнил, что подразумеваю использование gcc/llvm именно как jit.
> это и есть мегаизвращение. что, собственно, доказывает нам Mike Pall со
> своим LuaJIT2.LuaJIT это конечно круто и замечательно, но шейдеры пишутся на чем-то сиподобном, а OpenCL по сути специфичный диалект си. Так что да, кроме JIT надо бы еще и парсер этого самого си-подобного синтаксиса. Для OpenCL его целиком фигачить не вломак оказалось интелу, АМД заломало и они взяли из шланга. Почему не GCC? Ну... они уже 2 года долбутся с этим, 2 года назад сабжа не было :)
как я уже сказал — тут две отдельные ветки беседы надо. JIT в одну сторону, компиляцию шэйдеров — в другую.для шэйдеров и можно, и нужно позвать внешний компилятор. помимо того, что это обезопасит драйвера от ошибок в компиляторе, можно ещё и обновлять раздельно: не надо переустанавливать драйвера, если вышел новый релиз компилятора шэйдеров.
просто в винде создать новый процесс сильно дороже, чем в пингвинусе, вот и занимаются извращениями.
> как я уже сказал — тут две отдельные ветки беседы надо. JIT
> в одну сторону, компиляцию шэйдеров — в другую.Компиляция шейдеров во время выполнения происходит, по поводу чего не вижу глобальных отличий от JIT в плане логики действа, если честно. Единственное чем оно так глобально отличается - сгенеренный код потом не на системном проце выполняется а отправится в GPU.
> для шэйдеров и можно, и нужно позвать внешний компилятор.
Не, спасибочки, еще не хватало чтобы при запуске какойнить игрушки 100500 внешних процессов пахало. Нафиг-нафиг.
> помимо того, что это обезопасит драйвера от ошибок в компиляторе,
Программа все-равно не сможет корректно работать если шейдер или CLный кернель не скомпилился. Если компилер даже совсем навернется где-то в прога -> GL/CL либы -> компилер - да и болт с ним. Нехай чинят, юзери лишний раз прессанут разработчиков чтобы обезглючили эту хрень.
> можно ещё и обновлять раздельно: не надо переустанавливать драйвера,
> если вышел новый релиз компилятора шэйдеров.Компилятор шейдеров не имеет самоценности как отдельная сущность в отрыве от драйверов, которые позволяют то что получилось в GPU запихнуть и запустить.
> просто в винде создать новый процесс сильно дороже, чем в пингвинусе, вот
> и занимаются извращениями.А при чем тут вообще винда? Амдшники в открытом драйвере юзанули, с аргументом что там парсер есть и кодогенератор какой-никакой.
> по поводу чего не вижу глобальных отличий от JITэто потому, что про JIT-ы ты тоже знаешь только три символа, как и про X11.
остальную феерию просто вытер, потому что тут опять «обнять и плакать».
> это потому, что про JIT-ы ты тоже знаешь только три символа, как и про X11.Да это пофигу - общую суть затеи с шейдерами и CL ядрами я усек и вижу что народ тяготеет к сборке этого в рантайме, когда оно по факту понадобилось. Почти как JIT по общей логике получается. А gcc на такое исходно никогда никто не затачивал вообще - он обычный такой компилятор.
> остальную феерию просто вытер, потому что тут опять «обнять и плакать».
Да ну, брось. Ты всякой всякой феерии тоже не меньше генеришь.
А насчет иксов и прочая - я буду пользоваться той графической системой которая будет для меня работать лучше. И это явно не про иксы. Насчет того кто в в чем разбирается: реально разбирается в иксах полтора землекопа на всю планету. Остальные приходят в ужас от увиденного и действительно не разбираются в иксах. Ну или по крайней мере в их коде, являюищмся ужасным месивом костылей и подпорок. Лично мне намного интереснее будет посмотреть что такие как ты разбирающиеся будут делать когда парочка грандов типа Кейта Пакарда окончаетльно задолбаются с этим месивом. У тебя и vkni появится чудный шанс показать всему миру как ты там разбираешься.
>> это потому, что про JIT-ы ты тоже знаешь только три символа, как и про X11.
> Да это пофигуя заметил.
> общую суть затеи с шейдерами и CL ядрами я усек
только вот беда: это не JIT, это кросс-компиляция. «не в лотерею, а в преферанс. не выиграл, а проиграл. не квартиру, а машину. а так всё верно, да.»
> Да ну, брось. Ты всякой всякой феерии тоже не меньше генеришь.
все ошибаются. я тоже ошибаюсь, конечно. но в темы, где я совсем ничего не понимаю, я стараюсь вообще не лезть.
> делать когда парочка грандов типа Кейта Пакарда
вот его вообще не надо было туда пускать. «гранд», блин. забирайте это к себе куда угодно и не возвращайте никогда.
> У тебя и vkni появится чудный шанс показать всему миру как ты там разбираешься.
(пожимает плечами) возможно, придётся. правда, лично я «всему миру» ничего доказывать и показывать не собираюсь, я если буду пилить — то совсем для других целей. потому как форк для распальцовки и сейчас сделать никто не мешает.
> и да: я не уточнил, что подразумеваю использование gcc/llvm именно как jit.
> это и есть мегаизвращение. что, собственно, доказывает нам Mike Pall со
> своим LuaJIT2.Для си-подобных языков это не мегаизвращение, а наиболее естественный метод JIT-компиляции. Для Lua LLVM JIT сливает, но не потому что он плохой, а потому что заточен на совсем другие языки.
Кстати, в WebKit яббловцы прикрутили JIT-компиляцию JS с помощью LLVM в качестве четвертого уровня JIT.
> Для си-подобных языков это не мегаизвращение, а наиболее естественный метод JIT-компиляции.— алё, Хьюстон, у нас проблемы: воробей!
— спокойно, уже везём ядерную боеголовку!> Для Lua LLVM JIT сливает, но не потому что он плохой,
> а потому что заточен на совсем другие языки.тут вот в списке рассылки LuaJIT забавное пролетело: транслятор байт-кода JVM в байт-код LuaJIT. первая версия — в общем-то PoC — показала (на микротестах, конечно) результаты кое-где получше хотспота, а кое-где ненамного хуже. ну, и кое-где таки хуже — потому что автор транслятора сделал некоторые вещи неправильно, на что СуперМайк ему указал. про потребление памяти лучше умолчу вообще, чтобы у жавистов падучая не началась.
это я к чему? к тому, что с джитингом «статически типизированых» языков LuaJIT2 справляется тоже весьма неплохо.
> Кстати, в WebKit яббловцы прикрутили JIT-компиляцию JS с помощью LLVM в качестве
> четвертого уровня JIT.ну, любят люди извращения — кто ж им запретить-то может…
>> Для си-подобных языков это не мегаизвращение, а наиболее естественный метод JIT-компиляции.
> — алё, Хьюстон, у нас проблемы: воробей!
> — спокойно, уже везём ядерную боеголовку!Проще взять готовый фронт-енд для С-подобных языков и готовый бэкэнд для JIT, чем городить велосипеды.
> Проще взять готовый фронт-енд для С-подобных языков и готовый бэкэнд для JIT,
> чем городить велосипеды.— а пользователь?
— а нам какое дело? купит процессор поновее и ещё 16GB памяти, это его проблемы!
угу, для питона, руби, перла, пэхапе - первые будут.
потом всякие тикли, APL и проч и проч - втащат, мб )
было бы прикольно увидеть Erlang OTP - сроднившимся с GCC :P
> было бы прикольно увидеть Erlang OTP — сроднившимся с GCC :Pне особо. и вообще, для многих «динамических» языков AOT-компилятор — совсем не лучшее решение, как ни странно. даже если этот AOT-компилятор пытается изобразить из себя JIT.
Я может быть чего-то не понимаю, но Gentoo вроде бы давно придумали. И компилятся там исходники ровно один раз, а не постоянно, как Jit без кеширования.
Вы вообще нихрена не понимаете. И гентушники тут ни о чем.Что есть у гентушников для того чтобы, например, вгрузить шейдер в GPU, предварительно скомпилив его, ась? И да, драйверу GPU например несколько не комильфо стартовать новые процессы с компилером. Функцию библы позвать - еще куда ни шло. Ну а программа (OpenGL/OpenCL/...) не может заранее знать какой там у вас GPU и как под него шейдеры генерить. Поэтому все что оно может - попросить "а скомпильте мне это и запустите", ну а дальше уже драйвер и бэкэнд кодогенерации будут разбираться как "это" превратить в команды понимаемые "вон тем" GPU, который в системе есть.
Аналогично - везде где надо скрипты или байткод выполнять, они тормозят если их интерпретировать, т.к. полезная логика всегда сильно разбавлена логикой интерпретатора. А если все заранее в нативный машинный код перегнать и выполнять его - можно сочетать достоинства компиляторов и интерпретаторов. От интерпретаторов - не надо заранее знать какая платформа + нет видимой програмеру фазы компиляции под каждую конкретную платформу. От компиляторов - скорость выполнения типичная для компилированного кода. Просто фазу окончательной компиляции в нативный код снесли на юзеря. Это чем-то похожа на гентушников :))) но совсем не в том виде каком они себе это представляли.
> И да, драйверу GPU например несколько не комильфо стартовать новые процессы
> с компилером. Функцию библы позвать — еще куда ни шло.действительно, то ли дело — прямо в драйвер вкорячить немеряных размеров библиотеку компилятора. это же так секурно, а память вообще экономит прямо влёт: пользователь же каждую наносекунду какой-нибудь шэйдер компилирует!
намного разумней как раз отдельные процессы, стандартизованый язык и универсальный способ вызова компилятора. и не нужно таскать с собой костыли: большинство софта будет вызывать оный компилятор при установке, заранее собирая шейдеры под GPU, который на борту. и оставшаяся небольшая часть — вызывать по мере необходимости. that's all, folks!
> Аналогично — везде где надо скрипты или байткод выполнять, они тормозят если
> их интерпретировать, т.к. полезная логика всегда сильно разбавлена логикой интерпретатора.
> А если все заранее в нативный машинный код перегнать и выполнять
> его — можно сочетать достоинства компиляторов и интерпретаторов. От интерпретаторов —
> не надо заранее знать какая платформа + нет видимой програмеру фазы
> компиляции под каждую конкретную платформу. От компиляторов — скорость выполнения типичная
> для компилированного кода. Просто фазу окончательной компиляции в нативный код снесли
> на юзеря. Это чем-то похожа на гентушников :))) но совсем не
> в том виде каком они себе это представляли.а этот пассаж вообще офигительно смешон. сразу видно человека, который проблематику JIT-компиляторов для «динамических» языков не понимает вообще. максимум — что-то там слышал краем уха, и уверен, что AOT-компилятор завсегда лучше JIT в любой области. и что полновесный AOT-компилятор типа GCC — это такая мелочь, оверхэд от которой вообще не стоит упоминания.
ещё раз отправляю тебя внимательно смотреть на LuaJIT2. и на то, как происходит кодогенерация в GCC и сколько все его фазы весят (как в плане памяти, так и в плане скорости). это для начала.
> а память вообще экономит прямо влёт:
> пользователь же каждую наносекунду какой-нибудь шэйдер компилирует!Меня, если честно, беспокоит вопрос времени - gcc -O2 значительно тормознее gcc -O0. Т.е. фаза оптимизации занимает очень существенное время. А JIT должен быть всё-таки достаточно быстр. Ну, либо придётся ограничиться предкомпиляцией с сохранением результатов (но это и есть вариант Gentoo).
да и памяти оно тоже кушает. при этом libjit — если выкинуть вливы — весит значительно меньше, работает сильно быстрее и выдаёт достаточно неплохой код. вдобавок имеет интерпретатор для архитектур, где нет кодогенерации.
> да и памяти оно тоже кушает.В gcc 4.8 вроде как потребление памяти заметно скостили, правда там в основном на LTO вроде непирали.
> при этом libjit — если выкинуть вливы —
Гыгы, действительно, нафиг надо генерить код под GPU? Отдадим шлангу на откуп? :)
> весит значительно меньше, работает сильно быстрее и выдаёт достаточно
> неплохой код. вдобавок имеет интерпретатор для архитектур, где нет кодогенерации.Звучит довольно вкусно.
>> при этом libjit — если выкинуть вливы —
> Гыгы, действительно, нафиг надо генерить код под GPU?jit-компилятором? однозначно не надо, jit-ы не для этого совсем придуманы.
>> весит значительно меньше, работает сильно быстрее и выдаёт достаточно
>> неплохой код. вдобавок имеет интерпретатор для архитектур, где нет кодогенерации.
> Звучит довольно вкусно.оно ещё вкуснее, на самом деле, потому что на вход libjit'у подаётся почти классический SSA. то есть, распределением регистров, уничтожением лишних временных переменных и прочей «низкой» механикой занимается сама libjit. и это действительно удобно.
и ещё там есть плюшки для перекомпиляции уже раз отджитеной функции, при этом с поддержкой многопоточности. то есть, сам компилятор только в одном потоке может работать, но: пока мы упорно занимаемся перекомпиляцией, другие потоки спокойно используют старую версию функции. а потом libjit заменит её на новую. при этом позаботившись о том, чтобы ничего не упало и не сглючило, если какой-то другой поток в это время всё ещё находится в старом варианте.
«из коробки» оно умеет x86, x86_64 и arm. то есть, подавляющее большинство устройств, где может понадобиться, охвачено. да и создание нового бэкэнда не ракетная наука.
> «из коробки» оно умеет x86, x86_64 и arm.Мда, и кто-то еще заикается про малое количество архитектур, поддерживаемых LLVM.
> jit-компилятором? однозначно не надо, jit-ы не для этого совсем придуманы.Оно достаточно близко по смыслу имхо - код для GPU генерится на лету, по ходу выполнения программы. Обычный компилер на такое дергать - полное извращение.
> спокойно используют старую версию функции. а потом libjit заменит её на
> новую. при этом позаботившись о том, чтобы ничего не упало и
> не сглючило, если какой-то другой поток в это время всё ещё
> находится в старом варианте.Хорошо придумано, не отнять.
> «из коробки» оно умеет x86, x86_64 и arm. то есть, подавляющее большинство устройств,
А как насчет MIPS и PPC?
>> jit-компилятором? однозначно не надо, jit-ы не для этого совсем придуманы.
> Оно достаточно близко по смыслу имхо — код для GPU генерится на
> лету, по ходу выполнения программы. Обычный компилер на такое дергать —
> полное извращение.оно совершенно далеко и по смыслу, и по целям, и по требованиям. и вот ты как раз предлагаешь «дёргать обычный компилер», только через задницу.
> А как насчет MIPS и PPC?
они ждут своих героев. изначально libjit делаласть для DotGNU, чего там на мипсах ловить? но оно и ARM не умело тоже. потом научили. а MIPS и PPC пока никому не понадобились, видимо. научи — будет круто. иначе, как понимаешь — интерпретатор.
Использовать gcc для jit какая-то нелепость при наличии llvm.
> Использовать gcc для jit какая-то нелепость при наличии llvm.не большая, чем использовать для этого llvm.
То, что ребята пошли по пути LLVM не может не радовать. Вот только они опоздали. В LLVM классных плюшек с каждым релизом только прибавляется. И догнать их будет не легко. А поддерживая старый(и зачастую плохо поддерживаемый код на C) - просто не реально.
> В LLVM классных плюшек с каждым релизом только прибавляется.Особенно "классно" с LLVM сношались амдшники, которые добрых 2 года пытались убедить этот крап сгененрить просто валидный код для их GPU. Про оптимизацию кода речь вообще не шла - для этого отдельный довесок присобачили. Который к LLVM вообще никак не относится.
> И догнать их будет не легко. А поддерживая старый(и зачастую
> плохо поддерживаемый код на C) - просто не реально.Я думаю мсье стоило бы почитать что думают практикующие разработчики о "простоте" работы с clang/llvm. Например, мнение от Vadim Girlin, того который оптимизатор шейдеров написал. Ему проще с нуля оказалось написать это чем с шланговской инфраструктурой бодаться.
> но уже началась подготовка биндинга для языка Pythonа вот это уже интересно