?

Log in

No account? Create an account

Кухня шута

Шуты не бывают веселыми... А еще они не бывают чьими-то.

Previous Entry Share Next Entry
(no subject)
man_of_motley
История (к сожалению, больше профессиональная) к тому что большие корпорации не так уж мега-разумны как кажется некоторым и эффективность их работы не так уж высока. На примере Google с их V8 и вообще на тему интеграции скриптовых языков.



Для начала немножко вводной:

Так уж получилось что одно из наших флагманских приложений требует дать пользователю возможность самому реализовать некоторую логику, а потом интенсивно её использовать (интенсивно - это например вызывать её от 3 до 10 миллионов раз в течении очень ограниченного времени. Задача, обычно типичная для игр, но встречается и в бизнесе.

Посему, скажем так, некоторый опыт у нас в этом есть. :-)

Для начала глянем что есть задача скрипта? Это обычно относительно небольшой кусочек пользовательской логики с интенсивным использованием нижележащей логики писанной на C++ и часто вызываемый из того же C++.

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

При этом писать эту логику будет обычный пользователь, которого, к сожалению, надо предполагать дураком. И значит нативное приложение от этого дурака должно быть защищено.

Итого - скорость самой виртуальной машины, скорость переключений, возможность реализовать защиту от дурака.

Сравнение Lua/LuaJIT/Jscript Google v.8: по этим характеристиками.

1) Lua и Google v8 обладают лучшей производительностью в сумме этих характеристик на данный момент. Даже подключение C#/Vb.net в сумме проигрывает из-за тяжеловесного переключения между managed и native контекстами.

2) По исполнению чистой логики Lua и v8 идут примерно нос-в-нос по обработке чисел, v8 немного сливает по обработке строк, но зато поддерживает unicode.

3) Интеграция чистого Lua и v8 во многом схожа, правда в v8 решили использовать стек нативного приложения вместо стека виртуальной машины. По идее должно бы ускорить - но... гений большой корпорации требует создания трех(!!!) разных контекстов на каждый кадр стека - и в результате переключение между виртуальной машиной v8 и нативным кодом чувствительно медленнее чем у Lua, и в итоге типовой скрипт состоящий 50/50 из логики и вызовов нативного кода - проигрывает в v8 примерно 3 раза против Lua машины.

4) В v8 куда внятнее сделана обработка исключений, это плюс.

5) Но в v8 очень "по-научному" сделана куча - поэтому в отличии от Lua, где есть один-единственный способ освобождения связанного нативного объекта - по удалению скриптового объекта, которое случается в точно известный момент времени - когда на него нет больше ссылок, в v8 получается нужно 3 (!!!) способа освобождения - dispose вызываемый пользователем, хук на кучу и отдельная проверка всё ли освобождено по удалению скрипта (ибо dispose пользователем может быть и не вызыван, а хук кучи можно так статься тоже никогда никто не вызовет). Наверное в этом есть какая-то своя правда, но для языка который позиционируется как язык расширения нативного приложения - недопустимо. Просто недопустимо. Ибо, см. выше - автор скрипта по определению дурак и от него надо защищаться.

6) LuaJIT, конечно, красавчик. Если переключить взаимодействие VM на прямые вызовы C-функций через FFI - скорость практически сравнивается со скоростью чистого C-кода. К сожалению, за счет потери дурако-устойчивости, ибо автору скрипта открывается весь спектр возможностей отстрелить себе ногу, включая доступ к указателями...

Т.е., в общем и в целом, если нет необходимости поддержать именно JScript, Lua быстрее и проще в интеграции, и не проигрывает по "красивости" функциональности за исключением, пожалуй, только что несколько кривоватой реализации перехвата ошибок через pcall вместо простого и красивого try-catch.

А теперь сравним какой ценой крутая корпорация добилась продукта, который чуть-чуть недотягивает по возможностям до разработки на колене, сделанной в заштатном университете в Южной Америке (тот еще центр науки, ага).

Объем исходного кода:

Lua - 0.3Mb
Google v8 - 19Mb

В 63 раза больше, sic! В 63 раза больше кода чтобы добиться того, и даже чуть худшего результата...

Возможность сборки:

Lua - любой человек имеющий любой C компилятор
Google v8 - полчаса танца с бубнами, на очень ограниченного наборе компиляторов которые можно использовать.

Отчеты BoundsChecker (программка такая специальная про поверки качества кода по работе с памятью):

Lua - чист как слеза младенца
Google V8 - более 500 репортов о некорректной работе с памятью (sic!).

Наличие документации:

Lua - описаны как каждая функция в деталях и с примерами, так и то, что происходит внутри. В деталях, достаточных чтобы любой, кто прошел хороший курс системного программирования понял че к чему.

Google V8 - скудная документация собранная из комментариев к исходного коду, причем собранная посторонними, сам Google поленился оторвать жопу и запустить какой-нибудь doxygen.
Три кривых примера (один падает, два текут по памяти не только внутри v8, но и в самих примерах размером два экрана).
Пара статей, наверное полезных для тех, кто вообще не в курсе, о чем речь, и то вряд ли.

И ведь это корпорация, типа одна из самых успешных в мире, и работающая не за бабло по контракту, а на собственные деньги. Такие дела.

Оправдывает v8 только то, что по сравнению со всем остальным - это единственные скриптовый язык которые проигрывает Lua в разы, а не на порядки. У остальных всё еще хуже...

  • 1
эффективность их падает корпораций, имхо, из-за HR с непомерным ЧСВ и менеджеров, которые в разработке софта и слабо разбираются.

а чо там с питоном?

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

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

а чо там с питоном?
Медленный он для real-time. По крайней мере все реализации которые я пробовал.

у луа мне показалось странным подход - "все через таблицы".
:-) Типичный для скриптовых языков. У Jscript тоже всё объект, а у VBScript/VBA - IDispatch.

и биндинги в свое время хоть и получились, но выглядели как то кривовато и обещали проблемы с поддержкой.
Не более чем поддержать тот же IDispatch, на самом деле.

для 2014 года как то не кошерно.
Зависит от задачи и от реализации контекста, на самом деле. У VBA тоже, но как-то хватало, и не мешалось.

поддержать тот же IDispatch
согласен, но вот его у меня в поем приложении и не было. чистые плюсы, без COM.

Зависит от задачи и от реализации контекста
имелось в виду для встраиваемого языка. можно конечно туда и такой general purpose как питон запихнуть, если юзеры его любят. но написанный именно для этой цели луа его легко зарулит.

  • 1