Куда уж быстрей-то? Есть подозрение, что без JIT-а сильно быстрее уже не получится. А с JIT-ом — см. LuaJIT 2, в среднем всего в 2.37 раза медленнее C++. 5.2, конечно, пока LuaJIT не поддерживает, но ближе к релизу, скорее всего, будет.
Если говорить про стандартную реализацию 5.2, то, говорят, стало где-то чуть медленнее, где-то чуть быстрее. Существенной разницы с 5.1 нет.
В отличие от «некоторых других» динамических языков, в Луа можно параллельно работать одновременно с несколькими стейтами в одном процессе.
Если нужно организовать параллельную работу логики на Луа, обычно создаётся по стейту на поток и организуется механизм обмена данными между стейтами. Например, налаживается система посылки сообщений между потоками или данные просто расшариваются тем или иным способом между стейтами с обеспечением синхронизации доступа кодом движка.
Почему разработчики отдельных игр пренебрегают такой возможностью мне сказать сложно. Может быть считают, что овчинка не стоит выделки, и игровая логика отлично будет работать и на одном ядре…
Хочу уточнить на всякий случай, что проблемы с Юникодом под Windows возникают в основном при работе с юникодной файловой системой через io.* (что всё равно обычно отдаётся на откуп движку — так что не страшно). Сами юникодные строки можно использовать — так же как и на других платформах.
Вот ещё есть паттерн Alternate Hard and Soft Layers, там есть несколько полезных мыслей по поводу использования скриптовых языков вообще. Там, правда довольно сумбурно написано.
Распараллеливание кода в Луа отлично получается и без поддержки системных потоков самим языком. (Понятное дело, что для этого нужны изолированные стейты, но это и хорошо, лучше масштабируется.)
Там дальше в треде народ пошёл ещё раз перечислять проблемы с Юникодом у тех, кто использует Луа под Windows… Можно излить свои печали, иногда это работает.
А по поводу «быстрых и лёгких» дохрена — это спорное заявление. К тому же, фишка Луа в том, что в языке достигнут хороший баланс по всем перечисленным показателям, не только по быстроте и скорости.
Но мне холиваров по поводу языка разводить здесь совсем не хочется. Я никого Луа использовать не заставляю. Те, кто использует — те обычно знают «в чём фишка». ;-)
www.lua.org/work/
Если говорить про стандартную реализацию 5.2, то, говорят, стало где-то чуть медленнее, где-то чуть быстрее. Существенной разницы с 5.1 нет.
Если нужно организовать параллельную работу логики на Луа, обычно создаётся по стейту на поток и организуется механизм обмена данными между стейтами. Например, налаживается система посылки сообщений между потоками или данные просто расшариваются тем или иным способом между стейтами с обеспечением синхронизации доступа кодом движка.
Почему разработчики отдельных игр пренебрегают такой возможностью мне сказать сложно. Может быть считают, что овчинка не стоит выделки, и игровая логика отлично будет работать и на одном ядре…
Вот ещё есть паттерн Alternate Hard and Soft Layers, там есть несколько полезных мыслей по поводу использования скриптовых языков вообще. Там, правда довольно сумбурно написано.
http://article.gmane.org/gmane.comp.lang.lua.general/61528
http://article.gmane.org/gmane.comp.lang.lua.general/61523
Там дальше в треде народ пошёл ещё раз перечислять проблемы с Юникодом у тех, кто использует Луа под Windows… Можно излить свои печали, иногда это работает.
С другой стороны, UTF-8 вполне можно пользоваться (стиснув зубы).
http://penlight.luaforge.net/FAQ/#T9
http://en.wikipedia.org/wiki/Category:Lua-scripted_video_games
http://en.wikipedia.org/wiki/Lua_(programming_language)#Applications
en.wikipedia.org/wiki/Category:Lua-scripted_video_games
Вот неигровые приложения, использующие Луа, про которые знает Википедия:
en.wikipedia.org/wiki/Lua_(programming_language)#Applications
Не знаю, правда, что это доказывает. :-)
Но мне холиваров по поводу языка разводить здесь совсем не хочется. Я никого Луа использовать не заставляю. Те, кто использует — те обычно знают «в чём фишка». ;-)