forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Основанные на GCC проекты JIT-компилятора и расширения, испо..., opennews (??), 04-Окт-13, (0) [смотреть все]

Чем оно лучше LLVM , Аноним (-), 00:37 , 04-Окт-13, (1) –5 //

Килотонны петабайт исходников не надо будет переписывать , pavlinux (ok), 00:45 , 04-Окт-13, (3) +12 //

Правильно написанный исходник не нужно бывает переписывать , YetAnotherOnanym (ok), 12:31 , 04-Окт-13, (46) –1 //

Да, в случае сферического коня в идеальном вакууме с анекдот , Аноним (-), 12:56 , 04-Окт-13, (50) +4

Нет, в случае нерукожопого программиста Переход FreeBSD на clang показал что та, Аноним (-), 13:58 , 04-Окт-13, (56) –2

напомни, сколько шлангу пришлось из-за этого поддерживать гнутых гцц-шных расшир, Пиу (ok), 15:45 , 04-Окт-13, (65) +4

при этом две самые полезные фичи так и не поддерживает nested functions и state, arisu (ok), 16:06 , 04-Окт-13, (68) +4

а так же дают постоянный исполняемый стек, что открывает простор для написания э, linux must _RIP_ (?), 11:52 , 07-Окт-13, (100) –1

пшёл вон, мразь , arisu (ok), 11:59 , 07-Окт-13, (104) +1
Пошёл gcc патчить, м азь , Andrey Mitrofanov (?), 14:08 , 07-Окт-13, (108) +1

Для кода, не соответствующего стандарту, не может быть оправданий И пофиг, гнут, annulen (ok), 13:04 , 07-Окт-13, (105) –2

мне как-то совершенно плевать на идиотские стандарты стандарт на си особенно ид, arisu (ok), 13:17 , 07-Окт-13, (107) +3
GCC доступен под туеву хучу архитектур и желающие могут впилить туда свою новую , Аноним (-), 12:13 , 10-Окт-13, (149)

Наверное это был сам Юрий Нежопорукий что они х рят на своей волне и ни с ке, Аноним (-), 09:29 , 05-Окт-13, (79) +2

это вы о большинстве линуксоидных программистов которые слов c-std , POSIX, S, linux must _RIP_ (?), 11:54 , 07-Окт-13, (101) –2

Это о общей логике развития FBSD Эталонный пример того как не надо рулить проек, Аноним (-), 12:08 , 10-Окт-13, (147)

Выше скорость генерируемого кода, поддерживает большое количество платформ, нет , Хрен с горы (?), 00:46 , 04-Окт-13, (4) +15 //

в общем, если поскипать бред, то получается, что преимуществ-то и нет Сейчас вс, Аноним (-), 07:57 , 04-Окт-13, (18) –19 //

Ну да, кроме вон той толпени корпорасов типа IBM, интелов и еще 100500 всяких, б, Аноним (-), 08:17 , 04-Окт-13, (19) +3

Да ты что, а это что по твоему http www-03 ibm com software products us en cc, 123 (??), 09:54 , 04-Окт-13, (30)

Понятия не имею что это Зато догадываюсь чем они собирают ядро линя и софт под , Аноним (-), 12:03 , 04-Окт-13, (43) +2

А почему Oracle Solaris Studio свой компилятор включает Зачем Intel свой компил, Человек (??), 09:55 , 04-Окт-13, (31) –11

Лучше спросите зачем все это покупают И кстати компилятор из Solaris Studio жутк, Аноним (39), 11:27 , 04-Окт-13, (39) +1
Ну да Давайте теперь каждую программу тестировать в разных компиляторах вместо , Аноним (-), 11:43 , 04-Окт-13, (41)

Не давайте , а все нормальные люди так и делали всегда, потому что это повышает, Аноним (-), 14:02 , 04-Окт-13, (57) +2

шланг с его хроническими болячками намного проще объявить неподдерживаемым и не , arisu (ok), 15:55 , 04-Окт-13, (66) +3

Жесть как она есть , Аноним (-), 12:05 , 10-Окт-13, (146)

справедливости ради это скорее разница в поведении на сборке программы с неопре, arisu (ok), 12:17 , 10-Окт-13, (151)

Потому что у санок вечно NIH был Кстати, данный компилер - набор грабель и кост, Аноним (-), 12:28 , 04-Окт-13, (45) +9
gcc не нужен это сильно таких жирнючих троллей ещё не было моё почтени, Клыкастый (ok), 16:17 , 04-Окт-13, (69) +2
Исторические причины значительно лучшая кодогенерация под SPARC Впрочем, есть, Vkni (ok), 18:25 , 04-Окт-13, (74) +1

более того это компилятор, вероятность наличия которого на какой-нибудь хитрой , arisu (ok), 18:34 , 04-Окт-13, (75) +3

Хм, ну покажи мне хоть как-то живую систему, на которую не портирован GCC Пусть, Crazy Alex (ok), 20:40 , 07-Окт-13, (125)
Это только если рассматриваем десктоп На планшетах и телефонах вероятность нали, Vkni (ok), 21:13 , 07-Окт-13, (127)

А как же виндовс фон Хотя я согласен - лучше считать его за ноль А я думал - , Аноним (-), 12:00 , 10-Окт-13, (143)

Тем временем парни из IBM уже запилили LLVM и Clang для Power и System Z , annulen (ok), 13:05 , 07-Окт-13, (106) –2

Осталось всего ничего спустить фанатизм в унитаз и честно сообщить нам сколько , Аноним (-), 12:01 , 10-Окт-13, (144)

Вам повторить про более лучшую оптимизацию и большее количество поддерживаемых п, BratSinot (ok), 09:03 , 04-Окт-13, (24) +1

бессмысленно, оно в этом ничего не понимает достаточно пассажа про 171 обфусц, arisu (ok), 15:57 , 04-Окт-13, (67) +2

Что-то НеОбфусцированная архитектура LLVM оказалась настолько не готова к тому ч, Аноним (-), 09:57 , 05-Окт-13, (81) +3

да тут начинать надо с того, что никакой 171 обфусцированой архитектуры 187 , arisu (ok), 10:02 , 05-Окт-13, (83) +2

А с этим никто и не спорит Просто объем маркетингового буллшита текущего из нек, Аноним (-), 11:57 , 10-Окт-13, (142)

казалось бы при чём тут огрызок 8230 , arisu (ok), 12:20 , 10-Окт-13, (152)

Скоро окажется, что gpu работает наравне с cpu и последний можно убрать Потом о, ssy (?), 00:37 , 04-Окт-13, (2) +4 //

Еще лет 7-8 назад один из разрабов Nvidia вывалил на сайте developer nvidia com,, pavlinux (ok), 00:47 , 04-Окт-13, (5) +4 //

Не в начале апреля пост был , Аноним (-), 00:52 , 04-Окт-13, (6) //

Симшьно, ща уписаюсь http www cs utah edu wbsun gpustore pdf, pavlinux (ok), 00:56 , 04-Окт-13, (7)
Кстати, на Опеннете новость была , pavlinux (ok), 01:44 , 04-Окт-13, (10) +1

За вами тоже уже выехали , zhenya_k (?), 11:11 , 04-Окт-13, (36) –2

Извинитесь , Аноним (-), 11:31 , 04-Окт-13, (40)

http www opennet ru opennews art shtml num 23833 nVidia Fermi сможет выполнять, Аноним (-), 09:17 , 04-Окт-13, (26) +1

Это завязано на CUDA и блободрайвере, что для ядра сильно-сильно не айс Вот есл, Аноним (-), 11:02 , 04-Окт-13, (35)

Какие еще слова знаешь , Аноним (-), 11:54 , 04-Окт-13, (42) +1

Wiki всем доступно, можешь и ты просветиться , Аноним (-), 16:45 , 04-Окт-13, (70) –1

И как именно апи для декодирования видео относится к вычислениям на GPU , Аноним (-), 09:59 , 05-Окт-13, (82)

А ещё был более-менее реальный proof of concept червя, живущего исключительно в , vitalif (ok), 00:58 , 04-Окт-13, (8)

Это никогда не случится Вы не особо представляете как вообще GPU работает Дл, анонимус (??), 11:17 , 04-Окт-13, (37) +2

Странная эта борьба за новые языки и возможности Все время пытаются сделать лаз, rshadow (ok), 01:38 , 04-Окт-13, (9) +2 //

Речь скорее идет о изобретении инструментов переноса старого кода и инструментов, Аноним (-), 03:32 , 04-Окт-13, (12)

Отличненько, - горю желанием заценить , jOKer (ok), 03:53 , 04-Окт-13, (13)
забавно, конечно, но редкостные извращенцы что этот, что llvm-щики , arisu (ok), 04:33 , 04-Окт-13, (14) //

На миллионyю по счету просьбу засветить свой код, который лучше, будет традицион, Аноним (-), 07:22 , 04-Окт-13, (16) //

проси на здоровье, за спрос денег не берут , arisu (ok), 14:36 , 04-Окт-13, (59) +2

Предложи более прямой способ сгенерить шейдеры для GPU, например Как ты понимае, Аноним (-), 08:42 , 04-Окт-13, (22) //

Вы прям так спрашиваете как будто arisu разбирается в компьютерах и не просто та, Аноним (-), 14:05 , 04-Окт-13, (58) //

не мешай ему дилетанствовать c самовлюбленным апломбом, вон уже чуть ниже поток , Аноним (-), 19:21 , 04-Окт-13, (76) –2

пожимает плечами конкретная сущность 8212 это намертво зависающий движок ре, arisu (ok), 19:29 , 04-Окт-13, (77) +6

Красиво приложил Мсье, что вы, как можно, эппл на такие навороты не рассчиты, Аноним (-), 11:34 , 05-Окт-13, (84) +1

вот, кстати, только что в списке рассылки Lua пришло , arisu (ok), 12:09 , 05-Окт-13, (90)

Справедливости ради - почитай логи коммитов к амдшному окрытому драйверу GCC, Аноним (-), 11:55 , 10-Окт-13, (141)

так я и на gcc-шные баги наступал как-нибудь под настроение 8212 если вспомн, arisu (ok), 12:04 , 10-Окт-13, (145)

Это какая версия компилятора Т е кодstruct z_t int a int b inline vo, Vkni (ok), 19:31 , 05-Окт-13, (95)

3 3 не знаю и проверять лень там функция несколько сложнее, возвращает тоже стр, arisu (ok), 19:37 , 05-Окт-13, (96) +1

Выкладывай отпрепроцессенный файл и опции компиляции, я проверю , annulen (ok), 14:33 , 07-Окт-13, (109) –1

Не выложит, это принципиально Будет тот же графоманский поток околокомпьютеорны, Аноним (-), 21:08 , 07-Окт-13, (126) –1

Милый Аноним, вы тоже не понимаете, что заниматься социальными игрищами, надев м, Vkni (ok), 21:38 , 07-Окт-13, (131) +1

http www opennet ru openforum vsluhforumID3 91996 html 133, Vkni (ok), 21:58 , 07-Окт-13, (134)

ты мне гешефт поломал, кстати я-то надеялся, что денег дадут за сэмпл , arisu (ok), 22:03 , 07-Окт-13, (137)

В том виде, что ты написал, это очень похоже на неопределённое поведение Причём, Vkni (ok), 21:19 , 07-Окт-13, (128) –1

я про си и говорил нулевую польза 8212 это если бы меня преупреждением обруг, arisu (ok), 21:31 , 07-Окт-13, (129)

Стат анализатор у clang а говно, хотя попробуй, прогони его, авось ругнётся А , Vkni (ok), 21:37 , 07-Окт-13, (130)

его, вроде, отдельно собирать надо потом попробую как-нибудь, git всё помнит, е, arisu (ok), 21:56 , 07-Окт-13, (132) +1

Уже не надо - http www opennet ru openforum vsluhforumID3 91996 html 133, Vkni (ok), 22:00 , 07-Окт-13, (135)

Программа 8 ---------------------------------------------- 8typedef struct SSS, Vkni (ok), 21:57 , 07-Окт-13, (133)

благодарю могу от себя добавить, что gcc 4 8 1 на x86 тоже никаких ворнингов не, arisu (ok), 22:00 , 07-Окт-13, (136)

предлагаю унифицировать промежуточную VM для оных GPU, а драйвера пусть при нео, arisu (ok), 14:41 , 04-Окт-13, (60) //

Уже была попытка, кстати Называлось сие TGSI, см http people freedesktop org, Аноним (-), 11:50 , 05-Окт-13, (85)

как я уже сказал 8212 тут две отдельные ветки беседы надо JIT в одну сторону, arisu (ok), 11:56 , 05-Окт-13, (87) +1

Компиляция шейдеров во время выполнения происходит, по поводу чего не вижу глоба, Аноним (-), 13:18 , 05-Окт-13, (91) –1

это потому, что про JIT-ы ты тоже знаешь только три символа, как и про X11 остал, arisu (ok), 15:10 , 05-Окт-13, (93) +1

Да это пофигу - общую суть затеи с шейдерами и CL ядрами я усек и вижу что народ, Аноним (-), 11:41 , 10-Окт-13, (138)

я заметил только вот беда это не JIT, это кросс-компиляция 171 не в лотерею,, arisu (ok), 12:11 , 10-Окт-13, (148)

Для си-подобных языков это не мегаизвращение, а наиболее естественный метод JIT-, annulen (ok), 14:37 , 07-Окт-13, (111) –1

8212 алё, Хьюстон, у нас проблемы воробей 8212 спокойно, уже везём ядерну, arisu (ok), 14:50 , 07-Окт-13, (112) +1

Проще взять готовый фронт-енд для С-подобных языков и готовый бэкэнд для JIT, че, annulen (ok), 15:17 , 07-Окт-13, (113) –1

8212 а пользователь 8212 а нам какое дело купит процессор поновее и ещё 1, arisu (ok), 15:19 , 07-Окт-13, (114) +1

угу, для питона, руби, перла, пэхапе - первые будут потом всякие тикли, APL и пр, Аноним (-), 07:21 , 04-Окт-13, (15) //

не особо и вообще, для многих 171 динамических 187 языков AOT-компилятор , arisu (ok), 14:51 , 04-Окт-13, (61) +1

Я может быть чего-то не понимаю, но Gentoo вроде бы давно придумали И компилятс, Vkni (ok), 07:30 , 04-Окт-13, (17) –4 //

Вы вообще нихрена не понимаете И гентушники тут ни о чем Что есть у гентушнико, Аноним (-), 08:39 , 04-Окт-13, (21) //

действительно, то ли дело 8212 прямо в драйвер вкорячить немеряных размеров б, arisu (ok), 15:01 , 04-Окт-13, (64) +1 //

Меня, если честно, беспокоит вопрос времени - gcc -O2 значительно тормознее gcc , Vkni (ok), 18:16 , 04-Окт-13, (72)

да и памяти оно тоже кушает при этом libjit 8212 если выкинуть вливы 8212 , arisu (ok), 18:24 , 04-Окт-13, (73) +1

В gcc 4 8 вроде как потребление памяти заметно скостили, правда там в основном н, Аноним (-), 11:55 , 05-Окт-13, (86)

jit-компилятором однозначно не надо, jit-ы не для этого совсем придуманы оно ещ, arisu (ok), 12:06 , 05-Окт-13, (89)

Мда, и кто-то еще заикается про малое количество архитектур, поддерживаемых LLVM, annulen (ok), 18:37 , 07-Окт-13, (120) –1
Оно достаточно близко по смыслу имхо - код для GPU генерится на лету, по ходу вы, Аноним (-), 11:49 , 10-Окт-13, (139)

оно совершенно далеко и по смыслу, и по целям, и по требованиям и вот ты как ра, arisu (ok), 12:15 , 10-Окт-13, (150)

Использовать gcc для jit какая-то нелепость при наличии llvm , Аноним (-), 20:34 , 04-Окт-13, (78) //

не большая, чем использовать для этого llvm , arisu (ok), 09:35 , 05-Окт-13, (80) –1

То, что ребята пошли по пути LLVM не может не радовать Вот только они опоздали , lucentcode (ok), 13:20 , 05-Окт-13, (92) //

Особенно классно с LLVM сношались амдшники, которые добрых 2 года пытались убе, Аноним (-), 11:52 , 10-Окт-13, (140)

а вот это уже интересно, хрюкотающий зелюк (?), 23:27 , 06-Окт-13, (97) –2

Сообщения [Сортировка по времени | RSS]

60. "Основанные на GCC проекты JIT-компилятора и расширения,..." +/–

Сообщение от arisu (ok), 04-Окт-13, 14:41

> Предложи более прямой способ сгенерить шейдеры для GPU, например?
предлагаю: унифицировать промежуточную VM для оных GPU, а драйвера пусть при необходимости «докомпиливают» её в родной код. причём поскольку GPU — штуки специфические, то и VM можно сдизайнить соответствующим образом, чтобы на стадии «компиляция в код VM» делалось побольше всего.
но, конечно, наименее костыльный метод — это, я так понимаю, таскать с собой всю механику GCC (которая изначально не предназначена была для подобного использования). или монстра-переростка llvm.
и да: я не уточнил, что подразумеваю использование gcc/llvm именно как jit. это и есть мегаизвращение. что, собственно, доказывает нам Mike Pall со своим LuaJIT2.

Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

85. "Основанные на GCC проекты JIT-компилятора и расширения,..." +/–

Сообщение от Аноним (-), 05-Окт-13, 11:50

> предлагаю: унифицировать промежуточную 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 года назад сабжа не было :)

Ответить | Правка | Наверх | Cообщить модератору

87. "Основанные на GCC проекты JIT-компилятора и расширения,..." +1 +/–

Сообщение от arisu (ok), 05-Окт-13, 11:56

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

Ответить | Правка | Наверх | Cообщить модератору

91. "Основанные на GCC проекты JIT-компилятора и расширения,..." –1 +/–

Сообщение от Аноним (-), 05-Окт-13, 13:18

> как я уже сказал — тут две отдельные ветки беседы надо. JIT
> в одну сторону, компиляцию шэйдеров — в другую.
Компиляция шейдеров во время выполнения происходит, по поводу чего не вижу глобальных отличий от JIT в плане логики действа, если честно. Единственное чем оно так глобально отличается - сгенеренный код потом не на системном проце выполняется а отправится в GPU.
> для шэйдеров и можно, и нужно позвать внешний компилятор.
Не, спасибочки, еще не хватало чтобы при запуске какойнить игрушки 100500 внешних процессов пахало. Нафиг-нафиг.
> помимо того, что это обезопасит драйвера от ошибок в компиляторе,
Программа все-равно не сможет корректно работать если шейдер или CLный кернель не скомпилился. Если компилер даже совсем навернется где-то в прога -> GL/CL либы -> компилер - да и болт с ним. Нехай чинят, юзери лишний раз прессанут разработчиков чтобы обезглючили эту хрень.
> можно ещё и обновлять раздельно: не надо переустанавливать драйвера,
> если вышел новый релиз компилятора шэйдеров.
Компилятор шейдеров не имеет самоценности как отдельная сущность в отрыве от драйверов, которые позволяют то что получилось в GPU запихнуть и запустить.
> просто в винде создать новый процесс сильно дороже, чем в пингвинусе, вот
> и занимаются извращениями.
А при чем тут вообще винда? Амдшники в открытом драйвере юзанули, с аргументом что там парсер есть и кодогенератор какой-никакой.

Ответить | Правка | Наверх | Cообщить модератору

93. "Основанные на GCC проекты JIT-компилятора и расширения,..." +1 +/–

Сообщение от arisu (ok), 05-Окт-13, 15:10

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

Ответить | Правка | Наверх | Cообщить модератору

138. "Основанные на GCC проекты JIT-компилятора и расширения,..." +/–

Сообщение от Аноним (-), 10-Окт-13, 11:41

> это потому, что про JIT-ы ты тоже знаешь только три символа, как и про X11.
Да это пофигу - общую суть затеи с шейдерами и CL ядрами я усек и вижу что народ тяготеет к сборке этого в рантайме, когда оно по факту понадобилось. Почти как JIT по общей логике получается. А gcc на такое исходно никогда никто не затачивал вообще - он обычный такой компилятор.
> остальную феерию просто вытер, потому что тут опять «обнять и плакать».
Да ну, брось. Ты всякой всякой феерии тоже не меньше генеришь.
А насчет иксов и прочая - я буду пользоваться той графической системой которая будет для меня работать лучше. И это явно не про иксы. Насчет того кто в в чем разбирается: реально разбирается в иксах полтора землекопа на всю планету. Остальные приходят в ужас от увиденного и действительно не разбираются в иксах. Ну или по крайней мере в их коде, являюищмся ужасным месивом костылей и подпорок. Лично мне намного интереснее будет посмотреть что такие как ты разбирающиеся будут делать когда парочка грандов типа Кейта Пакарда окончаетльно задолбаются с этим месивом. У тебя и vkni появится чудный шанс показать всему миру как ты там разбираешься.

Ответить | Правка | Наверх | Cообщить модератору

148. "Основанные на GCC проекты JIT-компилятора и расширения,..." +/–

Сообщение от arisu (ok), 10-Окт-13, 12:11

>> это потому, что про JIT-ы ты тоже знаешь только три символа, как и про X11.
> Да это пофигу
я заметил.
> общую суть затеи с шейдерами и CL ядрами я усек
только вот беда: это не JIT, это кросс-компиляция. «не в лотерею, а в преферанс. не выиграл, а проиграл. не квартиру, а машину. а так всё верно, да.»
> Да ну, брось. Ты всякой всякой феерии тоже не меньше генеришь.
все ошибаются. я тоже ошибаюсь, конечно. но в темы, где я совсем ничего не понимаю, я стараюсь вообще не лезть.
> делать когда парочка грандов типа Кейта Пакарда
вот его вообще не надо было туда пускать. «гранд», блин. забирайте это к себе куда угодно и не возвращайте никогда.
> У тебя и vkni появится чудный шанс показать всему миру как ты там разбираешься.
(пожимает плечами) возможно, придётся. правда, лично я «всему миру» ничего доказывать и показывать не собираюсь, я если буду пилить — то совсем для других целей. потому как форк для распальцовки и сейчас сделать никто не мешает.

Ответить | Правка | Наверх | Cообщить модератору

111. "Основанные на GCC проекты JIT-компилятора и расширения,..." –1 +/–

Сообщение от annulen (ok), 07-Окт-13, 14:37

> и да: я не уточнил, что подразумеваю использование gcc/llvm именно как jit.
> это и есть мегаизвращение. что, собственно, доказывает нам Mike Pall со
> своим LuaJIT2.
Для си-подобных языков это не мегаизвращение, а наиболее естественный метод JIT-компиляции. Для Lua LLVM JIT сливает, но не потому что он плохой, а потому что заточен на совсем другие языки.
Кстати, в WebKit яббловцы прикрутили JIT-компиляцию JS с помощью LLVM в качестве четвертого уровня JIT.

Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

112. "Основанные на GCC проекты JIT-компилятора и расширения,..." +1 +/–

Сообщение от arisu (ok), 07-Окт-13, 14:50

> Для си-подобных языков это не мегаизвращение, а наиболее естественный метод JIT-компиляции.
— алё, Хьюстон, у нас проблемы: воробей!
— спокойно, уже везём ядерную боеголовку!
> Для Lua LLVM JIT сливает, но не потому что он плохой,
> а потому что заточен на совсем другие языки.
тут вот в списке рассылки LuaJIT забавное пролетело: транслятор байт-кода JVM в байт-код LuaJIT. первая версия — в общем-то PoC — показала (на микротестах, конечно) результаты кое-где получше хотспота, а кое-где ненамного хуже. ну, и кое-где таки хуже — потому что автор транслятора сделал некоторые вещи неправильно, на что СуперМайк ему указал. про потребление памяти лучше умолчу вообще, чтобы у жавистов падучая не началась.
это я к чему? к тому, что с джитингом «статически типизированых» языков LuaJIT2 справляется тоже весьма неплохо.
> Кстати, в WebKit яббловцы прикрутили JIT-компиляцию JS с помощью LLVM в качестве
> четвертого уровня JIT.
ну, любят люди извращения — кто ж им запретить-то может…

Ответить | Правка | Наверх | Cообщить модератору

113. "Основанные на GCC проекты JIT-компилятора и расширения,..." –1 +/–

Сообщение от annulen (ok), 07-Окт-13, 15:17

>> Для си-подобных языков это не мегаизвращение, а наиболее естественный метод JIT-компиляции.
> — алё, Хьюстон, у нас проблемы: воробей!
> — спокойно, уже везём ядерную боеголовку!
Проще взять готовый фронт-енд для С-подобных языков и готовый бэкэнд для JIT, чем городить велосипеды.

Ответить | Правка | Наверх | Cообщить модератору

114. "Основанные на GCC проекты JIT-компилятора и расширения,..." +1 +/–

Сообщение от arisu (ok), 07-Окт-13, 15:19

> Проще взять готовый фронт-енд для С-подобных языков и готовый бэкэнд для JIT,
> чем городить велосипеды.
— а пользователь?
— а нам какое дело? купит процессор поновее и ещё 16GB памяти, это его проблемы!

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	60. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от arisu (ok), 04-Окт-13, 14:41
	> Предложи более прямой способ сгенерить шейдеры для GPU, например? предлагаю: унифицировать промежуточную VM для оных GPU, а драйвера пусть при необходимости «докомпиливают» её в родной код. причём поскольку GPU — штуки специфические, то и VM можно сдизайнить соответствующим образом, чтобы на стадии «компиляция в код VM» делалось побольше всего. но, конечно, наименее костыльный метод — это, я так понимаю, таскать с собой всю механику GCC (которая изначально не предназначена была для подобного использования). или монстра-переростка llvm. и да: я не уточнил, что подразумеваю использование gcc/llvm именно как jit. это и есть мегаизвращение. что, собственно, доказывает нам Mike Pall со своим LuaJIT2.
	Ответить \| Правка \| К родителю #22 \| Наверх \| Cообщить модератору


	85. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от Аноним (-), 05-Окт-13, 11:50
	> предлагаю: унифицировать промежуточную 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 года назад сабжа не было :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	87. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+1 +/–
	Сообщение от arisu (ok), 05-Окт-13, 11:56
	как я уже сказал — тут две отдельные ветки беседы надо. JIT в одну сторону, компиляцию шэйдеров — в другую. для шэйдеров и можно, и нужно позвать внешний компилятор. помимо того, что это обезопасит драйвера от ошибок в компиляторе, можно ещё и обновлять раздельно: не надо переустанавливать драйвера, если вышел новый релиз компилятора шэйдеров. просто в винде создать новый процесс сильно дороже, чем в пингвинусе, вот и занимаются извращениями.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	91. "Основанные на GCC проекты JIT-компилятора и расширения,..."	–1 +/–
	Сообщение от Аноним (-), 05-Окт-13, 13:18
	> как я уже сказал — тут две отдельные ветки беседы надо. JIT > в одну сторону, компиляцию шэйдеров — в другую. Компиляция шейдеров во время выполнения происходит, по поводу чего не вижу глобальных отличий от JIT в плане логики действа, если честно. Единственное чем оно так глобально отличается - сгенеренный код потом не на системном проце выполняется а отправится в GPU. > для шэйдеров и можно, и нужно позвать внешний компилятор. Не, спасибочки, еще не хватало чтобы при запуске какойнить игрушки 100500 внешних процессов пахало. Нафиг-нафиг. > помимо того, что это обезопасит драйвера от ошибок в компиляторе, Программа все-равно не сможет корректно работать если шейдер или CLный кернель не скомпилился. Если компилер даже совсем навернется где-то в прога -> GL/CL либы -> компилер - да и болт с ним. Нехай чинят, юзери лишний раз прессанут разработчиков чтобы обезглючили эту хрень. > можно ещё и обновлять раздельно: не надо переустанавливать драйвера, > если вышел новый релиз компилятора шэйдеров. Компилятор шейдеров не имеет самоценности как отдельная сущность в отрыве от драйверов, которые позволяют то что получилось в GPU запихнуть и запустить. > просто в винде создать новый процесс сильно дороже, чем в пингвинусе, вот > и занимаются извращениями. А при чем тут вообще винда? Амдшники в открытом драйвере юзанули, с аргументом что там парсер есть и кодогенератор какой-никакой.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	93. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+1 +/–
	Сообщение от arisu (ok), 05-Окт-13, 15:10
	> по поводу чего не вижу глобальных отличий от JIT это потому, что про JIT-ы ты тоже знаешь только три символа, как и про X11. остальную феерию просто вытер, потому что тут опять «обнять и плакать».
	Ответить \| Правка \| Наверх \| Cообщить модератору


	138. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от Аноним (-), 10-Окт-13, 11:41
	> это потому, что про JIT-ы ты тоже знаешь только три символа, как и про X11. Да это пофигу - общую суть затеи с шейдерами и CL ядрами я усек и вижу что народ тяготеет к сборке этого в рантайме, когда оно по факту понадобилось. Почти как JIT по общей логике получается. А gcc на такое исходно никогда никто не затачивал вообще - он обычный такой компилятор. > остальную феерию просто вытер, потому что тут опять «обнять и плакать». Да ну, брось. Ты всякой всякой феерии тоже не меньше генеришь. А насчет иксов и прочая - я буду пользоваться той графической системой которая будет для меня работать лучше. И это явно не про иксы. Насчет того кто в в чем разбирается: реально разбирается в иксах полтора землекопа на всю планету. Остальные приходят в ужас от увиденного и действительно не разбираются в иксах. Ну или по крайней мере в их коде, являюищмся ужасным месивом костылей и подпорок. Лично мне намного интереснее будет посмотреть что такие как ты разбирающиеся будут делать когда парочка грандов типа Кейта Пакарда окончаетльно задолбаются с этим месивом. У тебя и vkni появится чудный шанс показать всему миру как ты там разбираешься.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	148. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от arisu (ok), 10-Окт-13, 12:11
	>> это потому, что про JIT-ы ты тоже знаешь только три символа, как и про X11. > Да это пофигу я заметил. > общую суть затеи с шейдерами и CL ядрами я усек только вот беда: это не JIT, это кросс-компиляция. «не в лотерею, а в преферанс. не выиграл, а проиграл. не квартиру, а машину. а так всё верно, да.» > Да ну, брось. Ты всякой всякой феерии тоже не меньше генеришь. все ошибаются. я тоже ошибаюсь, конечно. но в темы, где я совсем ничего не понимаю, я стараюсь вообще не лезть. > делать когда парочка грандов типа Кейта Пакарда вот его вообще не надо было туда пускать. «гранд», блин. забирайте это к себе куда угодно и не возвращайте никогда. > У тебя и vkni появится чудный шанс показать всему миру как ты там разбираешься. (пожимает плечами) возможно, придётся. правда, лично я «всему миру» ничего доказывать и показывать не собираюсь, я если буду пилить — то совсем для других целей. потому как форк для распальцовки и сейчас сделать никто не мешает.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	111. "Основанные на GCC проекты JIT-компилятора и расширения,..."	–1 +/–
	Сообщение от annulen (ok), 07-Окт-13, 14:37
	> и да: я не уточнил, что подразумеваю использование gcc/llvm именно как jit. > это и есть мегаизвращение. что, собственно, доказывает нам Mike Pall со > своим LuaJIT2. Для си-подобных языков это не мегаизвращение, а наиболее естественный метод JIT-компиляции. Для Lua LLVM JIT сливает, но не потому что он плохой, а потому что заточен на совсем другие языки. Кстати, в WebKit яббловцы прикрутили JIT-компиляцию JS с помощью LLVM в качестве четвертого уровня JIT.
	Ответить \| Правка \| К родителю #60 \| Наверх \| Cообщить модератору


	112. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+1 +/–
	Сообщение от arisu (ok), 07-Окт-13, 14:50
	> Для си-подобных языков это не мегаизвращение, а наиболее естественный метод JIT-компиляции. — алё, Хьюстон, у нас проблемы: воробей! — спокойно, уже везём ядерную боеголовку! > Для Lua LLVM JIT сливает, но не потому что он плохой, > а потому что заточен на совсем другие языки. тут вот в списке рассылки LuaJIT забавное пролетело: транслятор байт-кода JVM в байт-код LuaJIT. первая версия — в общем-то PoC — показала (на микротестах, конечно) результаты кое-где получше хотспота, а кое-где ненамного хуже. ну, и кое-где таки хуже — потому что автор транслятора сделал некоторые вещи неправильно, на что СуперМайк ему указал. про потребление памяти лучше умолчу вообще, чтобы у жавистов падучая не началась. это я к чему? к тому, что с джитингом «статически типизированых» языков LuaJIT2 справляется тоже весьма неплохо. > Кстати, в WebKit яббловцы прикрутили JIT-компиляцию JS с помощью LLVM в качестве > четвертого уровня JIT. ну, любят люди извращения — кто ж им запретить-то может…
	Ответить \| Правка \| Наверх \| Cообщить модератору


	113. "Основанные на GCC проекты JIT-компилятора и расширения,..."	–1 +/–
	Сообщение от annulen (ok), 07-Окт-13, 15:17
	>> Для си-подобных языков это не мегаизвращение, а наиболее естественный метод JIT-компиляции. > — алё, Хьюстон, у нас проблемы: воробей! > — спокойно, уже везём ядерную боеголовку! Проще взять готовый фронт-енд для С-подобных языков и готовый бэкэнд для JIT, чем городить велосипеды.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	114. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+1 +/–
	Сообщение от arisu (ok), 07-Окт-13, 15:19
	> Проще взять готовый фронт-енд для С-подобных языков и готовый бэкэнд для JIT, > чем городить велосипеды. — а пользователь? — а нам какое дело? купит процессор поновее и ещё 16GB памяти, это его проблемы!
	Ответить \| Правка \| Наверх \| Cообщить модератору