https://opennet.dev/openforum/vsluhforumID3/101971.html Разработчики из компании Red Hat опубликовали интересную заметку (http://developerblog.redhat.com/2015/04/07/jit-compilation-using-gcc-5-2/) с примером использования библиотеки libgccjit (https://gcc.gnu.org/wiki/JIT), которая входит в состав набора компиляторов GCC 5 (https://gcc.gnu.org/gcc-5/changes.html), релиз которого ожидается через несколько недель. В GCC 5 генератор кода может быть собран в виде разделяемой библиотеки, встроен в другие процессы и использован для упреждающей AOT-компиляции (Ahead-of-time) или JIT-компиляции байткода в машинный код. В заметке показано как построить компилятор для гипотетического языка программирования, используя Python-биндинг (https://pypi.python.org/pypi/gccjit) к libgccjit для JIT-компиляции кода в Python-скрипте.<br><br><br>URL: http://developerblog.redhat.com/2015/04/07/jit-compilation-using-gcc-5-2/<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=41999<br> https://opennet.dev/openforum/vsluhforumID3/101971.html#47 Mon, 22 Jun 2015 12:26:08 GMT &gt;&gt; Суть в том, что от проектов LLVM и JVM то и дело слышны возгласы...<br>&gt; Ну это не технические отличия, а вопрос позиционирования.<br>&gt; И на самом деле, производительность можно улучшить за счет JIT. Например, JIT <br>&gt; позволяет вызывать напрямую или даже встраивать полиморфные вызовы, если во время <br>&gt; выполнения оказывается, что используется только одна реализация (может зависеть от входных <br>&gt; данных &#8212; оптимизировать статически не получится).<br><br>Да, это может дать прирост производительности. Однако я не очень представляю, как оптимизации, основанные на входных данных могут быть произведены автоматически. Это наверняка потребует строго выдержанного стиля кода, отступление от которого приведёт к невозможности подобных оптимизаций.<br><br>Если бы Вас не затруднило предоставить примеры, где подобный подход действительно применяется и даёт выигрыш - было бы здорово.<br><br>К тому же, не стоит забывать, что такой подход подразумевает возрастающие накладные расходы для постоянного анализа входных данных, чтобы отловит https://opennet.dev/openforum/vsluhforumID3/101971.html#46 Fri, 10 Apr 2015 15:13:26 GMT &gt; Суть в том, что от проектов LLVM и JVM то и дело слышны возгласы...<br><br>Ну это не технические отличия, а вопрос позиционирования.<br><br>И на самом деле, производительность можно улучшить за счет JIT. Например, JIT позволяет вызывать напрямую или даже встраивать полиморфные вызовы, если во время выполнения оказывается, что используется только одна реализация (может зависеть от входных данных &#8212; оптимизировать статически не получится). А встраивание делает возможными дальнейшие оптимизации. Если что-то меняется, что может нарушить сделанные допущения, оптимизация отменяется. Обзор оптимизаций, которые выполняет HotSpot: https://wikis.oracle.com/display/HotSpotInternals/PerformanceTechniques<br><br>Но возможность динамически менять код &#8212; более важное применение, с этим согласен.<br><br>&gt; Ну, это всё же частные случаи второго пункта, про модификацию программы во время выполнения.<br><br>Можно считать и так. Выделил отдельно, чтобы обратить внимание на то, что технология может быть непосредственно полезна не только раз https://opennet.dev/openforum/vsluhforumID3/101971.html#45 Thu, 09 Apr 2015 14:57:23 GMT &gt;&gt;Проще что?<br>&gt; всё<br><br>хэш&#8208;таблицы, например. куда уж несчастным скриптовикам до няшности и удобства использования хэш&#8208;таблиц в си&#8230;<br> https://opennet.dev/openforum/vsluhforumID3/101971.html#44 Thu, 09 Apr 2015 08:34:39 GMT Вообще-то, libgccjit - это всего лишь backend, т.е. генератор машинного кода. А вот фронтенд для C вам придется написать самим. Эта задачка посложнее всей libgccjit будет. Так что сабж подходит для чего-то простого, что при этом кровь из носу надо скомпилировать налету. Даже не знаю, что это могло бы быть.<br><br>А для "скриптов на C" лучше смотреть в сторону clang.<br> https://opennet.dev/openforum/vsluhforumID3/101971.html#43 Thu, 09 Apr 2015 05:56:58 GMT О чем речь, если оно поддерживает си, то и луа автоматом, кому надо луа пусть его юзает, кому надо си пусть юзает его, программировать плагины, думаю, будет гораздо удобнее.<br>Если оно будет динамически обновлять код по ходу выполнения, так это сказка.<br> https://opennet.dev/openforum/vsluhforumID3/101971.html#42 Thu, 09 Apr 2015 05:45:25 GMT да ну<br> https://opennet.dev/openforum/vsluhforumID3/101971.html#41 Thu, 09 Apr 2015 04:09:00 GMT &gt; Однако это не умаляет достоинства llvm, они дали очень хороший "пинок" для <br>&gt; развития gcc. Конкуренция это всегда хорошо. И может быть они когда <br>&gt; нибудь догонят gcc по возможностям...<br><br>Это вряд ли. Они ведь компилируются только в одну архитектуру, а потом на лету пытаются перекомпилироваться в машинные коды. Трижды ха. Это конечно определённо даёт фору в реализации новых стандартов ЯП, но жутко демпингует их по качеству сгенерированного кода. JIT относительно хорош для многих вещей, но не для оптимизации же.<br><br>Однако конкуренция - таки да, это хорошо.<br> https://opennet.dev/openforum/vsluhforumID3/101971.html#40 Thu, 09 Apr 2015 04:03:36 GMT &gt;&gt; Ну, это скорее её недостаток. Ей ведь надо балансировать между скоростью запуска и скоростью работы, вот и выкручиваются, как могут.<br>&gt; На серверах, где программа перезапускается редко и работает долго, это не проблема. <br><br>А у программ скомпилированных "до конца", такой проблемы нет.<br><br>&gt;&gt; Но упаси боже, не в том же виде, в каком предлагают его LLVM и JVM.<br>&gt; В чем суть отличий "того же вида" от не того?<br><br>Суть в том, что от проектов LLVM и JVM то и дело слышны возгласы, что мол проекты позволяют достигнуть производительности компилируемых языков, и что производительность их за так сильно возросла именно за счёт JIT. Надо понимать, что JIT всё-таки хоть и может привести к повышению производительности, но вообще говоря не для неё создан, ибо "до конца" с компилированные программы по-любому дадут более оптимизированный код.<br><br>А вот что касается возможности генерации кода на лету - то это действительно очень востребовано. Во-первых любой REPL[1] на этом основан, во-вторых - очень удобно генерировать функцию https://opennet.dev/openforum/vsluhforumID3/101971.html#38 Thu, 09 Apr 2015 03:11:17 GMT &gt; На плюсах - тоже можно хотя бы сделать по-человечески<br><br>Нельзя.<br>