Взаимодействие OLua и Lua под Виндой

Страницы: 1
RSS
Взаимодействие OLua и Lua под Виндой
 
Возникла необходимость ускорить обработку данных в написанном тестере стратегий поскольку на том железе что я имею мой бот с таблицей необходимгого мне размера плохо справляется - всего 4 прохода в секунду(весь скрипт). По личному опыту знаю что аналогичный скрипт исполняемый не в квике а запущенный  в винде работает в десятки раз быстрее. Подскажите есть какие нибудь  варианты связать два скрипта работающие в квике и в винде кроме как через запись в файл? Вариант с С# пока не подходит поскольку с ним пока не работал.
 
Цитата
lergen написал:
Возникла необходимость ускорить обработку данных в написанном тестере стратегий
А как тестер писали ? он на Луа у Вас ?

По теме, можно на С++ он запускает Луа скрипты спокойно, только нужно будет источники данных делать думаю и скрипты квика переписывать под тестер. По сути программа - тестер. (первое что в голову пришло)
 
Цитата
Андрей написал:
Цитата
lergen   написал:
Возникла необходимость ускорить обработку данных в написанном тестере стратегий
А как тестер писали ? он на Луа у Вас ?

По теме, можно на С++ он запускает Луа скрипты спокойно, только нужно будет источники данных делать думаю и скрипты квика переписывать под тестер. По сути программа - тестер. (первое что в голову пришло)
Писал сам на lua. С "С" вариант мне не подходит пока с ним не работал. Дело не в языке даже а во взаимодействии его с виндой и с lua. Во все это вникнуть это отдельная тема  - пока такой задачи не ставлю - со временем свободным не так хорошо как хотелось бы.
  Хочу пока с lua разобраться какие варианты есть передать параметры из скрипта работающего в квике скрипту который запущен  в винде.
 
Проще всего написать программу думаю которая будет реализовывать все функции Lua - к примеру берет файл с котировкой банально в цикле прогоняет и дергает события Lua (приход нового тика, совершение сделки и прочие...)

Мне кажется, нет я уверен, что хороший все сторонний тестер под Lua не написать (как мин без подключения доп. библиотек на языках типа плюсов и С#) Однако лучше да и правильнее скрипты Lua тестить а не в скриптах тестить) Тот же МТ5 для тестов намного лучше будет (там практически все что нужно есть для оптимизации и прочего...) Но в квике больше возможностей для торговли (опционы к примеру...) Если же использовать MT5 для тестов, то нужно будет переписывать робота на Mql и затем там тестить, оптимизировав уже можно торговать (останется только график нужного Вам инструмента в Мт загрузить там есть такая возможность.).

Вот пара полезных ссылок, возможно Вам пригодятся:
https://habrahabr.ru/post/197300/
https://habrahabr.ru/post/237503/
Все с хабра - сайт и сам по себе популярный так что надеюсь меня не сочтут за рекламщика))
 
Андрей спасибо за помощь. На сколько я помню МТ работает на исторических данных мне это не подходит. Да и не вспомню сейчас насколько он гибок в настройках, уж сам то я сваяю что мне в голову взбредет. На данный момент есть несколько наметок как развязать узелок. Возможно обойдусь оптимизацией алгоритма.
За ссылки спасибо - "С" думаю все равно нужен будет со временем.
 
Вот еще кстати одна ссылка в догонку так сказать, тут очень даже хорошо создатель сайта расписал метод стыковки С++ и квика. Сам сейчас сижу с жтой стыковкой воюю. https://quikluacsharp.ru/qlua-c-cpp-csharp/vyzov-funktsij-qlua-lua-iz-dll-napisannoj-na-c-c/

МТ5 довольно гибок, да и для тестов история как раз и нужна, ну что там у Вас я не знаю, так что это вам решать уж...
 
Скорее всего надо переписать сам скрипт ,изменить алгоритм или переписать его на СИ как dll.
Что же касается исполнения луа программы в КВИКЕ и вне его то исполняются одинаковое время так как в квике ровно таже VM Lua.
Задержка может быть лишь из-за загрузки процессора либо другими приложениями либо работой самого квика в реале.
--------------------
В любом случае Вы не там копаете.  
 
Цитата
Николай Камынин написал:
Что же касается исполнения луа программы в КВИКЕ и вне его то исполняются одинаковое время так как в квике ровно таже VM Lua.
в теории одинаково. На практике нет. В терминале скрипты исполняются медленнее.
 
Цитата
s_mike@rambler.ru написал:
Цитата
Николай  Камынин   написал:
Что же касается исполнения луа программы в КВИКЕ и вне его то исполняются одинаковое время так как в квике ровно таже VM Lua.
в теории одинаково. На практике нет. В терминале скрипты исполняются медленнее.
можете привести конкретные данные? На сколько процентов медленнее?
Полагаю, что медленнее может быть  лишь по причине того, что скрипт в квике не самостоятельная задача.
Других причин не видно.
Вообще-то интересно как Вам удалось функции библиотеки QLUA запустить независимо от квика?
 
Функции qlua здесь не при чем.

достаточно написать цикл и заменить время выполнения из под ос и из под терминала.

я как-то задавался этим вопросом раньше и сейчас еще раз проверил - в терминале медленнее.

вопрос "почему" не по нужному адресу -не я приклеивал луа к квику.
 
Стати, ни разу не получилось увидеть, как скрипт qlua, будучи запущенным из терминала, крутился бы на другом ядре. Возможно, дело в установленных ос или железе.
 
Готов взять обратно свои слова о слабом быстродействии Qlua. Оптимизацией алгоритма добился того что скрипт обрабатывающий таблицу в 6500 строк делает 15 проходов в секунду. Опять же оговорюсь что это для моего железа - для кого то возможно это так себе показатель. Замедление происходит в основном при взаимодействии виртуальной машины с квиком - при опросе графиков, таблиц, выводах в таблицы, сохранении в файл .... Если эти операции ограничить до необходимой целесообразности то все работает довольно шустро.
 
Цитата
s_mike@rambler.ru написал:
Стати, ни разу не получилось увидеть, как скрипт qlua, будучи запущенным из терминала, крутился бы на другом ядре. Возможно, дело в установленных ос или железе.
цикл, запущенный в main(), вполне себе крутится на отдельном ядре. (Есть нюанс куда его приткнет ОС, но в любом случае отдельно)
 
О нюансах.
У меня старенький ПК, 2 ядра, Windows XP. Запускаю 3 скрипта-близнеца, имена только разные. Подобрал параметры цикла, чтоб каждый в одиночку на не очень нагруженном ПК исполнялся около 1 минуты.

function main()
 message("00c-start",2)
 s=0
 for i=0, 580000000 do
   s = s+1
 end
 message("00c-finish",2)
 return
end

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

При параллельном выполнении какому-то ядру достался один скрипт, какому-то - два. Наблюдаю загрузку процессора в Диспетчере задач Windows -  оба ядра по 100%.
Через минуту завершается один скрипт - тоже ожидаемо. Была одна из вспомогательных гипотез, что те скрипты, что попали в одну воронку, завершатся еще через минуту.
По факту они завершились через полминуты. Эти полминуты оба ядра были загружены полностью. При полной загрузке ядер вся работа трех скриптов была выполнена за полторы минуты.

Приятный нюанс - произошло перераспределение нагрузки, освободившееся ядро стало выполнять один из двух отставших скриптов. Два ядра, у каждого свой скрипт, осталось выполнить половину работы каждого, по полминуты.
Итого: 3 минуты/2(ядра) = 1.5 минуты.
Прямо задачка про трубы.

Неприятный нюанс. Все знают что основной поток QUIK, в котором последовательно обрабатываются асинхронные выходы, в частности - индикаторы, нельзя грузить долгой работой, можно многое притормозить и даже заблокировать.
Три (даже два) "тяжелых" скрипта в соседних потоках при двух ядрах тоже справляются с такой задачей - на полторы минуты  практически блокируют работу QUIK. Вероятная причина - приоритеты всех потоков одинаковы.

Разработчикам - оцените, пожалуйста, целесообразность и возможность повышения приоритета основного потока QUIK.
Не думаю, что только у меня ресурсоемкие алгоритмы.
Оптимизировал алгоритмы, "тяжесть" унес в DLL(C++), использовал особенности внутреннего устройства LUA, межпоточную сихронизацию, уйду (ушел) из индикаторов, перейду на многоядерный ПК, но мину за спиной оставлять не хочется, как не хочется и жить на костылях.  


   
 
Уважаемые разработчики!

Подтвердите, пожалуйста, что вы заметили мое упоминание про неприятный нюанс и мое предложение.  
 
Цитата
lergen написал:
Хочу пока с lua разобраться какие варианты есть передать параметры из скрипта работающего в квике скрипту который запущен  в винде.
Наверно это возможно через общие объекты, доступные как в квике, так и в  Луа самой винды, например простой текстовый файл. Он может создаваться и там и там и соответственно читаться тоже. Или через файл HTML, с ним наверно даже проще его не нужно открывать и закрывать как текстовый, на одной стороне он просто дописывается, а на другой стороне он читается, единственная проблема, что если прочитать раньше времени, то данные будут не обновленные, а старые. Это на мой взгляд самая простая передача данных, а по времени она не затратная, скорость записи на диск на современных ПК составляет 133 Мбайт/сек. Можно наверно через MySQl, но мне кажется это все будет работать медленнее, хотя как вариант можно и через какую либо локальную БД.
человек (не робот)
 
Цитата
Андрей написал:
Мне кажется, нет я уверен, что хороший все сторонний тестер под Lua не написать (как мин без подключения доп. библиотек на языках типа плюсов и С#)
А мне кажется ничего и не нужно писать, lua работает с потоками, а это значит что скорость в lua должна быть выше любой сборки совместно с C# или С++. Может конечно я плохо знаю с#, но мне там не попадались стандартные функции работающие в своем потоке (кроме функций ввода-вывода). Поток там реализуется операционной системой виндовс, причем потоки разделяются между потоками задач самой операционной системы и пользовательскими задачами и скорость задержки пользовательских задач в среднем кратна 20 мс. А в lua на сколько я понял, используются dll которые сами создают потоки, и проблема может быть только одна пор идее, это синхронизация этих потоков, но это мои выводы, может кто то может это объяснить более грамотно. А отладчик для qlua декода, очень хороший отладчик, хоть и немного капризный. А для Lua мне очень нравится отладчик zbstudio.exe, на мой взгляд, лучше VS.
человек (не робот)
 
Если я еще совсем не рехнулся :))), то при запуске Lua-скрипта в Quik (QLua) мы создаем отдельный main поток.
Если же мы обращаемся к функциям обратного вызова, то они исполняются в основном потоке Quik. Таким образом любая математика и т.д. в callback - это тормоз всего Quik.(больше никаких потоков вы не создадите в QLua) Это же в руководстве написано, вроде. Но и у main тоже есть предел памяти :))) Создаем "утечку" и Quik слетает.
Оптимально (ИМХО) получаем данные с Quik от функций обратного вызова и в очередь  MMF(буфер), в main же потоке можно реализовать "прием" обратной связи(те же заявки можно кидать вместо trans2QuikAPI) и передачу  CraateDataSource(для теста как раз в оффлайне пойдет с данных в Quik около 5 000 свечек по каждому ТФ, или всех тиков за сутки). А обработку данных на чем угодно реализуйте.
Страницы: 1
Читают тему (гостей: 1)
Наверх