Написал dll, в которой одна функция: сложение двух чисел. Вот она внутри проекта C++ (пример взят с сайта quik2dde.ru)
Код
static int forLua_AddTwoNumbers(lua_State *L) {
// получаем первый и второй параметры вызова функции из стека с проверкой каждого на число
double d1 = luaL_checknumber(L, 1);
double d2 = luaL_checknumber(L, 2);
// помещаем в стек результат сложения
lua_pushnumber(L, d1 + d2);
return(1); // эта функция возвращает одно значение
}
Теперь тестирую эту функцию в Луа. Сравниваю скорость: 1) как быстро складывает dll 2) как быстро складывает Lua
Код
package.cpath = "C:\\runfast.dll"
require("runfast")
iterations=10000000
function main()
start=os.clock()
for i=1,iterations do
r = runfast.AddTwoNumbers(i, i)
end
finish=os.clock()-start
message ("C dll:"..tostring(finish), 1)
start=os.clock()
for i=1,iterations do
r = i+i
end
finish=os.clock()-start
message ("Lua:"..tostring(finish), 1)
end
результат:
Луа быстрее в 3,6 раза. Почему? Из-за всех этих телодвижений со стеком? Но как тогда извлекать преимущество от скорости Си++? Мне надо переместить в dll из Луа кучу трудоёмких функций, чтобы быстро считалось.
Написал функцию так, чтобы цикл крутился внутри dll:
Код
static int forLua_AddCircle(lua_State *L) {
double d1 = luaL_checknumber(L, 1); //с чего начинать цикл
double d2 = luaL_checknumber(L, 2); //количество итераций
double r;
double i;
for (i = d1; i <= d2; i++)
{
r = i + i;
}
return(1);
}
Код
package.cpath = "C:\\runfast.dll"
require("runfast")
iterations=100000000
function main()
start=os.clock()
for i=1,iterations do
r = runfast.AddTwoNumbers(i, i)
end
finish=os.clock()-start
message ("C dll:"..tostring(finish), 1)
start=os.clock()
for i=1,iterations do
r = i+i
end
finish=os.clock()-start
message ("Lua:"..tostring(finish), 1)
start=os.clock()
r = runfast.AddCircle(1,iterations)
finish=os.clock()-start
message ("C dll circle:"..tostring(finish), 1)
end
Enfernuz, то есть мне для достижения максимальной скорости нужно в dll запихать всё, что сейчас находится в Луа-скрипте. Это позволит обратиться к dll единожды при вызове библиотеки. Вся логика робота будет в dll. А если переносить в dll только часть функций, то Луа по скорости победит C++, потому что долгое взаимодействие Луа с dll...
Я думаю, Вам об этом стоит задуматься лишь тогда, когда (если) Вы упрётесь в какой-нибудь боттлнек при реализации своих алгоритмов на Lua в QUIK. Ну, или если просто владеете другим языком лучше , чем Lua :)
Enfernuz, уже уткнулся. Всё это происходит, потому что мои колбеки OnQuote захлёбываются. Я принимаю 55 инструментов, и скрипт на луа не справляется. В каждом колбеке есть логика и математика, которую нельзя переместить в main. поэтому нужна скорость
Нет ничего такого, чего нельзя перенести в main поток. Значит вы логику нарушили никаких тяжелых вычислений в колбеках. Просто аксиомой это установите и ведите разработку с этим учетом.
Аксиомы: Тяжелые вычисления в коллбэке = смерть квика
Для себя ничего особо полезного не увидел, очередное пособие как делать обертки, таких в инете на любой вкус. К ускорению взаимодействия с луа-движком этот путь не ведет.
Для себя ничего особо полезного не увидел, очередное пособие как делать обертки, таких в инете на любой вкус. К ускорению взаимодействия с луа-движком этот путь не ведет.
позвольте Вам напомнить, что суть форума - обмен информацией. полезность и результативность сего процесса исключительно персонифицированы.
новичок написал: позвольте Вам напомнить, что суть форума - обмен информацией. полезность и результативность сего процесса исключительно персонифицированы.
Никак не возражаю, наоборот вполне согласен. И позвольте в ответ отметить что я вполне конструктивно подкинул ссылку на русский вариант текста который многим может быть удобнее.
И далее не вижу по каким причинам я не могу высказать свое отношение к материалу. Возможно формулировка резковата, ну что делать, я считаю материал откровенно слабым. Могу это долго и нудно аргументировать. Пример с которого начинается статья по сути требует написания нескольких строк в конфиге любого формата. А не притягивания в проект сценарного движка. И так далее.
Все это исключительно мое личное мнение которое не отражает ничьей официальной позиции )))
Подскажите, пожалуйста, какие накладываются ограничения в QLUA по сравнению с обычным LUA 5.1? Имею в виду - кол-во local переменных, кол-во и размер пользовательских таблиц, кол-во модулей, размер модулей, и т.д.
Поясню, в чём проблема. кусок кода, вызываемого по нажатию кнопки из моей .dll: ... if (code_id == 'process_get_order_list') then -- local test_tbl_ = {} local str_tbl_ = {} str_tbl_['000'] = '111' str_tbl_['111'] = '000' return 'ok',str_tbl_ end
Код стабилен. Если раскомментировать строку 'local test_tbl_ = {}', QUIK рушится с exception'ом, либо сразу после вызова, либо при попытке завершения работы скрипта. Понятно, что сам по себе такой код безвреден и крешиться не может, но программа разрослась, состоит уже из 8 модулей скучей функций и таблиц.
Отсюда и вопрос: каковы ограничения по сравнению с обычным LUA 5.1? Дело ещё в том, что на мной написанном имитаторе (Borland C++ 6.0 с/без Code Guard, LUA 5.1) тот же самый код стабилен.
Лже-Дмитрий написал: Подскажите, пожалуйста, какие накладываются ограничения в QLUA по сравнению с обычным LUA 5.1? Имею в виду - кол-во local переменных, кол-во и размер пользовательских таблиц, кол-во модулей, размер модулей, и т.д.
Поясню, в чём проблема. кусок кода, вызываемого по нажатию кнопки из моей .dll: ... if (code_id == 'process_get_order_list') then -- local test_tbl_ = {} local str_tbl_ = {} str_tbl_['000'] = '111' str_tbl_['111'] = '000' return 'ok',str_tbl_ end
Код стабилен. Если раскомментировать строку 'local test_tbl_ = {}' , QUIK рушится с exception'ом, либо сразу после вызова, либо при попытке завершения работы скрипта. Понятно, что сам по себе такой код безвреден и крешиться не может, но программа разрослась, состоит уже из 8 модулей скучей функций и таблиц.
Отсюда и вопрос: каковы ограничения по сравнению с обычным LUA 5.1? Дело ещё в том, что на мной написанном имитаторе (Borland C++ 6.0 с/без Code Guard, LUA 5.1) тот же самый код стабилен.
Ваш вопрос не корректен. QLUA - это библиотека,в которой функции для доступа к хранилищу данных на терминале и посылке приему сообщений от сервера брокера. для того чтобы функции этой библиотеки могли работать в квик внедрена VM LUA 5.1
Let_it_go написал: Написал функцию так, чтобы цикл крутился внутри dll:
Код
static int forLua_AddCircle(lua_State * L) {
double d1 = luaL_checknumber(L, 1 ); //с чего начинать цикл
double d2 = luaL_checknumber(L, 2 ); //количество итераций
double r;
double i;
for (i = d1; i < = d2; i + + )
{
r = i + i;
}
return ( 1 );
}
Код
package.cpath = "C:\\runfast.dll"
require ( "runfast" )
iterations = 100000000
function main ()
start = os.clock ()
for i = 1 ,iterations do
r = runfast.AddTwoNumbers (i, i)
end
finish = os.clock () - start
message ( "C dll:" .. tostring(finish), 1 )
start = os.clock ()
for i = 1 ,iterations do
r = i + i
end
finish = os.clock () - start
message ( "Lua:" .. tostring(finish), 1 )
start = os.clock ()
r = runfast.AddCircle ( 1 ,iterations)
finish = os.clock () - start
message ( "C dll circle:" .. tostring(finish), 1 )
end
Результат:
dll с циклом всех победила.
разница в том что в lua данные в виде структур если хотите оптимизировать луа скрипты, то следите чтобы типы не смешивались. ------------------- если хотите ускорить вычисления то сделайте столько протоков сколько у вас ядер ,а ядер поставьте по числу инструментов -------------------- если хотите ускорить торговлю на бирже, т е сделать HFT робот, то откажитесь от квика и переходите на прямое подключение к бирже. ----------------------- Вы не там ищите ускорение, так как тормоз в каналах связи, в очередях у сервера брокера и задержках рассылки биржевой информации сервером брокера