The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Основанные на GCC проекты JIT-компилятора и расширения, использующего GPU для вычислений

03.10.2013 23:49

Дэвид Малколм (David Malcolm), активный разработчик GCC из компании Red Hat, опубликовал прототип библиотеки libgccjit.so с реализацией встраиваемого в приложения JIT-компилятора, использующего GCC в качестве бэкенда. Данная библиотека может быть динамически связана с интерпретаторами байткода и другими программами, которым необходима генерации машинного кода на лету, во время выполнения.

Идея проекта состоит в том, что GCC собирается в форме позиционно-независимого кода, который присоединяется к библиотеке libgccjit.so, что позволяет обеспечить возможность выполнения GCC в одном процессе с генерируемым машинным кодом. Инициирование компиляции и выполнения откомпилированных на лету блоков кода производится приложением при помощи специально предоставленного библиотекой API. Первый прототип проекта поддерживает JIT-компиляцию кода на языке Си, но уже началась подготовка биндинга для языка Python.

Другим интересным проектом, является опубликованный разработчиками из компании Samsung модифицированный вариант GCC с интегрированной поддержкой стандарта OpenACC 1.0. Указанный вариант GCC даёт возможность сформировать исполняемый файл, позволяющий в процессе работы программы вынести выполнение некоторых вычислительных операций на плечи GPU.

  1. Главная ссылка к новости (http://gcc.gnu.org/ml/gcc-patc...)
  2. OpenNews: Обсуждение возможных планов развития GCC 5.0
  3. OpenNews: Наглядное представление шагов оптимизации в GCC
  4. OpenNews: nVidia Fermi сможет выполнять Linux
  5. OpenNews: Проект KGPU позволяет задействовать GPU для выполнения фрагментов кода ядра Linux
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/38075-gcc
Ключевые слова: gcc, jit, gpu, openacc
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (113) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 00:37, 04/10/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Чем оно лучше LLVM?
     
     
  • 2.3, pavlinux (ok), 00:45, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +12 +/
    Килотонны петабайт исходников не надо будет переписывать.
     
     
  • 3.46, YetAnotherOnanym (ok), 12:31, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Килотонны петабайт исходников не надо будет переписывать.

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

     
     
  • 4.50, Аноним (-), 12:56, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Правильно написанный исходник не нужно бывает переписывать.

    Да, в случае сферического коня в идеальном вакууме... (с) анекдот :)

     
     
  • 5.56, Аноним (-), 13:58, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Нет, в случае нерукожопого программиста. Переход FreeBSD на clang показал что таких, к счастью, большинство - clang'ом не собиралось не больше десятка процентов портов, из них большая часть исправлялась добавлением пропущенного #include (что, кстати, значит что в gcc'шной libstdc++ инклудится лишнее, если она это жрала), с USE_GCC остались единицы с реальными gcc'измами.
     
     
  • 6.65, Пиу (ok), 15:45, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    напомни, сколько шлангу пришлось из-за этого поддерживать гнутых/гцц-шных расширений?
     
     
  • 7.68, arisu (ok), 16:06, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > напомни, сколько шлангу пришлось из-за этого поддерживать гнутых/гцц-шных расширений?

    при этом две самые полезные фичи так и не поддерживает: nested functions и statement expressions.

    оно понятно, что хардкорные фанаты тверды в своём принципе «что было хорошо для наших дедов и отцов — то хорошо и для нас», но эти две фичи, как я уже писал, без мегаусложнения компилятора дают приятные бонусы. например, удобные однострочные макросы min/max, вычисляющие аргументы ровно один раз, или нечто вроде лямбд для тех же qsort()/bsearch(), которые (вроде-лямбды) могут быть объявлены прямо параметром и напрямую обращаться к переменным родительской функции.

    но это, конечно, не Ъ.

     
     
  • 8.100, linux must _RIP_ (?), 11:52, 07/10/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    а так же дают постоянный исполняемый стек, что открывает простор для написания э... текст свёрнут, показать
     
     
  • 9.104, arisu (ok), 11:59, 07/10/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    пшёл вон, мразь ... текст свёрнут, показать
     
  • 9.108, Andrey Mitrofanov (?), 14:08, 07/10/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Пошёл gcc патчить, м азь ... текст свёрнут, показать
     
  • 8.105, annulen (ok), 13:04, 07/10/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Для кода, не соответствующего стандарту, не может быть оправданий И пофиг, гнут... текст свёрнут, показать
     
     
  • 9.107, arisu (ok), 13:17, 07/10/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    мне как-то совершенно плевать на идиотские стандарты стандарт на си особенно ид... большой текст свёрнут, показать
     
  • 9.149, Аноним (-), 12:13, 10/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    GCC доступен под туеву хучу архитектур и желающие могут впилить туда свою новую ... текст свёрнут, показать
     
  • 6.79, Аноним (-), 09:29, 05/10/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Нет, в случае нерукожопого программиста.

    Наверное это был сам Юрий Нежопорукий.

    > Переход FreeBSD на clang показал что

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

     
     
  • 7.101, linux must _RIP_ (?), 11:54, 07/10/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > ...что они х#$рят на своей волне и ни с кем не считаются,
    > ставя свои лицензионные бзики выше получаемого на выходе результата.

    это вы о большинстве линуксоидных программистов? которые слов c-std .., POSIX, SUS боятся как огня ?:)

     
     
  • 8.147, Аноним (-), 12:08, 10/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Это о общей логике развития FBSD Эталонный пример того как не надо рулить проек... текст свёрнут, показать
     
  • 2.4, Хрен с горы (?), 00:46, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +15 +/
    Выше скорость генерируемого кода, поддерживает большое количество платформ, нет зависимости от одной компании, свободная лицензия.
     
     
  • 3.18, Аноним (-), 07:57, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • –19 +/
    в общем, если поскипать бред, то получается, что преимуществ-то и нет. Сейчас все новые компиляторы, трансляторы и т.п. или пишутся с нуля, или используют LLVM в качестве бэкенда, а GCC с его обфусцированной архитектурой (привет параноику Столлману) никому нафиг не нужен :)
     
     
  • 4.19, Аноним (-), 08:17, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > никому нафиг не нужен :)

    Ну да, кроме вон той толпени корпорасов типа IBM, интелов и еще 100500 всяких, билдующих им себе линух для своих железяк.

     
     
  • 5.30, 123 (??), 09:54, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Да ты что, а это что по твоему? http://www-03.ibm.com/software/products/us/en/ccompfami/
     
     
  • 6.43, Аноним (-), 12:03, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Да ты что, а это что по твоему? http://www-03.ibm.com/software/products/us/en/ccompfami/

    Понятия не имею что это. Зато догадываюсь чем они собирают ядро линя и софт под свой любимый power, например. Наверняка это gcc, да :).

     
  • 5.31, Человек (??), 09:55, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • –11 +/
    А почему Oracle Solaris Studio свой компилятор включает ?

    Зачем Intel свой компилятор продаёт ?

    Зачем AMD пилит свой форк Open64 ?

    Зачем IBM продаёт XL ?

    Зачем The Portland Group продаёт свой компилятор ?

    Это великие IT-компании, у которых достаточно компетенции для реализации своих собственных компиляторов. У Red Hat такой компетенции нет и они используют GCC.

    GCC нужен ТОЛЬКО для компиляции ядра Linux и другого ПО, которое использует костыли от GCC (его очень мало). В ядре Linux содержатся куча костылей. Эти костыли используют костыли из GCC. Вот и всё.

    Apple выкинула GCC и FreeBSD тоже.

    Реально GCC НЕ НУЖЕН !

     
     
  • 6.39, Аноним (39), 11:27, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Лучше спросите зачем все это покупают.

    И кстати компилятор из Solaris Studio жуткое уе.ище.

     
  • 6.41, Аноним (-), 11:43, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Ну да. Давайте теперь каждую программу тестировать в разных компиляторах вместо одного и собирать не только для разной архитектуры, но и производителя, ура товарищи, ура!
    А заодно напомните, кто реально для работы на ПК(а не узкоспециализированном железе одной фирмы) будет это делать, заранее спасибо.
     
     
  • 7.57, Аноним (-), 14:02, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Ну да. Давайте теперь каждую программу тестировать в разных компиляторах вместо одного
    > и собирать не только для разной архитектуры, но и производителя, ура
    > товарищи, ура!

    Не "давайте", а все нормальные люди так и делали всегда, потому что это повышает шанс ловли ошибок и несовместимостей. Посмотрите хотя бы travis ci, оно по умолчанию давно поддерживает как минимум gcc и clang. Но куда GNU'шным проприетарщикам это понять - у них одна архитектура - бyбунту.

     
     
  • 8.66, arisu (ok), 15:55, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    шланг с его хроническими болячками намного проще объявить неподдерживаемым и не ... текст свёрнут, показать
     
     
  • 9.146, Аноним (-), 12:05, 10/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Жесть как она есть ... текст свёрнут, показать
     
     
  • 10.151, arisu (ok), 12:17, 10/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    справедливости ради это скорее разница в поведении на сборке программы с неопре... текст свёрнут, показать
     
  • 6.45, Аноним (-), 12:28, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +9 +/
    > А почему 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Н !

    Кому? Проприерасам и их подстилкам? Окей, пусть идут на...й, я не возражаю :).

     
  • 6.69, Клыкастый (ok), 16:17, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    "gcc не нужен"... это... сильно. таких жирнючих троллей ещё не было. моё почтение.
     
  • 6.74, Vkni (ok), 18:25, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Исторические причины значительно лучшая кодогенерация под SPARC Впрочем, есть... большой текст свёрнут, показать
     
     
  • 7.75, arisu (ok), 18:34, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Это компилятор по-умолчанию в Linux'ах. Т.е. на данный момент это основной C/C++
    > компилятор.

    более того: это компилятор, вероятность наличия которого на какой-нибудь хитрой системе (или возможности поставить порт) очень близка к единице. поэтому имеет смысл писать код так, чтобы его мог прожевать gcc, а остальными компиляторами заморачиваться только по мере неленивости.

     
     
     
    Часть нити удалена модератором

  • 9.125, Crazy Alex (ok), 20:40, 07/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Хм, ну покажи мне хоть как-то живую систему, на которую не портирован GCC Пусть... текст свёрнут, показать
     
  • 9.127, Vkni (ok), 21:13, 07/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Это только если рассматриваем десктоп На планшетах и телефонах вероятность нали... текст свёрнут, показать
     
     
  • 10.143, Аноним (-), 12:00, 10/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    А как же виндовс фон Хотя я согласен - лучше считать его за ноль А я думал -... текст свёрнут, показать
     
  • 5.106, annulen (ok), 13:05, 07/10/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >> никому нафиг не нужен :)
    > Ну да, кроме вон той толпени корпорасов типа IBM, интелов и еще
    > 100500 всяких, билдующих им себе линух для своих железяк.

    Тем временем парни из IBM уже запилили LLVM и Clang для Power и System Z.

     
     
  • 6.144, Аноним (-), 12:01, 10/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Тем временем парни из IBM уже запилили LLVM и Clang для Power и System Z.

    Осталось всего ничего: спустить фанатизм в унитаз и честно сообщить нам сколько лет gcc так уже умеет.

     
  • 4.24, BratSinot (ok), 09:03, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вам повторить про более лучшую оптимизацию и большее количество поддерживаемых платформ/архитектур?
     
     
  • 5.67, arisu (ok), 15:57, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Вам повторить про более лучшую оптимизацию и большее количество поддерживаемых платформ/архитектур?

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

     
     
  • 6.81, Аноним (-), 09:57, 05/10/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Что-то НеОбфусцированная архитектура LLVM оказалась настолько не готова к тому ч... большой текст свёрнут, показать
     
     
  • 7.83, arisu (ok), 10:02, 05/10/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    да тут начинать надо с того, что никакой «обфусцированой архитектуры» в gcc нет: надо просто иметь рабочие мозги и понимать предметную область.

    llvm же вполне хорош — для своих применений. правда, там с дизайном совсем не радуга с поняшами, но и это тут обсуждать смысла нет: фанбои тупые, а те, кому интересно состояние дел, и так знают.

     
     
  • 8.142, Аноним (-), 11:57, 10/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    А с этим никто и не спорит Просто объем маркетингового буллшита текущего из нек... текст свёрнут, показать
     
     
  • 9.152, arisu (ok), 12:20, 10/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    казалось бы при чём тут огрызок 8230 ... текст свёрнут, показать
     

     ....большая нить свёрнута, показать (42)

  • 1.2, ssy (?), 00:37, 04/10/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Скоро окажется, что gpu работает наравне с cpu и последний можно убрать. Потом окажется, что gpu можно разгрузить, добавив cpu. Ну вы поняли.
     
     
  • 2.5, pavlinux (ok), 00:47, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Скоро окажется, что gpu работает наравне с cpu ...

    Еще лет 7-8 назад один из разрабов Nvidia вывалил на сайте developer.nvidia.com,
    что они запускали ядро Linux на GeForce, вроде 6800GT. Пост исчез в течении двух дней,
    разраба никто больше не слышал.  :)

    Чуть раньше, когда CUDA и OpenCL в планах даже не было, один чувак,
    реализовал функции сортировки, сравнения строк на Жыфорсе. Его сайт
    жил дольше, но не обновлялся ни разу.

     
     
  • 3.6, Аноним (-), 00:52, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Не в начале апреля пост был?
     
     
  • 4.7, pavlinux (ok), 00:56, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Симшьно, ща уписаюсь http://www.cs.utah.edu/~wbsun/gpustore.pdf
     
  • 4.10, pavlinux (ok), 01:44, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Кстати, на Опеннете новость была.
     
     
  • 5.36, zhenya_k (?), 11:11, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    За вами тоже уже выехали.
     
     
  • 6.40, Аноним (-), 11:31, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Извинитесь.
     
  • 4.26, Аноним (-), 09:17, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    https://www.opennet.ru/opennews/art.shtml?num=23833 nVidia Fermi сможет выполнять Linux
    https://www.opennet.ru/opennews/art.shtml?num=30484 Проект KGPU позволяет задействовать GPU для выполнения фрагментов кода ядра Linux
     
     
  • 5.35, Аноним (-), 11:02, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Это завязано на CUDA и блободрайвере, что для ядра сильно-сильно не айс. Вот если будет VAAPI и nouveau (radeon), то тогда да.
     
     
  • 6.42, Аноним (-), 11:54, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > CUDA... VAAPI и nouveau (radeon)

    Какие еще слова знаешь?

     
     
  • 7.70, Аноним (-), 16:45, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Wiki всем доступно, можешь и ты просветиться :)
     
  • 6.82, Аноним (-), 09:59, 05/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот если будет VAAPI

    И как именно апи для декодирования видео относится к вычислениям на GPU? :)


     
  • 3.8, vitalif (ok), 00:58, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    А ещё был более-менее реальный proof of concept червя, живущего исключительно в памяти GPU и в ROM'е broadcom'овской сетевухи (она там тоже такая типа вся программируемая), и слущающего трафик.
     
  • 2.37, анонимус (??), 11:17, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это никогда не случится :) Вы не особо представляете как вообще GPU работает. Для некоторых алгоритмов намного быстрее, а для некоторых наоборот намного медленнее. А вот решения AMD CPU + GPU - APU вполне жизнеспособны, как в свое время CPU + FPU.
     

  • 1.9, rshadow (ok), 01:38, 04/10/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Странная эта борьба за новые языки и возможности. Все время пытаются сделать лазерный скальпель, когда вогруг все пилят только деревья. Надо бы культуру программирования и технологии в массы подтянуть, а не переизобретать очередной велосипед на очередном языке.
     
     
  • 2.12, Аноним (-), 03:32, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Речь скорее идет о изобретении инструментов переноса старого кода и инструментов в новые условия. Что с того, что новые условия это не лесопилка, а что то потоньше? Уровень среднего программера остается неизменным.
     

  • 1.13, jOKer (ok), 03:53, 04/10/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >но уже началась подготовка биндинга для языка Python.

    Отличненько, - горю желанием заценить!

     
  • 1.14, arisu (ok), 04:33, 04/10/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    забавно, конечно, но редкостные извращенцы. что этот, что llvm-щики.
     
     
  • 2.16, Аноним (-), 07:22, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    На миллионyю по счету просьбу засветить свой код, который лучше, будет традиционное мужественное самоотверженное молчание ? Часто незнакомых людей "редкостными извращенцами" в лицо называешь?
     
     
  • 3.59, arisu (ok), 14:36, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > На миллионyю по счету просьбу засветить свой код, который лучше, будет традиционное
    > мужественное самоотверженное молчание ? Часто незнакомых людей «редкостными извращенцами»
    > в лицо называешь?

    проси на здоровье, за спрос денег не берут.

     
  • 2.22, Аноним (-), 08:42, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > забавно, конечно, но редкостные извращенцы. что этот, что llvm-щики.

    Предложи более прямой способ сгенерить шейдеры для GPU, например? Как ты понимаешь, заранее вообще неизвестно что там у юзеря: ати, нвидия, интел или вообще какой-нить ARM. Поэтому программа явно не может таскать с собой для этого предкомпилированный код.

     
     
  • 3.58, Аноним (-), 14:05, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> забавно, конечно, но редкостные извращенцы. что этот, что llvm-щики.
    > Предложи более прямой способ сгенерить шейдеры для GPU, например? Как ты понимаешь,
    > заранее вообще неизвестно что там у юзеря: ати, нвидия, интел или
    > вообще какой-нить ARM. Поэтому программа явно не может таскать с собой
    > для этого предкомпилированный код.

    Вы прям так спрашиваете как будто arisu разбирается в компьютерах и не просто так брякнул.

     
     
  • 4.76, Аноним (-), 19:21, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    не мешай ему дилетанствовать c самовлюбленным апломбом, вон уже чуть ниже поток полился про "ощущения чуйств" на тему GCC. Замени GCC и LLVM на Коллайдер и систему жизнеобеспечения автономного модуля на Марсе, впрочем и митохондрии подойдут - суть не поменяется. Костьми ляжет, но ни слова не дождешься о конкретных проверяемых сущностях.
     
     
  • 5.77, arisu (ok), 19:29, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +6 +/
    (пожимает плечами) конкретная сущность — это намертво зависающий движок регулярок, нежно портированый из plan9 и допиленый. тупой шланг не врубается, что inline-функция может модифицировать некоторые переменные, передаваемые ей в структуре (хотя никакого const там нет), поэтому сначала переменную где-то кэширует, а потом использует её старое значение. в итоге получается бесконечный цикл вида «jmp $». чего лично я от компилятора такого возраста никак не ожидал и был несколько в офигее, когда софтина подвисла, слопав весь процессор.

    но я понимаю, что для тебя «я наступил на баг в компиляторе» — ситуация вообще невозможная, потому что твой «приветмир» без ворнингов вообще не собирается. какие уж там баги компилятора…

     
     
  • 6.84, Аноним (-), 11:34, 05/10/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Красиво приложил :).
    > нежно портированый из plan9 и допиленый. тyпой шланг не врубается,

    Мсье, что вы, как можно, эппл на такие навороты не рассчитывал. Так что будем слушать вопли фанатиков "это не нyжно!!!111".

     
     
  • 7.90, arisu (ok), 12:09, 05/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    вот, кстати, только что в списке рассылки 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.
     
     
  • 8.141, Аноним (-), 11:55, 10/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Справедливости ради - почитай логи коммитов к амдшному окрытому драйверу GCC... текст свёрнут, показать
     
     
  • 9.145, arisu (ok), 12:04, 10/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    так я и на gcc-шные баги наступал как-нибудь под настроение 8212 если вспомн... текст свёрнут, показать
     
  • 6.95, Vkni (ok), 19:31, 05/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > тупой шланг не врубается, что
    > inline-функция может модифицировать некоторые переменные, передаваемые ей в структуре

    Это какая версия компилятора? Т.е. код

    struct z_t
    {
        int a;
        int b;
    };

    inline void f( z_t * z)
    {
        z.a = 1.0;
    }

    он откомпилирует неправильно?

     
     
  • 7.96, arisu (ok), 19:37, 05/10/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Это какая версия компилятора?

    3.3.

    > он откомпилирует неправильно?

    не знаю и проверять лень. там функция несколько сложнее, возвращает тоже структуру и используется в виде funcall(ss)->fld = ss->fld1, при этом ss->fld1 внутри функции меняется. но шланг этого не понимает, и использует старое значение.

    p.s. собственно, после раздумий я не уверен, ошибка ли это компилятора, или идиотизм стандарта с очередной «неопределённой последовательностью». но принцип least surprise явно поломан, это раз. и два — если поведение неопределено, то компилятор должен плюнуть предупреждением.

     
     
  • 8.109, annulen (ok), 14:33, 07/10/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Выкладывай отпрепроцессенный файл и опции компиляции, я проверю ... текст свёрнут, показать
     
     
  • 9.126, Аноним (-), 21:08, 07/10/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не выложит, это принципиально Будет тот же графоманский поток околокомпьютеорны... текст свёрнут, показать
     
     
  • 10.131, Vkni (ok), 21:38, 07/10/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Милый Аноним, вы тоже не понимаете, что заниматься социальными игрищами, надев м... текст свёрнут, показать
     
  • 9.134, Vkni (ok), 21:58, 07/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    http www opennet ru openforum vsluhforumID3 91996 html 133... текст свёрнут, показать
     
     
  • 10.137, arisu (ok), 22:03, 07/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    ты мне гешефт поломал, кстати я-то надеялся, что денег дадут за сэмпл ... текст свёрнут, показать
     
  • 8.128, Vkni (ok), 21:19, 07/10/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В том виде, что ты написал, это очень похоже на неопределённое поведение Причём... текст свёрнут, показать
     
     
  • 9.129, arisu (ok), 21:31, 07/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    я про си и говорил нулевую польза 8212 это если бы меня преупреждением обру... большой текст свёрнут, показать
     
     
  • 10.130, Vkni (ok), 21:37, 07/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Стат анализатор у clang а говно, хотя попробуй, прогони его, авось ругнётся А ... текст свёрнут, показать
     
     
  • 11.132, arisu (ok), 21:56, 07/10/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    его, вроде, отдельно собирать надо потом попробую как-нибудь, git всё помнит, е... большой текст свёрнут, показать
     
     
  • 12.135, Vkni (ok), 22:00, 07/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Уже не надо - http www opennet ru openforum vsluhforumID3 91996 html 133... текст свёрнут, показать
     
  • 10.133, Vkni (ok), 21:57, 07/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Программа 8 ---------------------------------------------- 8 typedef struct S... текст свёрнут, показать
     
     
  • 11.136, arisu (ok), 22:00, 07/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    благодарю могу от себя добавить, что gcc 4 8 1 на x86 тоже никаких ворнингов не... текст свёрнут, показать
     
  • 3.60, arisu (ok), 14:41, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Предложи более прямой способ сгенерить шейдеры для GPU, например?

    предлагаю: унифицировать промежуточную VM для оных GPU, а драйвера пусть при необходимости «докомпиливают» её в родной код. причём поскольку GPU — штуки специфические, то и VM можно сдизайнить соответствующим образом, чтобы на стадии «компиляция в код VM» делалось побольше всего.

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

    и да: я не уточнил, что подразумеваю использование gcc/llvm именно как jit. это и есть мегаизвращение. что, собственно, доказывает нам Mike Pall со своим LuaJIT2.

     
     
  • 4.85, Аноним (-), 11:50, 05/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Уже была попытка, кстати Называлось сие TGSI, см http people freedesktop org... большой текст свёрнут, показать
     
     
  • 5.87, arisu (ok), 11:56, 05/10/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    как я уже сказал — тут две отдельные ветки беседы надо. JIT в одну сторону, компиляцию шэйдеров — в другую.

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

    просто в винде создать новый процесс сильно дороже, чем в пингвинусе, вот и занимаются извращениями.

     
     
  • 6.91, Аноним (-), 13:18, 05/10/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Компиляция шейдеров во время выполнения происходит, по поводу чего не вижу глоба... большой текст свёрнут, показать
     
     
  • 7.93, arisu (ok), 15:10, 05/10/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > по поводу чего не вижу глобальных отличий от JIT

    это потому, что про JIT-ы ты тоже знаешь только три символа, как и про X11.

    остальную феерию просто вытер, потому что тут опять «обнять и плакать».

     
     
  • 8.138, Аноним (-), 11:41, 10/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Да это пофигу - общую суть затеи с шейдерами и CL ядрами я усек и вижу что народ... большой текст свёрнут, показать
     
     
  • 9.148, arisu (ok), 12:11, 10/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    я заметил только вот беда это не JIT, это кросс-компиляция 171 не в лотерею... большой текст свёрнут, показать
     
  • 4.111, annulen (ok), 14:37, 07/10/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > и да: я не уточнил, что подразумеваю использование gcc/llvm именно как jit.
    > это и есть мегаизвращение. что, собственно, доказывает нам Mike Pall со
    > своим LuaJIT2.

    Для си-подобных языков это не мегаизвращение, а наиболее естественный метод JIT-компиляции. Для Lua LLVM JIT сливает, но не потому что он плохой, а потому что заточен на совсем другие языки.

    Кстати, в WebKit яббловцы прикрутили JIT-компиляцию JS с помощью LLVM в качестве четвертого уровня JIT.

     
     
  • 5.112, arisu (ok), 14:50, 07/10/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    8212 алё, Хьюстон, у нас проблемы воробей 8212 спокойно, уже везём ядерн... большой текст свёрнут, показать
     
     
  • 6.113, annulen (ok), 15:17, 07/10/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Для си-подобных языков это не мегаизвращение, а наиболее естественный метод JIT-компиляции.
    > — алё, Хьюстон, у нас проблемы: воробей!
    > — спокойно, уже везём ядерную боеголовку!

    Проще взять готовый фронт-енд для С-подобных языков и готовый бэкэнд для JIT, чем городить велосипеды.

     
     
  • 7.114, arisu (ok), 15:19, 07/10/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Проще взять готовый фронт-енд для С-подобных языков и готовый бэкэнд для JIT,
    > чем городить велосипеды.

    — а пользователь?
    — а нам какое дело? купит процессор поновее и ещё 16GB памяти, это его проблемы!

     

     ....большая нить свёрнута, показать (35)

  • 1.15, Аноним (-), 07:21, 04/10/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    угу, для питона, руби, перла, пэхапе - первые будут.
    потом всякие тикли, APL и проч и проч - втащат, мб )
    было бы прикольно увидеть Erlang OTP - сроднившимся с GCC :P
     
     
  • 2.61, arisu (ok), 14:51, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > было бы прикольно увидеть Erlang OTP — сроднившимся с GCC :P

    не особо. и вообще, для многих «динамических» языков AOT-компилятор — совсем не лучшее решение, как ни странно. даже если этот AOT-компилятор пытается изобразить из себя JIT.

     

  • 1.17, Vkni (ok), 07:30, 04/10/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Я может быть чего-то не понимаю, но Gentoo вроде бы давно придумали. И компилятся там исходники ровно один раз, а не постоянно, как Jit без кеширования.
     
     
  • 2.21, Аноним (-), 08:39, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Вы вообще нихрена не понимаете И гентушники тут ни о чем Что есть у гентушник... большой текст свёрнут, показать
     
     
  • 3.64, arisu (ok), 15:01, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    действительно, то ли дело 8212 прямо в драйвер вкорячить немеряных размеров б... большой текст свёрнут, показать
     
     
  • 4.72, Vkni (ok), 18:16, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > а память вообще экономит прямо влёт:
    > пользователь же каждую наносекунду какой-нибудь шэйдер компилирует!

    Меня, если честно, беспокоит вопрос времени - gcc -O2 значительно тормознее gcc -O0. Т.е. фаза оптимизации занимает очень существенное время. А JIT должен быть всё-таки достаточно быстр. Ну, либо придётся ограничиться предкомпиляцией с сохранением результатов (но это и есть вариант Gentoo).

     
     
  • 5.73, arisu (ok), 18:24, 04/10/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    да и памяти оно тоже кушает. при этом libjit — если выкинуть вливы — весит значительно меньше, работает сильно быстрее и выдаёт достаточно неплохой код. вдобавок имеет интерпретатор для архитектур, где нет кодогенерации.
     
     
  • 6.86, Аноним (-), 11:55, 05/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > да и памяти оно тоже кушает.

    В gcc 4.8 вроде как потребление памяти заметно скостили, правда там в основном на LTO вроде непирали.

    > при этом libjit — если выкинуть вливы —

    Гыгы, действительно, нафиг надо генерить код под GPU? Отдадим шлангу на откуп? :)

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

    Звучит довольно вкусно.

     
     
  • 7.89, arisu (ok), 12:06, 05/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> при этом libjit — если выкинуть вливы —
    > Гыгы, действительно, нафиг надо генерить код под GPU?

    jit-компилятором? однозначно не надо, jit-ы не для этого совсем придуманы.

    >> весит значительно меньше, работает сильно быстрее и выдаёт достаточно
    >> неплохой код. вдобавок имеет интерпретатор для архитектур, где нет кодогенерации.
    > Звучит довольно вкусно.

    оно ещё вкуснее, на самом деле, потому что на вход libjit'у подаётся почти классический SSA. то есть, распределением регистров, уничтожением лишних временных переменных и прочей «низкой» механикой занимается сама libjit. и это действительно удобно.

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

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

     
     
  • 8.120, annulen (ok), 18:37, 07/10/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Мда, и кто-то еще заикается про малое количество архитектур, поддерживаемых LLVM... текст свёрнут, показать
     
  • 8.139, Аноним (-), 11:49, 10/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Оно достаточно близко по смыслу имхо - код для GPU генерится на лету, по ходу вы... текст свёрнут, показать
     
     
  • 9.150, arisu (ok), 12:15, 10/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    оно совершенно далеко и по смыслу, и по целям, и по требованиям и вот ты как ра... текст свёрнут, показать
     

  • 1.78, Аноним (-), 20:34, 04/10/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Использовать gcc для jit какая-то нелепость при наличии llvm.
     
     
  • 2.80, arisu (ok), 09:35, 05/10/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Использовать gcc для jit какая-то нелепость при наличии llvm.

    не большая, чем использовать для этого llvm.

     

  • 1.92, lucentcode (ok), 13:20, 05/10/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    То, что ребята пошли по пути LLVM не может не радовать. Вот только они опоздали. В LLVM классных плюшек с каждым релизом только прибавляется. И догнать их будет не легко. А поддерживая старый(и зачастую плохо поддерживаемый код на C) - просто не реально.
     
     
  • 2.140, Аноним (-), 11:52, 10/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > В LLVM классных плюшек с каждым релизом только прибавляется.

    Особенно "классно" с LLVM сношались амдшники, которые добрых 2 года пытались убедить этот крап сгененрить просто валидный код для их GPU. Про оптимизацию кода речь вообще не шла - для этого отдельный довесок присобачили. Который к LLVM вообще никак не относится.

    > И догнать их будет не легко. А поддерживая старый(и зачастую
    > плохо поддерживаемый код на C) - просто не реально.

    Я думаю мсье стоило бы почитать что думают практикующие разработчики о "простоте" работы с clang/llvm. Например, мнение от Vadim Girlin, того который оптимизатор шейдеров написал. Ему проще с нуля оказалось написать это чем с шланговской инфраструктурой бодаться.

     

  • 1.97, хрюкотающий зелюк (?), 23:27, 06/10/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > но уже началась подготовка биндинга для языка Python

    а вот это уже интересно

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру