The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

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

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


14. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +/–
Сообщение от arisu (ok), 04-Окт-13, 04:33 
забавно, конечно, но редкостные извращенцы. что этот, что llvm-щики.
Ответить | Правка | Наверх | Cообщить модератору

16. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +/–
Сообщение от Аноним (-), 04-Окт-13, 07:22 
На миллионyю по счету просьбу засветить свой код, который лучше, будет традиционное мужественное самоотверженное молчание ? Часто незнакомых людей "редкостными извращенцами" в лицо называешь?
Ответить | Правка | Наверх | Cообщить модератору

59. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +2 +/–
Сообщение от arisu (ok), 04-Окт-13, 14:36 
> На миллионyю по счету просьбу засветить свой код, который лучше, будет традиционное
> мужественное самоотверженное молчание ? Часто незнакомых людей «редкостными извращенцами»
> в лицо называешь?

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

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

22. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +/–
Сообщение от Аноним (-), 04-Окт-13, 08:42 
> забавно, конечно, но редкостные извращенцы. что этот, что llvm-щики.

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

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

58. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +/–
Сообщение от Аноним (-), 04-Окт-13, 14:05 
>> забавно, конечно, но редкостные извращенцы. что этот, что llvm-щики.
> Предложи более прямой способ сгенерить шейдеры для GPU, например? Как ты понимаешь,
> заранее вообще неизвестно что там у юзеря: ати, нвидия, интел или
> вообще какой-нить ARM. Поэтому программа явно не может таскать с собой
> для этого предкомпилированный код.

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

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

76. "Основанные на GCC проекты JIT-компилятора и расширения,..."  –2 +/–
Сообщение от Аноним (-), 04-Окт-13, 19:21 
не мешай ему дилетанствовать c самовлюбленным апломбом, вон уже чуть ниже поток полился про "ощущения чуйств" на тему GCC. Замени GCC и LLVM на Коллайдер и систему жизнеобеспечения автономного модуля на Марсе, впрочем и митохондрии подойдут - суть не поменяется. Костьми ляжет, но ни слова не дождешься о конкретных проверяемых сущностях.
Ответить | Правка | Наверх | Cообщить модератору

77. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +6 +/–
Сообщение от arisu (ok), 04-Окт-13, 19:29 
(пожимает плечами) конкретная сущность — это намертво зависающий движок регулярок, нежно портированый из plan9 и допиленый. тупой шланг не врубается, что inline-функция может модифицировать некоторые переменные, передаваемые ей в структуре (хотя никакого const там нет), поэтому сначала переменную где-то кэширует, а потом использует её старое значение. в итоге получается бесконечный цикл вида «jmp $». чего лично я от компилятора такого возраста никак не ожидал и был несколько в офигее, когда софтина подвисла, слопав весь процессор.

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

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

84. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +1 +/–
Сообщение от Аноним (-), 05-Окт-13, 11:34 
Красиво приложил :).
> нежно портированый из plan9 и допиленый. тyпой шланг не врубается,

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

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

90. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +/–
Сообщение от arisu (ok), 05-Окт-13, 12:09 
вот, кстати, только что в списке рассылки 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.
Ответить | Правка | Наверх | Cообщить модератору

141. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +/–
Сообщение от Аноним (-), 10-Окт-13, 11:55 
> вот, кстати, только что в списке рассылки Lua пришло:

Справедливости ради - почитай логи коммитов к амдшному окрытому драйверу :). GCC там тоже  досталось на орехи, пришлось баг воркэраундить :)

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

145. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +/–
Сообщение от arisu (ok), 10-Окт-13, 12:04 
так я и на gcc-шные баги наступал. как-нибудь под настроение — если вспомню — и его попинаю. но кланг пинать забавней.
Ответить | Правка | Наверх | Cообщить модератору

95. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +/–
Сообщение от Vkni (ok), 05-Окт-13, 19:31 
> тупой шланг не врубается, что
> inline-функция может модифицировать некоторые переменные, передаваемые ей в структуре

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

struct z_t
{
    int a;
    int b;
};

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

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

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

96. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +1 +/–
Сообщение от arisu (ok), 05-Окт-13, 19:37 
> Это какая версия компилятора?

3.3.

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

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

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

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

109. "Основанные на GCC проекты JIT-компилятора и расширения,..."  –1 +/–
Сообщение от annulen (ok), 07-Окт-13, 14:33 
>> Это какая версия компилятора?
> 3.3.
>> он откомпилирует неправильно?
> не знаю и проверять лень. там функция несколько сложнее, возвращает тоже структуру
> и используется в виде funcall(ss)->fld = ss->fld1, при этом ss->fld1 внутри
> функции меняется. но шланг этого не понимает, и использует старое значение.

Выкладывай отпрепроцессенный файл и опции компиляции, я проверю.

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

126. "Основанные на GCC проекты JIT-компилятора и расширения,..."  –1 +/–
Сообщение от Аноним (-), 07-Окт-13, 21:08 
Не выложит, это принципиально. Будет тот же графоманский поток околокомпьютеорных мыслей. Очень правдоподобный для не слишком дотошных, но не практике принципе не проверяемый. Вся суть аризу. "я ощущаю что этот концептуальный подход нелогичен, скучен и приличный человек не будет пользоваться". Спроси про делали и конкретные строки кода или патч - получишь в ответ еще более пространный графоманский водевиль с оскорблениями. Гланвое - ни строки кода.
Ответить | Правка | Наверх | Cообщить модератору

131. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +1 +/–
Сообщение от Vkni (ok), 07-Окт-13, 21:38 
> Не выложит, это принципиально. Будет тот же графоманский поток околокомпьютеорных мыслей.

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

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

134. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +/–
Сообщение от Vkni (ok), 07-Окт-13, 21:58 
> Выкладывай отпрепроцессенный файл и опции компиляции, я проверю.

http://www.opennet.ru/openforum/vsluhforumID3/91996.html#133

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

137. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +/–
Сообщение от arisu (ok), 07-Окт-13, 22:03 
ты мне гешефт поломал, кстати: я-то надеялся, что денег дадут за сэмпл.
Ответить | Правка | Наверх | Cообщить модератору

128. "Основанные на GCC проекты JIT-компилятора и расширения,..."  –1 +/–
Сообщение от Vkni (ok), 07-Окт-13, 21:19 
> p.s. собственно, после раздумий я не уверен, ошибка ли это компилятора, или
> идиотизм стандарта с очередной «неопределённой последовательностью». но принцип
> least surprise явно поломан, это раз. и два — если поведение
> неопределено, то компилятор должен плюнуть предупреждением.

В том виде, что ты написал, это очень похоже на неопределённое поведение. Причём тут даже C++-ом не пахнет, чистый C.

И, мне кажется, что именно в таких местах мы и получаем пользу от clang'а.

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

129. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +/–
Сообщение от arisu (ok), 07-Окт-13, 21:31 
> Причём тут даже C++-ом не пахнет, чистый C.

я про си и говорил.

> И, мне кажется, что именно в таких местах мы и получаем пользу
> от clang'а.

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

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

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

130. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +/–
Сообщение от Vkni (ok), 07-Окт-13, 21:37 
> нулевую. польза — это если бы меня преупреждением обругали.

Стат. анализатор у clang'а говно, хотя попробуй, прогони его, авось ругнётся. А для предупреждения эта штука слишком сложна - нужно проанализировать код внутри функции и убедиться, что таки да - меняет поле.

> я в упор не помню, что там в стандарте по этому поводу написано (там вообще фигни столько написано, что и у коня голова лопнет)

Язык C староват очень.

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

132. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +1 +/–
Сообщение от arisu (ok), 07-Окт-13, 21:56 
>> нулевую. польза — это если бы меня преупреждением обругали.
> Стат. анализатор у clang'а говно, хотя попробуй, прогони его, авось ругнётся.

его, вроде, отдельно собирать надо. потом попробую как-нибудь, git всё помнит, если что.

> для предупреждения эта штука слишком сложна — нужно проанализировать код внутри
> функции и убедиться, что таки да — меняет поле.

ну, там сразу перед return'ом ++ стоит, в принципе, ничего заковыристого. обычный data flow analysis, его и так делают.

>> я в упор не помню, что там в стандарте по этому поводу написано (там вообще фигни столько написано, что и у коня голова лопнет)
> Язык C староват очень.

дык вон недавно очередную ревизию стандарта приняли. фигни насовали, полезного — ноль. ну почему, например, не стандартизировать 2's-complement integer arithmetic? почему integer overflow не прописать? да куча софта пользуется тем, что это стандарт де-факто (хоть хэш-функции взять — куча на этом подвязана). почему не добавить конструкцию для проверки флажка переполнения, который есть у подавляющего большинства процессоров? это ведь офигенно упростило бы те же проверки на переполнение, которые можно было бы делать постфактум.

вот зачем в очередной раз пересматривать стандарт, чтобы бережно не добавлять туда ничего более-менее полезного irl? какого чёрта было плевать на уже введённый в ISO C90 __inline__ и сделать идиотское _Noreturn вместо __noreturn__? да ну их в анус, академиков сферических. я для себя давно решил, что стандарт — это gnu99, со всеми его вкусными расширениями.

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

135. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +/–
Сообщение от Vkni (ok), 07-Окт-13, 22:00 
> его, вроде, отдельно собирать надо. потом попробую как-нибудь, git всё помнит, если
> что.

Уже не надо - http://www.opennet.ru/openforum/vsluhforumID3/91996.html#133

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

133. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +/–
Сообщение от Vkni (ok), 07-Окт-13, 21:57 
Программа:
8><----------------------------------------------><8

typedef 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.

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

136. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +/–
Сообщение от arisu (ok), 07-Окт-13, 22:00 
благодарю. могу от себя добавить, что gcc 4.8.1 на x86 тоже никаких ворнингов не даёт. я, кстати, с -O2 собирал.
Ответить | Правка | Наверх | Cообщить модератору

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 | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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