Holywar: AngelScript vs Lua (6 стр)

Дополниетьлно:
Компьютер для теста: AMD Sempron 3000+ S939 (Модель: Веник)/MB ECS RX-480/Память DDR PC3200 - 1.5Гб (Single channel)

Вопросы:
- Как можно побороть переполнения стека в LUA проявившееся в тэсте Аккермана?
  Это слив тэста -1 для LUA, +1 для AngelScript
- Что за произошло с LUA в тэсте фибоначи 3?
Скорость работы глобальных функций Lua приблизительно равна скорости работы функций AngelScript где-то быстрее (фибоначи 2) где-то медленее(остальные тэсты). Вопрос, есть ли у AngelScript разделение между global и local функциями? а то может я тестил только как глобальные?

Замеченый + AngelScript, биндинг внешних функий и переменных из C++ прост как 2 пальца, приэтом сохраняются в таблице непосредственно адреса объектов.
При просмотре работы VM изменение внешней переменной происходит мгновенно, одной коммандой виртуальной машины! без всяких вызовов функции типа tolua/luabind работающих со стеком.
Замеченый - AngelScript, нет поддержки аргументов типа "..."

А давайте сделаем тест более реальным. Добавте туда массу вызовов функций движка. Например path-finding тест с кучей вызовов pLevel->IsCellReachable(ox,oy,tx,ty).
Думаю ЛУА будет отдыхать :)

Матёрое гробокопание детектед. Впрочем, мне луа очень нравится, несмотря на свой, поначалу резавший взгляд, паскаль-стайл. Освоил, прикрутил к своему проекту, погонял, воспылал. Функциональные примочки прикольные, хоть я и не пытался кодить ни на одном функциональном языке. Прозреваю, тесты сделаны для голых понтов, т.к. в реальных условиях мало кого будет волновать разница во времени выполнения на секунды, переполнить стек тоже будет достаточно сложно. В этих синтетических тестах товарищи используют скриптовые языки вместо обычных (как их назвать? программных?). У меня вот есть реализация нейросети на луа, накопал на каком-то psp-форуме. Работает, но ужасно медленно. Это просто пример задачи, которую можно решить на скриптах, но неэффективно. Скрипты должны заниматься исключительно логикой работы хост-приложения, но никак не пытаться заменить его функционал или части этого функционала.

Например, есть модуль для луа, добавляющий поддержку сокетов. Я не думаю, что такой модуль целесообразно использовать, это небезопасно и негибко. Лучше реализовать и сделать все проверки работы в хост-приложении, экспортировав нужные функции в скриптовую систему. В своем проекте я так и сделал, вполне нормально получилось. Грубо говоря, хост должен состоять из множества блоков, выполняющих какие-то конкретные функции, а скрипт это всё увязывает воедино и осуществляет взаимодействие, "дергает за ниточки". Не знаю, правильно это или нет, но я делаю именно так, и все работает пристойно.

Ых, откопали топик.

Сокеты на луа кстати не настолько бесполезная вещь, есть Xavante - отличный http / application сервер на луа, да и вообще весь Kepler Project довольно интересен. Требует мало памяти, работает шустро, доступ к бд есть, получается отличная машинка для браузерных игр :)

Qiller
Я имею в виду классическое применение скриптов. Если уж делать на них игру целиком, то проще тот же PHP взять, там какбэ сокеты встроены, да и это более самодостаточный язык, пусть и со своей конкретной специализацией.

>- Как можно побороть переполнения стека в LUA проявившееся в тэсте Аккермана?
Видемо никак...
>- Что за произошло с LUA в тэсте фибоначи 3?
Ну раз никто незнает, значит произошла какая-то фигня...

>А давайте сделаем тест более реальным. Добавте туда массу вызовов функций движка.
Зделал приинтереснейший тест!

общий код на С++ для тестирования:

int a;
void RunByScript(int a)
{
  a++;
};

a - Переменная доступная из С++ для изменения и т.п.
RunByScript - эта С++ функция будет вызыватся скриптами.

Задача тэста:
Изменять переменную a в цикле, и вызывать функцию на С++

Код на LUA

local function calc()
     a=15
     for a = 1,400000000 do
        RunByScript(a)
     end
     a=a+1
end

print(calc())

для Lua был выполнен биндинг переменной a и функции RunByScript при помощи tolua++-1.0.92

Код на AngelScript

void main()
{
      a=15;
      for (a = 1;a<400000000;++a) 
      {
             RunByScript(a);
      };
      a+=1;
}

Для AS был выполнен биндинг следующим образом:
r = engine->RegisterGlobalProperty("int a", &a);
r = engine->RegisterGlobalFunction("void RunByScript(int)", asFUNCTION(RunByScript),asCALL_CDECL);

далее просто был запущен тест, и проверено значение переменной a!
Результаты:
Тест LUA:
функция global, время выполнения 133 328ms, значение в a=16!
функция local, время выполнения 104 391ms, значение в a=16!
Тест AngelScript:
функция global, время выполнения 84 032ms , значение в a= 400000001

Явный слив за LUA нетолько по времени выполнения, но и по некорректной работе с переменными из С++!
Сомневаюсь что замена tolua на luabind исправит положение... Тем кто юзает luabind предлагаю проверть.
в режиме цикла for у lua создалась новая переменная "a" при работе с которой функции tolua не вызвыались тоесть переменная в цикле неподвергалась ни изменению ни чтению из её значения, и приэтом только на вызове функций луа уже слила, а что былобы если она ещё корректно работала с переменными?
Этого к сожалению неузнать...
Но попытка передавать переменную a в функцию,  изменением цикла
Код 1 на LUA

local function calc()
     a=15
     for i = 1,400000000 do
        RunByScript(a)
     end
     a=a+1
end

Код 2 на LUA

local function calc()
     a=15
     for i = 1,400000000 do
        a=a+1
        RunByScript(a)
     end
     a=a+1
end

Тест LUA:
Код1:функция local, время выполнения 348 547ms, значение в a=16!
Код1:функция global, время выполнения 348 860ms, значение в a=16!
Что уже свидетельствует о том что если бы  for в луа работал бы с честной переменной "a", то время выполнения возрасло бы не в 3, а примерно в 9раз и может теоретически достигать 1 000 000ms.
Запускаем на тестирование код 2!
Код2:функция global, время выполнения 927 609ms, значение в a=400000016!
Результаты оказались теми, что я и ожидал тестировать в локальном функции я нестал ибо и так долго тестилось ;)

Вывод: LUA работает с переменными и функциями из С++, более чем в 11 раз медленнее чем AngelScript....

При тестировании использовался Core 2 E2160/DDR2-800(5-5-5-18)

DDMZ
Гы, можно было не проверять. Это общеизвестный факт. В 76 посте я просто хотел посмеяться над удивлением луащников :)

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

Лично мне все равно какой использовать.

Но вот Crytek остановились на Lua, почему?

А зачем коду на Lua нужна сверхвысокая скорость?

DDMZ
Если б еще и питон протестировал, было бы более полная картина :-)

zlos
Затем чтобы он не был узким местом очевидно.

up

Сделал ещё дополнительные тесты:
1. Скрость вызова функций С++ из скрипта:
Код на AngelScript:

void main()
{
  for (int a = 1;a<400000000;++a)
  {RunByScript(0);};
};

Код на Луе:

for i = 1,400000000 do 
  RunByScript(0) 
end

Далее был запущен тест и измерено время его выполнения...
Результаты:
LUA: 77015ms
AS: 65312ms
В результате лидирует с очень небольшим отрывом AS.

2. Скрость вызова функций скрипта из С++:
Код на AngelScript:

void main()
{
  int a = 1;
}

Код C++ для вызова AngelScript:
(вариант 1)

for (int i=0;i<100 000;i++)
{
    engine->ExecuteString(0,"int a=1;");
}

(вариант 2)

for (int i=0;i<100 000;i++)
{
    engine->ExecuteString(0,"main();");
}

(вариант 3)

int funcId = engine->GetModule(0)->GetFunctionIdByDecl("void main()");              
//Если перенести в тело цикла то на 1 000 000 затратится 15 609ms
for (int i=0;i<10 000 000;i++)
{
      ctx->Prepare(funcId);
      ctx->Execute();
}

Код на LUA:

function tf()
     a=1 
end

Код C++ для вызова LUA:
(вариант 1)

for (int i=0;i<1 000 000;i++)
{
      luaL_dostring(ls.L,"do a=1 end");   //Если do убрать то будет в 2 раза медленее
};

(вариант 2)

DDMZ
Можно выложить exe файлы для тестов?  В целях сравнения с "велосипедом" :)

doc.
>Можно выложить exe файлы для тестов?  В целях сравнения с "велосипедом" :)
Пишешь скрипт-двиг? =)