Легковесный embeddable scripting engine с JIT.

Забыл очень важное требование - свободная/открытая (GPL/BSD) лицензия.

lua? (весь пост не осилил)

> lua? (весь пост не осилил)

...а стоило бы. Совсем обленились!

Ванильный lua не содержит JIT. Есть сторонние LuaJIT и LLVM-Lua, если удастся их завести и они окажутся стабильными, то это будет просто идеально.

Кто-нибудь сталкивался?

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

На ЯваСкрипте? Блестящая идея.

Встроить в приложение компилятор Си получится дешевле. Или написать свой миникомпилятор на каком0нибудь GNU Lightning.

>Совсем обленились!
это да...

>Ванильный lua не содержит JIT. Есть сторонние LuaJIT и LLVM-Lua...
Да, я juajit и имел в виду. Хотя сам не пробовал, но отзывы слышал положительные

TCL.

>На ЯваСкрипте? Блестящая идея.

Ну, не ерничайте. На самом деле, будет не много и не мало. Ну, пускай сотня таких eval'ов в секунду. Хорошенько раскочегарившийся Firefox с жабоскриптом где только можно (XUL и web) наверняка вычисляет поболе того.

> Встроить в приложение компилятор Си получится дешевле.

NO WAI... не получится

> Или написать свой миникомпилятор на каком0нибудь GNU Lightning.

Вот это уже интереснее. Валяйте дальше (если не лень), хочу послушать.

Forth

> TCL.

Ещё скажи LISP. Еды не будет, изыди, троллиё.

С другой стороны, почему б не подкормить.

1) тяжеловесный рантайм;
2) нету JIT;
3) инопланетный синтаксис;
4) нужны костыли для ембеддинга в С.

Следующий.

>> Встроить в приложение компилятор Си получится дешевле.

>NO WAI... не получится

Мелкий Си-компилятор типа tcc - в разы меньше твоих JS-рантаймов.

> Валяйте дальше (если не лень), хочу послушать.

Лень.

> Forth

Ещё один петросян. Не додумался, надо было сразу написать: "LISP, Haskell, Forth, Brainfuck и прочие мемы не предлагать"

webkit jit? Вроде как отлично отточен уже.

>> Forth
> Ещё один петросян.

Оскорбление собеседника больше всего говорит окружающим о тебе самом. Не в положительном смысле.

>1) легковесный (монстры типа Java или Mono не покатят);

Минимальные нативные варианты занимают от единиц килобайт.

>2) встраиваемый (линкуемый с программой на С);

Элементарно.

>3) скриптовой (синтаксис, близкий к математическому, приветствуется);

Синтаксис будет такой, какой захочешь. Форт - метаязык. Хочешь будет программу на Бейсике в машкод компилировать.

>4) JIT обязателен.

Возможна прямая генерация машинного кода.

...

Вообще, если не хочется заморачиваться самопальным генератором машкода, можно сразу взять SP-Forth/Linux и уже к нему долепить то, что нужно. Правда, это уже аж несколько сот килобайт размером.

1. Бред
2. Nowadays the Tcl performs JIT compilation transparently, so Tcl does not suffer from the performance penalty associated with traditional interpreters.
3. Проще, чем может показаться
4. http://wiki.tcl.tk/2074

гугловский V8, как самый быстрый из всех ныне живущих

> Мелкий Си-компилятор типа tcc - в разы меньше твоих JS-рантаймов.

А glibc-devel с собой таскать не придётся? Некошерно как-то.

> Лень.

А, чёрт с вами. Скажите только, правильно ли я понял, что GNU Lightning - это такой кастрированный SPARC'оподобный виртуальный проц, которому можно скормить его мнемоники, а Lightning оттранслирует их в ассемблер реального проца? Сдаётся мне, там надо буде тянуть ещё и GAS за собой. И совершенно не понятно, как подсунуть в предполагаемый EL свои сишные функции. Не говоря уж про то, что надо пейсать компилятор из EL в Lightning-код.

С жабоскриптом-то оно всё ж проще как-то.

Поддерживаю Forth.

ЗЫ видимо, топикстартер ничего кроме плюсов и JS не осилил, вот и пугается :)

> webkit jit? Вроде как отлично отточен уже.

Вы не про это часом?

"The project evolved into SquirrelFish Extreme (abbreviated SFX, marketed as Nitro), announced on September 18, 2008, which compiles JavaScript into native machine code, eliminating the need for a bytecode interpreter and thus speeding up Javascript execution." (с Педивикии)

Если про это - дык оно x86-only (с хаками под x86/64) и плюсятина. Ещё и проприетарное, похоже.

Кстати, если не гнаться за инфиксным синтаксисом, то SP-Forth всё нужное умеет «из коробки». Инфиксная математика для него, вроде, есть, но я не пользовался и не знаю, в каком она состоянии сегодня и работает ли под Linux.

> Оскорбление собеседника...

Ну, прости, борода, погорячился я. Тут же чёртова прорва любителей предложить всякие брейнфаки. Не со зла я, а Forth, видимо, недооценил.

Я так понял, там подход, близкий тому же GNU Lightning? Только "виртуальный проц" уровнем чуть выше (стековая машина), а предполагаемый EL надо транслировать в Forth-код самостоятельно?

Мне интереснее всего, как тут будет обстоять дело с подсовыванием в EL сишных функций типа log() или sin().

> ЗЫ видимо, топикстартер ничего кроме плюсов и JS не осилил, вот и пугается :)

Не надо грязи, просто мои нервы расшатаны троллотой :) Осилю то, что наилучшим образом подойдёт для решения задачи.

Я там подкинул вопрос про вызов сишных функций из EL (это тоже потребуется). Приглашаю к обсуждению, буду благодарен за мысли.

>Я так понял, там подход

Форты бывают разные. Давай для определённости говорить про SP-Forth.

>близкий тому же GNU Lightning? Только "виртуальный проц" уровнем чуть выше (стековая машина)

SP-Forth генерирует прямо машинный x86-код (только 32-х битный, увы). Умеет делать это в рантайме. Ядро весит (скачал, посмотрел) 64кБ.

Правда, под Linux ядро поставляется без SPF-оптимизатора, с которым результат под Windows на вычислительных задачах иногда уделывал MS VC :) Будет ли виндовый оптимизатор работать под Linux - не знаю, надо щупать. А я с SP-Forth не возился уже лет 8.

...

Сейчас проверил - увы. Фибоначчи без оптимизатора он считает отвратительно, вдвое хуже, чем gcc -O0 и в 10 раз хуже, чем gcc -O3

Так что нужно или оптимизатор ковырять, или под Windows гонять :)

>а предполагаемый EL надо транслировать в Forth-код самостоятельно?

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

...

Пойду, погуглю на счёт оптимизатора для SP-Forth...

> гугловский V8, как самый быстрый из всех ныне живущих

Да вот, вроде как дрессировщики обезьян его обскакали: http://andreasgal.com/2008/09/03/tracemonkey-vs-v8/

>Мне интереснее всего, как тут будет обстоять дело с подсовыванием в EL сишных функций типа log() или sin().

Э... Вот если плавучка нужна, тут уже плохо. У SP-Forth только работа с сопроцессором есть. Оптимизатор с ней не работает. Боюсь, плохо всё будет.

М.б. попробовать тогда какой-нибудь мелкий классический компилятор и компилировать выражения прямо системным вызовом?

Спасибо за науку, коллега. Кстати, ещё вроде как есть GNU Forth, он как вообще?

> М.б. попробовать тогда какой-нибудь мелкий классический компилятор и компилировать выражения прямо системным вызовом?

Имеется в виду tcc, упомянутый tailgunner'ом? Надо и этот вариант рассмотреть, но, сдаётся мне, слишком много потрохов придётся с собой тащить. А ещё учитывая то, что проект кроссплатформенный... "ну, вы понели" (С)

И да, выражения могут сильно меняться прямо в рантайме. Вот уж не хочется на каждый чих дёргать тецеце.

В общем, поэтому пока склоняюсь к JIT'ованным JavaScript'ам и LuaJIT.

>Кстати, ещё вроде как есть GNU Forth, он как вообще?

Проверил сейчас - на целочисленке в полтора раза медленнее неоптимизированого SP-Forth. И, соответственно, раз в 10-20 медленнее потенциально оптимизированного.

Зато богатые и отлаженные библиотеки под Linux. Плавучка там есть :)

>Имеется в виду tcc, упомянутый tailgunner'ом?

Да, как вариант.

>сдаётся мне, слишком много потрохов придётся с собой тащить

Сейчас глянул - в установленном виде под Gentoo занимает 405кБ. Из них сколько-то доков и примеров. Сам бинарник весит 124кБ.

...

Сейчас на Фибоначчи гляну...

Ничего так, в 5 раз быстрее неоптимизированного SP-Forth, раза в три медленнее, чем gcc -O3.

...

Если точно, то результаты были такие (40-е число Фибоначчи, рекурсивно):

gforth - 13.7сек.
sp-forth - 9.3сек.
gcc -O0 - 3.5сек
tcc - 2.0сек
gcc -O3 - 0.7сек

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

Ну, думаю, самый быстрый транслятор в рантайме, как раз, в Форте. Ибо самый примитивный и внешний компилер вызывать не придётся :)

>В общем, поэтому пока склоняюсь к JIT'ованным JavaScript'ам и LuaJIT.

Ну, всё зависит от их скоростей. В портеже их нет, так что по-быстрому не проверю.

...

Ага, по сравнению с gforth Lua хорошо смотрится: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gforth&...

можно попробовать yorick. пункты 1, 2, 3 выполняются - к тому же изначально заточен именно под расчёты (имитационное моделирование, классические примеры на homepage у него из уравнений матфизики). насчёт JIT не знаю как оно там нынче, давно с ним не работал

http://yorick.sourceforge.net/

http://www.maumae.net/yorick/doc/index.php

здесь более актуальная информация, старый сайт похоже не обновляется

http://www.maumae.net/yorick/doc/performance.php

это касательно производительности. ну и примеры тут есть

> здесь более актуальная информация, старый сайт похоже не обновляется

По-моему, ни один не обновляется. Проект мертв, походу.

LLVM?

> LLVM?

Плюсятина. Не пойдёт.

>По-моему, ни один не обновляется. Проект мертв, походу.

реализация работает и делает своё дело последние лет десять. и делает хорошо. последние новости, которые я отслеживал по yorick - добавление байндинга к GTK+, а это было около года назад. сообщений о сворачивании разработки я не слышал

Ходют тут вокруг, и не отвечают, волке! :) А я ж вопросец подкинул надысь. Про дёрганье сишных функций из EL, если использовать GNU Lightning.

>> LLVM?

> Плюсятина. Не пойдёт.

Ты таки тролль. Жаль.

> последние новости, которые я отслеживал по yorick - добавление байндинга к GTK+

Форум почти мертвый, в юзерском листе молчание пару лет.

>Форум почти мертвый

а он у них всегда такой был. у языка очень маленькое сообщество

>в юзерском листе молчание пару лет

а на форуме последний пост за 2009 год. и что?

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

>SP-Forth генерирует прямо машинный x86-код (только 32-х битный, увы)

Какие тогда выгоды по сравнению с V8?

>>в юзерском листе молчание пару лет

>а на форуме последний пост за 2009 год. и что?

В анонсах - 1 тема за 4 года, в саппорте - 6 за 8 месяцев.

> да и вообще, хватит троллить-то

Я даже и не начинал.

> качество инструмента нынче определяется активностью его пользователей?

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

> Ты таки тролль. Жаль.

Тьфу на вас! Английским же по белому сказано на Педивикии, что "written in C++". А меня интересует возможность обращений к scripting-рантайму из pure C-программы. Вот что имелось в виду. Нервишки-то у вас, поди, троллием расшатаны почище моего. ;)

Вообще, если посмотреть со стороны: был задан сугубо технический вопрос, не прошло и страницы, а все уже переругались и пообзывали друг друга троллями. ЛОР такой ЛОР. :)

>ЗЫ видимо, топикстартер ничего кроме плюсов и JS не осилил, вот и пугается :)

Хоть осиливай лисп, хаскель и форт, хоть не осиливай - это не важно если вопрос состоит в том осилят ли кастомеры твое внешнее скриптование или нет.

> Английским же по белому сказано на Педивикии, что "written in C++"

Это сказано про V8, да? Или про TraceMonkey тоже?

> А меня интересует возможность обращений к scripting-рантайму из pure C-программы.

Не интересует тебя это - собственно, поэтому ты и тролль. Иначе ты бы хоть из вежливости помянул C bindings для LLVM.

> вопрос состоит в том осилят ли кастомеры твое внешнее скриптование или нет.

Слава те Господи, не состоит. В данном случае предполагаемое "скриптование" - исключительно для девелоперов (ну, и пары десятков повер-юзеров - любителей кастомизации). Так что выбираем то, что наиболее эффективно решает задачу, а больше ничего не еб^Wдовлеет.

>Оно определяется количеством проблем и скоростью их устранения

ну значит нет проблем. это же хорошо!

> Это сказано про V8, да? Или про TraceMonkey тоже?

Про LLVM же это сказано, едрить твою налево!

> Иначе ты бы хоть из вежливости помянул C bindings для LLVM.

Я про LLVM раньше слышал пару раз краем уха. Сегодня впервые сподобился почитать на педивикии про это дело. Ну и откуда мне знать про C bindings? Там вообще на тему ембеддинга всё как-то смутно, я так и не понял, предназначен ли LLVM для этого вообще.

Кстати, хорошо, что про V8 напомнил. Этот гад тоже оказался на C++, и я пока не представляю, как его ембеддить в С-программу, в отличие от TraceMonkey, который.

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

Что-то никто не вспомнил Parrot VM. Если припрёт, то, наверное, можно будет наклепать свой EL на этом попугае. Вроде всё при нём: и не тяжёлый, и C embedding предусмотрен, и JIT наличествует.

оно собирается как-то под arm афаик. Посмотри, мало ли. Лицензия обычная гнутая.

Посмотри на neko