forum.opennet.ru

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

Оглавление

Пример использования средств JIT-компиляции, появившихся в G..., opennews (ok), 08-Апр-15, (0) [смотреть все]

Компиляторы из промежуточного представления в бинарное имеют смысл при инсталляц, nc (ok), 20:09 , 08-Апр-15, (1) +3 //

Писать скрипты в сишном коде не на lua или, избавь Ктулху, на JavaScript, а на С, A.Stahl (ok), 20:21 , 08-Апр-15, (2) –5 //

Что-то я не вижу ничего хорошего в скриптах на Си Если же вы думаете, что это по, Аноним (-), 20:25 , 08-Апр-15, (3) +5 //

Есть программа на Си Нужно в ней что-то скриптовое Разумеется лучше чтобы этот, A.Stahl (ok), 20:28 , 08-Апр-15, (4)

Какой кусок кода в гипотетической, но уже написанной C-шной программе разумеетс, Сергей (??), 20:44 , 08-Апр-15, (6)

Скриптовый Т е часто изменяемый Возможно даже пользователем , A.Stahl (ok), 20:49 , 08-Апр-15, (10) –1

Пользоветель скорее умрет, но попросит сделать поддержку LUA вместо С , Сергей (??), 20:53 , 08-Апр-15, (14) +2
Частоизменяемый не проблема компилировать при разработке , Сергей (??), 20:54 , 08-Апр-15, (15) –1

В том то и дело, что изменяемый при эксплуатации, а не при разработке , Вулх (?), 21:09 , 08-Апр-15, (19)

Смотри пост 7 14, Сергей (??), 03:21 , 09-Апр-15, (34)

Чем лучше писать скрипты на C по сравнению с LUA , Сергей (??), 20:46 , 08-Апр-15, (7)

Тем, что зная Си ты уже автоматичемски знаешь Си Круто, да А вот знание Си ника, A.Stahl (ok), 20:50 , 08-Апр-15, (11) –1

Знание C C Tcl BASH мне тут же обеспечило знание LUA Попробуй под пытками зас, Сергей (??), 20:58 , 08-Апр-15, (17) +6
Все знают Бейсик, но это же не повод писать на нём абсолютно всё , Vkni (ok), 06:09 , 09-Апр-15, (37)

да ну, cmp (ok), 08:45 , 09-Апр-15, (42) +1

Обычно что-то скриптовое в программе нужно для расширения функциональности польз, Аноним (-), 20:48 , 08-Апр-15, (9) +1

О чем речь, если оно поддерживает си, то и луа автоматом, кому надо луа пусть ег, cmp (ok), 08:56 , 09-Апр-15, (43)

Я всего один раз написал на LUA, но с полпинка небольшой скрипт без предваритель, Сергей (??), 20:52 , 08-Апр-15, (12) +2

Lua божественнен Один из самых шустрых скриптовых языков, очень малые затраты н, Аноним (-), 20:47 , 08-Апр-15, (8) +1 //

Ну никто и не утверждает обратного Но сишникам приятней будет использовать Си уж, A.Stahl (ok), 20:52 , 08-Апр-15, (13) –1

Проще что На самолёте проще чем на троллейбусе , Аноним (-), 20:56 , 08-Апр-15, (16)

всё, A.Stahl (ok), 21:04 , 08-Апр-15, (18) –1

хэш 8208 таблицы, например куда уж несчастным скриптовикам до няшности и удобс, arisu (ok), 17:57 , 09-Апр-15, (45) +1

Для скриптовых нужд у C уж больно слабо в плане синтаксиса и высокоуровневых кон, Crazy Alex (ok), 00:03 , 09-Апр-15, (26)

Начал за здравие а закончил за упокой , Led (ok), 00:05 , 09-Апр-15, (28) –3

И в чём проблема Для скриптов нужно что-то, где, как минимум, можно автоматом у, Crazy Alex (ok), 02:34 , 09-Апр-15, (33)

Precompiled Headers Нет, не слышал https gcc gnu org onlinedocs gcc Precomp, Анончег (?), 01:29 , 09-Апр-15, (30) –1

Их хватает, чтобы компиляция не занимала вечность, но не для того, чтобы компили, Crazy Alex (ok), 02:29 , 09-Апр-15, (32)

Нельзя , Vkni (ok), 06:11 , 09-Апр-15, (38) –1

Запатентуй компилятор мата -- обогатишься - , Сергей (??), 03:25 , 09-Апр-15, (35) +3

Вообще-то, libgccjit - это всего лишь backend, т е генератор машинного кода А , Аноним (-), 11:34 , 09-Апр-15, (44) –1

Для разного нужно - динамическая оптимизация программы с учетом текущего профиля, Tav (ok), 20:30 , 08-Апр-15, (5) +4 //

Ну, это скорее её недостаток Ей ведь надо балансировать между скоростью запуска, freehck (ok), 22:18 , 08-Апр-15, (23) //

На серверах, где программа перезапускается редко и работает долго, это не пробле, Tav (ok), 23:00 , 08-Апр-15, (24)

Да, да, поддерживаю, пускай расскажет нам про Ъ-виды и НЕ-Ъ-виды , Анончег (?), 01:33 , 09-Апр-15, (31)
А у программ скомпилированных до конца , такой проблемы нет Суть в том, что от , freehck (ok), 07:03 , 09-Апр-15, (40)

Ну это не технические отличия, а вопрос позиционирования И на самом деле, произв, Tav (ok), 18:13 , 10-Апр-15, (46) –1

Да, это может дать прирост производительности Однако я не очень представляю, ка, freehck (ok), 15:26 , 22-Июн-15, (47)

Как-то так шейдеры в GPU вгружают например Хотя иногда скомпиленое и кэшируют , Аноним (-), 21:43 , 08-Апр-15, (21)
Разные аппаратные платформы - это и разное число ядер, в том числе , КарМер (?), 22:17 , 08-Апр-15, (22) //

Тогда не JIT, а просто сборка на клиенте Но вообще-то разное число ядер в коде, Crazy Alex (ok), 00:07 , 09-Апр-15, (29)

JIT-компиляция может учесть все экстенжены текущего процессора, что приведет к з, Qld (?), 23:38 , 08-Апр-15, (25) –1 //

Так здесь не JIT, а вполне себе нормальная AOT-компиляция нужна - при первом за, Crazy Alex (ok), 00:05 , 09-Апр-15, (27)

GCC 5 начинает догонять старые версии LLVM , Аноним (-), 21:28 , 08-Апр-15, (20) //

Забавность ситуации заключается в том, что у gcc намного более богатые возможнос, MaMoHT (?), 05:05 , 09-Апр-15, (36) +4 //

Это вряд ли Они ведь компилируются только в одну архитектуру, а потом на лету п, freehck (ok), 07:09 , 09-Апр-15, (41) +1

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

23. "Пример использования средств JIT-компиляции, появившихся в G..." +/–

Сообщение от freehck (ok), 08-Апр-15, 22:18

> динамическая оптимизация программы с учетом текущего профиля выполнения (JVM);
Ну, это скорее её недостаток. Ей ведь надо балансировать между скоростью запуска и скоростью работы, вот и выкручиваются, как могут.
> модификация программы во время выполнения (Лисп, Смолток и др.);
Вот. Именно для этого JIT и нужен в первую очередь. Но упаси боже, не в том же виде, в каком предлагают его LLVM и JVM.
> предметно-ориентированные языки, являющиеся частью интерфейса пользователя.
А вот тут я бы попросил объяснить, что имеется в виду.

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

24. "Пример использования средств JIT-компиляции, появившихся в G..." +/–

Сообщение от Tav (ok), 08-Апр-15, 23:00

> Ну, это скорее её недостаток. Ей ведь надо балансировать между скоростью запуска и скоростью работы, вот и выкручиваются, как могут.
На серверах, где программа перезапускается редко и работает долго, это не проблема.
> Но упаси боже, не в том же виде, в каком предлагают его LLVM и JVM.
В чем суть отличий "того же вида" от не того?
> А вот тут я бы попросил объяснить, что имеется в виду.
Различные системы, предоставляющие пользователю специализированный язык для решения его задач: Маткады всякие, статистические пакеты типа R или Incanter, шеллы, приложения с поддержкой макрокоманд, мало ли что еще. JIT в них не всегда оправдан, но бывают случаи, когда объем вычислений значителен и JIT окупается.

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

31. "Пример использования средств JIT-компиляции, появившихся в G..." +/–

Сообщение от Анончег (?), 09-Апр-15, 01:33

> В чем суть отличий "того же вида" от не того?
Да, да, поддерживаю, пускай расскажет нам про "Ъ-виды" и "НЕ-Ъ-виды".

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

40. "Пример использования средств JIT-компиляции, появившихся в G..." +/–

Сообщение от freehck (ok), 09-Апр-15, 07:03

>> Ну, это скорее её недостаток. Ей ведь надо балансировать между скоростью запуска и скоростью работы, вот и выкручиваются, как могут.
> На серверах, где программа перезапускается редко и работает долго, это не проблема.
А у программ скомпилированных "до конца", такой проблемы нет.
>> Но упаси боже, не в том же виде, в каком предлагают его LLVM и JVM.
> В чем суть отличий "того же вида" от не того?
Суть в том, что от проектов LLVM и JVM то и дело слышны возгласы, что мол проекты позволяют достигнуть производительности компилируемых языков, и что производительность их за так сильно возросла именно за счёт JIT. Надо понимать, что JIT всё-таки хоть и может привести к повышению производительности, но вообще говоря не для неё создан, ибо "до конца" с компилированные программы по-любому дадут более оптимизированный код.
А вот что касается возможности генерации кода на лету - то это действительно очень востребовано. Во-первых любой REPL[1] на этом основан, во-вторых - очень удобно генерировать функцию на лету и возвращать её в качестве результата работы другой функции. "Да и вообще, какой смысл писать программу, которая даже не умеет модифицировать свой код?" [2]
>> А вот тут я бы попросил объяснить, что имеется в виду.
> Различные системы, предоставляющие пользователю специализированный язык для решения
> его задач: Маткады всякие, статистические пакеты типа R или Incanter, шеллы,
> приложения с поддержкой макрокоманд, мало ли что еще. JIT в них
> не всегда оправдан, но бывают случаи, когда объем вычислений значителен и
> JIT окупается.
Ну, это всё же частные случаи второго пункта, про модификацию программы во время выполнения.
[1] https://ru.wikipedia.org/wiki/REPL
[2] http://jim.pp.ru/chtivo/prosa/porgrammerstory.htm

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

46. "Пример использования средств JIT-компиляции, появившихся в G..." –1 +/–

Сообщение от Tav (ok), 10-Апр-15, 18:13

> Суть в том, что от проектов LLVM и JVM то и дело слышны возгласы...
Ну это не технические отличия, а вопрос позиционирования.
И на самом деле, производительность можно улучшить за счет JIT. Например, JIT позволяет вызывать напрямую или даже встраивать полиморфные вызовы, если во время выполнения оказывается, что используется только одна реализация (может зависеть от входных данных — оптимизировать статически не получится). А встраивание делает возможными дальнейшие оптимизации. Если что-то меняется, что может нарушить сделанные допущения, оптимизация отменяется. Обзор оптимизаций, которые выполняет HotSpot: https://wikis.oracle.com/display/HotSpotInternals/Performanc...
Но возможность динамически менять код — более важное применение, с этим согласен.
> Ну, это всё же частные случаи второго пункта, про модификацию программы во время выполнения.
Можно считать и так. Выделил отдельно, чтобы обратить внимание на то, что технология может быть непосредственно полезна не только разработчикам, но и конечным пользователям.

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

47. "Пример использования средств JIT-компиляции, появившихся в G..." +/–

Сообщение от freehck (ok), 22-Июн-15, 15:26

>> Суть в том, что от проектов LLVM и JVM то и дело слышны возгласы...
> Ну это не технические отличия, а вопрос позиционирования.
> И на самом деле, производительность можно улучшить за счет JIT. Например, JIT
> позволяет вызывать напрямую или даже встраивать полиморфные вызовы, если во время
> выполнения оказывается, что используется только одна реализация (может зависеть от входных
> данных — оптимизировать статически не получится).
Да, это может дать прирост производительности. Однако я не очень представляю, как оптимизации, основанные на входных данных могут быть произведены автоматически. Это наверняка потребует строго выдержанного стиля кода, отступление от которого приведёт к невозможности подобных оптимизаций.
Если бы Вас не затруднило предоставить примеры, где подобный подход действительно применяется и даёт выигрыш - было бы здорово.
К тому же, не стоит забывать, что такой подход подразумевает возрастающие накладные расходы для постоянного анализа входных данных, чтобы отловить случай, когда они перестанут удовлетворять выбранной по умолчанию реализации. Об этом в частности свидетельствует Ваша ссылка[1]. Окупятся ли данные расходы за счёт JIT - тоже нетривиальный вопрос.
Итого мы стоим лицом к лицу со многими неочевидными вопросами и сомнительным выигрышем в производительности. Собственно, для меня это и является причиной считать LLVM и JVM - не правильной вещью.
[1] https://wikis.oracle.com/display/HotSpotInternals/Performanc...
PS: Извиняюсь за столь длительную задержку с ответом -- меня выбила из колеи магистерская диссертация. Если у Вас будет желание, мы могли бы продолжить дискуссию по email.

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

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

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

Партнёры:

Хостинг:

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

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


	23. "Пример использования средств JIT-компиляции, появившихся в G..."	+/–
	Сообщение от freehck (ok), 08-Апр-15, 22:18
	> динамическая оптимизация программы с учетом текущего профиля выполнения (JVM); Ну, это скорее её недостаток. Ей ведь надо балансировать между скоростью запуска и скоростью работы, вот и выкручиваются, как могут. > модификация программы во время выполнения (Лисп, Смолток и др.); Вот. Именно для этого JIT и нужен в первую очередь. Но упаси боже, не в том же виде, в каком предлагают его LLVM и JVM. > предметно-ориентированные языки, являющиеся частью интерфейса пользователя. А вот тут я бы попросил объяснить, что имеется в виду.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	24. "Пример использования средств JIT-компиляции, появившихся в G..."	+/–
	Сообщение от Tav (ok), 08-Апр-15, 23:00
	> Ну, это скорее её недостаток. Ей ведь надо балансировать между скоростью запуска и скоростью работы, вот и выкручиваются, как могут. На серверах, где программа перезапускается редко и работает долго, это не проблема. > Но упаси боже, не в том же виде, в каком предлагают его LLVM и JVM. В чем суть отличий "того же вида" от не того? > А вот тут я бы попросил объяснить, что имеется в виду. Различные системы, предоставляющие пользователю специализированный язык для решения его задач: Маткады всякие, статистические пакеты типа R или Incanter, шеллы, приложения с поддержкой макрокоманд, мало ли что еще. JIT в них не всегда оправдан, но бывают случаи, когда объем вычислений значителен и JIT окупается.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	31. "Пример использования средств JIT-компиляции, появившихся в G..."	+/–
	Сообщение от Анончег (?), 09-Апр-15, 01:33
	> В чем суть отличий "того же вида" от не того? Да, да, поддерживаю, пускай расскажет нам про "Ъ-виды" и "НЕ-Ъ-виды".
	Ответить \| Правка \| Наверх \| Cообщить модератору


	40. "Пример использования средств JIT-компиляции, появившихся в G..."	+/–
	Сообщение от freehck (ok), 09-Апр-15, 07:03
	>> Ну, это скорее её недостаток. Ей ведь надо балансировать между скоростью запуска и скоростью работы, вот и выкручиваются, как могут. > На серверах, где программа перезапускается редко и работает долго, это не проблема. А у программ скомпилированных "до конца", такой проблемы нет. >> Но упаси боже, не в том же виде, в каком предлагают его LLVM и JVM. > В чем суть отличий "того же вида" от не того? Суть в том, что от проектов LLVM и JVM то и дело слышны возгласы, что мол проекты позволяют достигнуть производительности компилируемых языков, и что производительность их за так сильно возросла именно за счёт JIT. Надо понимать, что JIT всё-таки хоть и может привести к повышению производительности, но вообще говоря не для неё создан, ибо "до конца" с компилированные программы по-любому дадут более оптимизированный код. А вот что касается возможности генерации кода на лету - то это действительно очень востребовано. Во-первых любой REPL[1] на этом основан, во-вторых - очень удобно генерировать функцию на лету и возвращать её в качестве результата работы другой функции. "Да и вообще, какой смысл писать программу, которая даже не умеет модифицировать свой код?" [2] >> А вот тут я бы попросил объяснить, что имеется в виду. > Различные системы, предоставляющие пользователю специализированный язык для решения > его задач: Маткады всякие, статистические пакеты типа R или Incanter, шеллы, > приложения с поддержкой макрокоманд, мало ли что еще. JIT в них > не всегда оправдан, но бывают случаи, когда объем вычислений значителен и > JIT окупается. Ну, это всё же частные случаи второго пункта, про модификацию программы во время выполнения. [1] https://ru.wikipedia.org/wiki/REPL [2] http://jim.pp.ru/chtivo/prosa/porgrammerstory.htm
	Ответить \| Правка \| К родителю #24 \| Наверх \| Cообщить модератору


	46. "Пример использования средств JIT-компиляции, появившихся в G..."	–1 +/–
	Сообщение от Tav (ok), 10-Апр-15, 18:13
	> Суть в том, что от проектов LLVM и JVM то и дело слышны возгласы... Ну это не технические отличия, а вопрос позиционирования. И на самом деле, производительность можно улучшить за счет JIT. Например, JIT позволяет вызывать напрямую или даже встраивать полиморфные вызовы, если во время выполнения оказывается, что используется только одна реализация (может зависеть от входных данных — оптимизировать статически не получится). А встраивание делает возможными дальнейшие оптимизации. Если что-то меняется, что может нарушить сделанные допущения, оптимизация отменяется. Обзор оптимизаций, которые выполняет HotSpot: https://wikis.oracle.com/display/HotSpotInternals/Performanc... Но возможность динамически менять код — более важное применение, с этим согласен. > Ну, это всё же частные случаи второго пункта, про модификацию программы во время выполнения. Можно считать и так. Выделил отдельно, чтобы обратить внимание на то, что технология может быть непосредственно полезна не только разработчикам, но и конечным пользователям.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	47. "Пример использования средств JIT-компиляции, появившихся в G..."	+/–
	Сообщение от freehck (ok), 22-Июн-15, 15:26
	>> Суть в том, что от проектов LLVM и JVM то и дело слышны возгласы... > Ну это не технические отличия, а вопрос позиционирования. > И на самом деле, производительность можно улучшить за счет JIT. Например, JIT > позволяет вызывать напрямую или даже встраивать полиморфные вызовы, если во время > выполнения оказывается, что используется только одна реализация (может зависеть от входных > данных — оптимизировать статически не получится). Да, это может дать прирост производительности. Однако я не очень представляю, как оптимизации, основанные на входных данных могут быть произведены автоматически. Это наверняка потребует строго выдержанного стиля кода, отступление от которого приведёт к невозможности подобных оптимизаций. Если бы Вас не затруднило предоставить примеры, где подобный подход действительно применяется и даёт выигрыш - было бы здорово. К тому же, не стоит забывать, что такой подход подразумевает возрастающие накладные расходы для постоянного анализа входных данных, чтобы отловить случай, когда они перестанут удовлетворять выбранной по умолчанию реализации. Об этом в частности свидетельствует Ваша ссылка[1]. Окупятся ли данные расходы за счёт JIT - тоже нетривиальный вопрос. Итого мы стоим лицом к лицу со многими неочевидными вопросами и сомнительным выигрышем в производительности. Собственно, для меня это и является причиной считать LLVM и JVM - не правильной вещью. [1] https://wikis.oracle.com/display/HotSpotInternals/Performanc... PS: Извиняюсь за столь длительную задержку с ответом -- меня выбила из колеи магистерская диссертация. Если у Вас будет желание, мы могли бы продолжить дискуссию по email.
	Ответить \| Правка \| Наверх \| Cообщить модератору