Доклад: Опыт работы с LuaJIT в нагруженных интернет-проектах

Опыт работы с LuaJIT в нагруженных интернет-проектах / Александр Гладыш (LogicEditor) from Ontico

Declarative Internal DSLs in Lua: A Game Changing Experience

Declarative Internal DSLs in Lua: A Game Changing Experience

View more presentations from Alexander Gladysh

Lua Alchemy v0.3

Зарелизил Lua Alchemy v0.3: http://bit.ly/mghgfb

Фотографии с MarginCon

Фото inemytchenko

Я рассказываю про Луа, а вовсе не про то, про что вы могли подумать, прочтя надпись на плакате над моей головой.

Ещё фотки здесь: http://www.flickr.com/photos/tags/margincon10/

Доклад по Lua

Прочитал доклад по Lua на MarginCon в Омске.

Вот слайды:

Luabins 0.3

Зарелизил Luabins 0.3

http://github.com/agladysh/luabins

Новые фичи:

• Унификация формата для x86_64 и x86. (ВНИМАНИЕ! Данные старых версий, сохранённые из-под x86_64, перестанут загружаться.)
• API для сохранения данных в FILE * без участия Lua (см. fwrite.h).

Исправлены ошибки:

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

Разное:

• Улучшена информация о модуле. Переменная luabins.VERSION заменена на более стандартные luabins._VERSION, luabins._DESCRIPTION и luabins._COPYRIGHT.
• Добавлены некоторые утилиты командной строки, полезные при разработке (см. etc/).
• Слегка почищен код.

Luabins 0.2

Зарелизил luabins 0.2

http://github.com/agladysh/luabins

• Производительность luabins.save() удвоена.
• Добавлено API для сохранения данных в формате Luabins без Lua.

Формат сохранённых данных не изменился.

Второе превью Lua 5.2

Анонс здесь:

http://article.gmane.org/gmane.comp.lang.lua.general/61783

Скачивать отсюда:

http://www.lua.org/work/

Хабрахабр: Что можно ожидать от Луа 5.2?

Запостил статейку.

http://habrahabr.ru/blogs/development/80429/

Первая превью-версия Lua 5.2

Опубликована первая превью-версия Lua 5.2.

Живёт вот здесь:

http://www.lua.org/work/lua-5.2.0-work1.tar.gz

Анонс здесь:

http://article.gmane.org/gmane.comp.lang.lua.general/61229

LuaJIT 2 x64 Sponsorship Program

Майк Палл запустил программу корпоративного спонсорства LuaJIT 2.

Теперь в наших силах сделать так, чтобы скорее вышла 64-х битная версия!

(Есть возможность принимать спонсорскую помощь и от частных лиц.)

Основы декларативного программирования на Lua

Написал ещё одну статью для Хабра:

http://habrahabr.ru/blogs/development/77413/

Локальные переменные в луашной консоли

Всегда огорчался тем, что в луашной консоли тяжело использовать код с локальными переменными:

$ lua
Lua 5.1.3  Copyright (C) 1994-2008 Lua.org, PUC-Rio
> local v = 5
> print(v)
nil

Переменная ушла из области видимости.

Теперь, наконец-то дошло, что нужно использовать do...end:

> do
>> local v = 5
>> print(v)
>> end
5

Примеры в статьях теперь будут корректнее. :-)

Lua 5.2

Альфа — уже "через несколько месяцев"!

http://article.gmane.org/gmane.comp.lang.lua.general/59805

luamarca

Наконец-то слегка привёл в чувство и выложил луашную бенчмаркилку.

http://github.com/agladysh/luamarca

Надо теперь в бенчмарках порядок навести.

Хабрастатьи

Хабранаписал хабрадве хабрастатьи.

Хабраплюсуйте:

1. Контроль типов аргументов функций в Lua
2. Внешние зависимости в гите: submodule или subtree?

(о_О)

Lua vs. C++ for large programs

Mature C++ programmers often argue against intense Lua usage in the large programs.

They say that C++ is fast, Lua is slow. C++ has excellent tools to provide compile-time validation, while Lua is too dynamic and, therefore, unreliable.

Some time ago there was a related discussion on Lua mailing list. I hear these arguments so often, that I've decided to post a small essay in reply. Now I'm posting a slightly edited version of this essay here.

* * *

Several years before, when I came to Lua, my professional programming experience was almost all C++, without much of dynamic languages experience. Indeed, in C++, with careful design, compile-time validation can give very good correctness guarantees.

At first it was quite hard to write code in Lua — without compile time validation, without static types, it felt as if I try to stand on a blob of wobbly jelly instead of a good solid rock.

However, the price of such validation is quite high. Not to mention longer compile times. You need to spend much time on the design itself. Sometimes much more time than you'd spend solving the problem that you write code for. You need highly skilled and disciplined architector paying constant attention to the each part of the project all the time. You need highly-qualified programmers.

If you have a hammer, try to avoid looking on everything as a nail.

I quite understand if that amount of effort is spent on the low-level "foundation" code in the system (application, library etc.). It is usually written once, must be of high quality and work fast. But to waste it on the business logic, that mutate every day to the whim of the high command?

You want to be able to write cheap business logic code. Okay, it should be reliable enough and fast enough. But it is usually comes in huge quantities, and you should be able to change it quick. You should not need extra skilled programmers to write it — or your budget will bust.

Lua is perfect here — it is reliable, quite fast and easy to grasp.

Compile-time guarantees are not possible to achieve with pure Lua. As we know, Lua compiler is dumb (and this is a good thing — since it is also fast and simple).

I do hope that, in time, we would get Metalua-based static code validation tool, powerful enough to do something like that. But there is no such tool now.

However, there is a simple solution. Write tests.

Any static analysis tool may only catch such generic errors, that it has heuristics for. Even C++ compile-time validation will catch only so much of wrong logic — and the more it may catch, the greater the price you have to pay for the code.

To give a sense of scale: My last project had 160+ KLOC of Lua code. 80 KLOC of it were tests for our Lua and C++ code (we had 90+ KLOC of C++ in total). Most of our tests were declarative and consist of table-structured input / expected output data, they were significantly sparser than the usual code, so the price per LOC is lower.

Tests catch more (you may tune them exactly to the behaviour you expect), they cost less (you may employ less sophisticated programmers), they help refactoring at least as much as the static compile checks.

If we compare Lua with "test-time" validation and C++ with its compile-time checks, to me Lua is the winner (for the business logic at least).

* * *

Do not be afraid to use Lua in large-scale applications! It is at least as easy to write reliable code in Lua as in C++.

Of course, you have to write tests, but you should write them anyway. Lua is powerful enough and is fast enough (especially with LuaJIT 2) to make you happy. Yet it is simple enough so you don't have to force guru-level programmers to write tons of mind-numbing business-logic code.

genmakefile

Когда я писал luabins, я довольно долго возился с системой сборки проекта.

По умолчанию luabins собирается как C89. Однако, со сборкой в тестовом режиме (make test) не всё так просто.

Хорошим тоном считается, когда луашный модуль написан, как и сам Луа, на "clean ANSI C" — подмножестве C89, C98 и C++.

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

С учётом всех требований вся система получается довольно сложной.

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

Писать такой Makefile руками — тяжело. Нужен генератор.

Поскольку luabins — некоммерческий проект, мне было интересно написать такой генератор самому, в качестве развлечения.

Получился genmakefile.

Genmakefile — интересный "игрушечный" прототип мощной системы генерации текста на основе текстовых шаблонов.

Вот пример входных данных: Makefile.luabins.template.

То, что получается на выходе, мы уже видели в luabins: Makefile.luabins.out.

Вот код, который заставляет это всё работать: genmakefile.lua

Что же мы получаем из этих четырёхсот строк кода?

• Шаблонную систему с подстановкой значений по ключам.
• Из шаблона можно контролировать подстановочные словари.
• Можно создавать макросы, переопределяя язык подстановок.
• Можно использовать шаблоны и макросы неограниченной вложенности — шаблоны, генерирующие шаблоны и т.п.
• Несколько вызовов, специфичных для генерации Makefile-ов. :-)

Недостатки — типичные для раннего прототипа:

• Плохо продуманый синтаксис.
• Плохо продуманное API.
• Маловменяемые сообщения об ошибках.

Вывод: Lua rules! :-)

Есть недостатки, но получилось интересно, просто и мощно. Нужно переосмысливать и развивать систему дальше.

Дополнительное чтение:

1. Mixlua (искать Mixlua в тексте по ссылке).
2. Cosmo.

luabins

К вопросу о неанонсированных релизах. :-) Обнаружил, что ещё ничего не писал здесь про luabins.

Luabins — библиотека для бинарной сериализации луашных данных.

Лицензия: MIT.

Текущая версия: 0.1.1 (архив).

С библиотекой можно работать как из Луа, так и напрямую из C/C++.

Основное назначение luabins — сериализация данных для Lua-to-Lua RPC вызовов. При этом библиотека отлично подходит и для хранения простых данных.

Luabins поддерживает примитивные типы: nil, boolean, number и string. Поддерживаются нерекурсивные таблицы разумной вложенности (250 уровней по умолчанию, настраиваемо).

Luabins намеренно не поддерживает рекурсивные таблицы, функции, корутины и userdata. (Если нужна сериализация этих типов — вам к Pluto.)

Наивный пример работы на Lua:

Работа через luabins существенно быстрее чем сохранение и загрузка данных через луашный код в духе tstr и tserialize.

Размер сохранённых данных обычно больше, чем при сохранении в луашный код. (В основном из-за представления целых чисел в виде double; это та же проблема, что и при компиляции луашных исходников в байт-код.) В следующих версиях запланированы оптимизации на эту тему.

Luabins намеренно не сохраняет и не проверяет никакую мета-информацию о данных (включая версию формата!). Если нужно, эту информацию нужно подклеивать к данным руками.

Luabins пытается защищаться от враждебных (или просто неверных) данных при загрузке. Делаются проверки на переполнение и на переаллокацию.

На данный момент Luabins используется в нескольких коммерческих проектах.

Дополнительное чтение:

1. Анонс Luabins 0.1
2. README
3. Исходный код Luabins. ;-)

lua-phpserialize

Некоторое время назад я выложил v0.0.1 библиотеки lua-phpserialize.

Только теперь дошли руки написать об этом в блог. :-)

Части запланированных фичей нет (patches are welcome), но уже текущую версию библиотеки можно (и нужно) использовать для сохранения луашных данных в формат, понимаемый PHP-шным unserialize().

Очень удобно использовать для передачи данных из Lua в PHP.

Ограничения:

Как обычно, рекурсивные таблицы, функции и userdata не поддерживаются. Также, форматом PHP-шных массивов налагаются определённые ограничения на ключи.

Подробнее — здесь.