TGB, Да мне вообще плевать на потоки, блокировки и прочую лабуду! Я считаю, что работает мой, и только мой скрипт, и знать не знаю никаких потоков. То, что в цикле со sleep я рассматриваю как прерывание по таймеру, то, что по OnTrade - по сделкам, а то, что по SetTableNotificationCallback - как прерывания от клавы или мыши. И нет проблем!(с)
По моим оценкам, вы двое и есть самые продвинутые программеры на этом форуме. Хотите выяснить, у кого длиннее?
nikolz, Лапуль, у меня именно ВСЁ хорошо. Неплохо бы, конечно, иметь тот сервис, про который я написал, но и без него "всё хорошо, всё хорошо".
Пользователь
Сообщений: Регистрация: 21.08.2015
03.08.2021 18:44:01
Цитата
TGB написал: почему вы так упорно боретесь против «форка lua»?
Потому что арка не знает, как устроен луа. И вы не знаете. И я не знаю. У вас есть формальное описание виртуальной машины? Нет. Вы что-то патчите в неизвестно-как-работающем-коде с доказательствами вида "я три дня тестил". Тесты пишутся не для того, чтобы показать, что "у меня работает", а чтобы доказать соответствие написанного кода формальной модели. Модели нет, что тестировать? Если бы вы это предложение выкатили команде луа, еще куда б ни шло, там хоть последствия понимают.
Еще раз, в текущем луа есть удобная особенность атомарности исполнения байткода. Вы это хотите сломать. Я против самой идеи это ломать. Проблема возможного завешивания хоста навсегда кривым кодом - существует. Как ее решить без ковыряния в кишках луа, я предложил. Протестировать очень просто: выставляете в реестре HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\CriticalSectionTimeout на сколько хотите миллисекунд и тестируете существующий квик. В продакшене так делать нельзя, на всякий случай добавлю, это на всю систему влияет.
Знаю. Так как есть исходники Lua. И вы можете узнать, никто не запрещает.
Цитата
Anton написал: Если бы вы это предложение выкатили команде луа, еще куда б ни шло, там хоть последствия понимают.
Команде Lua это не нужно. Как только вы встраиваете Lua в свою систему, за последствия отвечаете вы (почитайте в тексте исходников Lua комментарии; они же в свободном доступе).
Цитата
Anton написал: Еще раз, в текущем луа есть удобная особенность атомарности исполнения байткода. Вы это хотите сломать. Я против самой идеи это ломать.
Конечно, при этом исчезает интересная возможность многочасового гадания в коде скрипта на атомарность/неатомарность , если не следовать рекомендациям разработчика QUIK по взаимодействию с колбеками. Но самое интересное, даже, если вы убежденный противник рекомендаций разработчика Quik и не используете потокобезопасную очередь между вызовом колбеков и main, то, если нет общих данных, модифицируемых в вызовах колбеков и в функциях вызываемых в main, то гаданием атомарность/неатомарность можно, вообще, не заниматься.
Цитата
Anton написал: Как ее решить без ковыряния в кишках луа, я предложил.
Засим завершаем тему. Я свою позицию изложил, прислушиваться или нет - арке решать.
Пользователь
Сообщений: Регистрация: 12.05.2020
06.08.2021 12:40:31
В предыдущих комментариях, при обсуждении конкретного, протестированого в непрерывном недельном прогоне, решения (в виде мизерной правки в 4-х местах исходников QLua), исправляющего, по моему мнению, существующую в QLua ошибку, было написано много текста, в котором можно «сломать голову».
На самом деле все достаточно просто. В QUIK запускается единственный служебный «основной» поток, который об-служивает колбеки всех запущенных скриптов пользователя и его созданных таблиц QUIK. В текущий момент существует, по крайней мере, два варианта, когда скриптер может, «случайно», выполнением кода своего скрипта, заблокировать «основной» поток (при этом перестают запускаться колбеки всех запущенных в QUIK пользователем скриптов и все скрипты «слепнут»: 1) скриптер написал непосредственно в запуске какого-то своего колбека длительно выполняющуюся функцию (почему бы нет?); 2) скриптер сумел написать в main длительно выполняющийся фрагмент байт-кода, в котором нет вызовов C-функций (почему бы нет?). Первый вариант лечится, если следовать рекомендациям разработчика QUIK по обработке колбеков. При этом, все что делается в main пользователя, становится однопоточным (относительно «основного» потока). «Основной» поток, при обработке колбеков, выполняет только короткие записи параметров колбекков в очереди. Причем, в этом случае, при написании и редактировании скрипта, заниматься синхронизацией с «основным» потоком не надо вообще. Второй вариант скриптер сейчас может лечить каждый раз, при редактировании скрипта, анализируя его текст на наличие фрагментов «длинных» байт-кодов и вставляя в них, в «?? нужных» местах какую-нибудь, функционально пустую C-функцию. Нужно ли это скриптеру, если это можно вылечить, внеся, предложенные мною, исправления в QLua? Могу ли быть ошибки, в предложенном мною? В любом коде ошибки могут быть, но это уже как-то протестировано (непрерывно в течении недель) да и разработчик QUIK может это потестировать.
Пользователь
Сообщений: Регистрация: 12.05.2020
09.08.2021 18:24:01
Об атомарности операций. Рассуждения об атомарности операции без определения ее области реализации это рассуждение о погоде без определения, к чему это относится (к Арктике или Антарктиде). Все операции скрипта, по отдельности, команды байт-кода или вызов C-функций являются атомарными, но в тоже время, выполнение скрипта, в целом, может быть и не атомарным (потоконебезопасным). Это связано с тем, что между упомянутыми операциями могут возникнуть переключение потоков, изменяющее контекст выполнение локально-атомарных операций. На самом деле, для выяснения потокобезопасности (атомарности выполнения скрипта в целом) достаточно выявить общие данные, модифицируемые в main и в основном служебном потоке QUIK, генерирующем вызовы колбеков скрипта. Если таких данных нет (а это часто можно обеспечить), то бессмысленно гадать об атомарности отдельных операций скрипта (скрипт выполняется атомарно, то есть, потокобезопасно, если нет таких данных).
Пользователь
Сообщений: Регистрация: 20.03.2015
30.08.2021 07:45:04
я правильно понимаю, что последняя версия на текущий момент 8.13.1, и в ней всё ещё есть ошибки синхронизации по работе с таблицами лимитов
спасибо. жаль конечно. но вижу есть другие интересные исправления всё же. версия 9.1.3 будет обратно совместима с сервером на 8 Quik? у меня Открытие Брокер, не знаю точно какая у них сейчас версия на сервере, программа этой информации не выдает
Надо делать так, как надо. А как не надо - делать не надо.
Пользователь
Сообщений: Регистрация: 20.12.2020
30.08.2021 19:23:57
Цитата
Павел Bosco написал: у меня Открытие Брокер, не знаю точно какая у них сейчас версия на сервере, программа этой информации не выдает
Не знаю какая у них версия сервера, но клиент 9.1.3.11 с Открытие Брокер работает.
Пользователь
Сообщений: Регистрация: 20.12.2020
30.08.2021 19:26:10
Предлагаю разработчикам добавить в Информационное окно, ну и соответственно в функцию getInfoParam возможность получения информации о версии сервера.
Пользователь
Сообщений: Регистрация: 20.03.2015
31.08.2021 09:34:27
Цитата
BlaZed написал: Предлагаю разработчикам добавить в Информационное окно, ну и соответственно в функцию getInfoParam возможность получения информации о версии сервера.
спасибо. и предложение напрашивается, да. но может в протоколе оно не транслируется.
Для работы терминала версии 9.1 и выше, необходимо, чтобы у брокера была версия сервера 9.0.0 и выше.
Зарегистрировали пожелание, постараемся его рассмотреть. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.
Пользователь
Сообщений: Регистрация: 12.05.2020
23.09.2021 07:33:57
Цитата
Roman Azarov написал: TGB , добрый день! Оба пожелания зарегистрированы, мы постараемся их рассмотреть. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожеланий в будущих версиях ПО. Каких-либо сроков назвать не можем. Как будет результат анализа пожеланий, мы сообщим Вам в данной теме.
Сегодя 23.09.21. С тех пор прошло более четырех месяцев. Где результат рассмотрения? Просьба к поддержке: сообщить результат рассмотрения первого пожелания (изложенного мною, с протестированным вариантом его реализации в виде конкретного кода), устраняющего блокировку потоков длинными участками байт-кода. У вас есть замечания относительно предложенного мною кода? Я готов дать развернутый комментарий. ---- !! Второе пожелание факультатив и, наверное, его не стоит реализовывать. Оно не устраняет ошибок в QLua, достаточно сложное в реализации для разработчиков QUIK (и при некорректной реализации может внести ошибки в QLua) и, наверное, не актуально для большинства пользователей QUIK.
TGB, в одном месте вы , что байт-код не должен прерываться, в другом наоборот. Вас двое что ли?
Надо делать так, как надо. А как не надо - делать не надо.
Пользователь
Сообщений: Регистрация: 12.05.2020
23.09.2021 11:42:41
Цитата
Старатель написал: TGB , в одном месте вы пишите , что байт-код не должен прерываться, в другом наоборот. Вас двое что ли?
Не надо комплиментов насчет того, что я могу заменить двоих . Нужно все-таки отличать настоящее и будущее. Вы что. не понимаете разницу между настоящим и будущим? Или притворяетесь? В настоящем байт-код в QLua не должен прерываться (так это сейчас "коряво" реализовано), а я пишу о "светлом" будущем, когда длинные участки участки непрерывного байт-кода не должны блокировать друг друга. Когда вы работаете в любой операционной системе на ПК с одним одним ядром ЦП, то при том что ядро одно, выполнение нескольких приложений в этих ОС не блокируют друг друга, а получают свой кванты ЦП. Про это вам известно?
Пользователь
Сообщений: Регистрация: 21.08.2015
23.09.2021 12:23:32
Цитата
TGB написал: в любой операционной системе на ПК с одним одним ядром ЦП
Выделил ключевое. Как только ядер больше одного, тут же начинают весьма себе блокировать.
Цитата
TGB написал: а я пишу о "светлом" будущем, когда длинные участки участки непрерывного байт-кода не должны блокировать друг друга
. Потом расскажете, удобно ли.
Пользователь
Сообщений: Регистрация: 12.05.2020
23.09.2021 12:36:11
Цитата
Anton написал: Выделил ключевое. Как только ядер больше одного, тут же начинают весьма себе блокировать.
То есть. когда вы пользуетесь браузером, у вас QUIK перестает работать?
Цитата
Anton написал: Устройте его себе сами . Потом расскажете, удобно ли.
Рассказываю. То что я уже устроил себе, мне удобно.
Пользователь
Сообщений: Регистрация: 21.08.2015
23.09.2021 12:57:17
Цитата
TGB написал: То есть. когда вы пользуетесь браузером, у вас QUIK перестает работать?
Утрировать можно сколько угодно. Браузер более-менее нормально написан, поэтому не перестает. А вот когда квик с полными таблицами стартует, кое-что таки наблюдается. Речь-то шла блокируют ли ядра друг друга, так вот блокируют только в путь, например, каждый Interlocked* лочит шину, при этом все ядра встают и ждут. Сравните по времени цикл с v = v + 1; с аналогичным по функционалу циклом с InterlockedIncrement(&v), особенно если таких циклов несколько в разных потоках.
Пользователь
Сообщений: Регистрация: 12.05.2020
23.09.2021 13:37:45
Цитата
Anton написал: Как только ядер больше одного, тут же начинают весьма себе блокировать.
То есть, для вас чем меньше ядер у ПК, тем лучше?
Пользователь
Сообщений: Регистрация: 21.08.2015
23.09.2021 13:57:27
Цитата
TGB написал: для вас чем меньше ядер у ПК, тем лучше?
Я такого не писал нигде и никогда. Что уж так грубо набрасывать-то.
Кому охота в граммах прикинуть, что такое лок шины и чем он плох, вот это надо собрать в релизном конфиге и запустить.
Код
#include <cstdio>
#include <intrin.h>
#include <process.h>
#include <Windows.h>
static const unsigned int NTHRD = 64;
static const unsigned int NITER = 10000000;
static volatile long cnt[NTHRD];
static unsigned int __stdcall RawLoopThread(void * pvoid)
{
volatile long * pcnt = cnt + reinterpret_cast<unsigned int>(pvoid);
*pcnt = 0;
for(unsigned int n = 0; n < NITER; ++n)
*pcnt = *pcnt + 1;
return *pcnt;
}
static unsigned int __stdcall InterlockedLoopThread(void * pvoid)
{
volatile long * pcnt = cnt + reinterpret_cast<unsigned int>(pvoid);
*pcnt = 0;
for(unsigned int n = 0; n < NITER; ++n)
_InterlockedIncrement(pcnt);
return *pcnt;
}
static void MeasureLoop(unsigned int (__stdcall * pfn)(void *), const char * name)
{
unsigned long long t = ::GetTickCount64();
HANDLE threads[NTHRD] = { 0 };
for(unsigned int n = 0; n < NTHRD; ++n)
{
unsigned int tid;
threads[n] = reinterpret_cast<HANDLE>(_beginthreadex(nullptr, 0,
pfn, reinterpret_cast<void *>(n), CREATE_SUSPENDED, &tid));
}
for(unsigned int n = 0; n < NTHRD; ++n)
::ResumeThread(threads[n]);
::WaitForMultipleObjects(NTHRD, threads, TRUE, INFINITE);
t = ::GetTickCount64() - t;
for(unsigned int n = 0; n < NTHRD; ++n)
::CloseHandle(threads[n]);
printf(" %s:\n %0.9f seconds\n %0.9f microseconds per iteration\n",
name, t / 1000.0, t * 1000.0 / NITER);
}
void main(void)
{
printf("Performance:\n");
::MeasureLoop(::RawLoopThread, "RawLoopThread");
::MeasureLoop(::InterlockedLoopThread, "InterlockedLoopThread");
printf("Press ENTER to exit\n");
getchar();
}
Данные пожелания еще не были рассмотрены. Как только появится какая-то новая информация, мы сообщим об этом в данной ветке форума.
Пользователь
Сообщений: Регистрация: 12.05.2020
06.05.2022 18:03:01
Цитата
Roman Azarov написал: Данные пожелания еще не были рассмотрены. Как только появится какая-то новая информация, мы сообщим об этом в данной ветке форума.
Мое предложение от 22.04.2021 15:59:54
Прошел год. ----------------- Напомню описание ситуации и вариант ее устранения. --- Бывают ситуации зависания в QLua, когда основной поток обслуживания колбеков всех скриптов пользователя, а также таблиц QUIK (это не таблицы Lua), блокируется выполнением длинного цикла пользовательской программы на «чистом» Lua, в котором нет ни вызова seep ни вызова дру-гих C-функций. Это может порождать ошибки, которые для многих пользователей QLua (использующих несколько запускаемых скриптов) являются неожиданными и труднообъяснимыми. Блокируются выполнения колбеков всех скриптов из-за выполнения длинного цикла пользовательской программы на «чистом» Lua в каком-то из запущенных пользователем скриптов. При этом зависает рабочее место QUIK. Это системная ошибка QLua. ---- Есть простой вариант реализации пожелания (далее список изменений, реализующих этот вариант в тексте исходников QLua ): 1. В файле lstate.h после строки: lu_byte allowhook; добавить: int Счетчик_для_переключения_State; 2. В файле lstate.с после строки: L->errfunc = 0; добавить: L->Счетчик_для_переключения_State = 0; 3. В файле lstate.с после строки: L1->stacksize = BASIC_STACK_SIZE; добавить: L1->Счетчик_для_переключения_State = 0; 4. В файле lvm.с после строки: StkId ra; добавить: if (++L->Счетчик_для_переключения_State > 1000) { // 1000 надо задать кон-стантой L->Счетчик_для_переключения_State = 0; lua_unlock(L); lua_lock(L); } ----------------------- В чем проблема реализации этого пожелания?
Пользователь
Сообщений: Регистрация: 30.01.2015
06.05.2022 18:07:09
Проблема в отсутствии программистов необходимой квалификации у разработчика.
написал: Данные пожелания еще не были рассмотрены. Как только появится какая-то новая информация, мы сообщим об этом в данной ветке форума.
Мое предложение от 22.04.2021 15:59:54
Прошел год. ----------------- Напомню описание ситуации и вариант ее устранения. --- Бывают ситуации зависания в QLua, когда основной поток обслуживания колбеков всех скриптов пользователя, а также таблиц QUIK (это не таблицы Lua), блокируется выполнением длинного цикла пользовательской программы на «чистом» Lua, в котором нет ни вызова seep ни вызова дру-гих C-функций. Это может порождать ошибки, которые для многих пользователей QLua (использующих несколько запускаемых скриптов) являются неожиданными и труднообъяснимыми. Блокируются выполнения колбеков всех скриптов из-за выполнения длинного цикла пользовательской программы на «чистом» Lua в каком-то из запущенных пользователем скриптов. При этом зависает рабочее место QUIK. Это системная ошибка QLua. ---- Есть простой вариант реализации пожелания (далее список изменений, реализующих этот вариант в тексте исходников QLua ): 1. В файле lstate.h после строки: lu_byte allowhook; добавить: int Счетчик_для_переключения_State; 2. В файле lstate.с после строки: L->errfunc = 0; добавить: L->Счетчик_для_переключения_State = 0; 3. В файле lstate.с после строки: L1->stacksize = BASIC_STACK_SIZE; добавить: L1->Счетчик_для_переключения_State = 0; 4. В файле lvm.с после строки: StkId ra; добавить: if (++L->Счетчик_для_переключения_State > 1000) { // 1000 надо задать кон-стантой L->Счетчик_для_переключения_State = 0; lua_unlock(L); lua_lock(L); } ----------------------- В чем проблема реализации этого пожелания?
Таких проблем не существует, если делать как у меня. --------------------------- Робот с любым числом алгоритмов и любым числом инструментов работает в одном скрипте QUIK. ------------------------- Каждый колбек существует лишь в одном экземпляре. ------------------------ Любой алгоритм для работы робота пишется в виде скрипта на чистом луа, без QLUA и загружается в отдельный поток для конкретного инструмента функцией main скрипта QUIK. ------------------------ Параметры по инструменту или портфелю передаются как параметры функции в скрипт алгоритма, а данные и индикаторы - в виде mapping матрицы. ---------------------------- Тестировал данную реализацию на двух сотнях инструментах. ================= Ну очень нравится как оно работает на версии 9.4. ---------------------------- Можно делать HFT, чего раньше даже не думал, что на LUA в квике будет так быстро работать. ------------------------------- Правда все это работает с моей библиотекой на СИ. --------------------- В итоге , В настоящее время Вообще нет никаких пожеланий по допиливанию QUIK.
Пользователь
Сообщений: Регистрация: 12.05.2020
06.05.2022 21:08:44
Цитата
nikolz написал: Таких проблем не существует, если делать как у меня.
Я написал свое предложение не про вас, не для вас и даже не для, конкретно, себя. Это про системную ошибку в QLua.
Цитата
nikolz написал: Можно делать HFT, чего раньше даже не думал
Ну, вы фантазер. HFT в QUIK ? Это диагноз.
Пользователь
Сообщений: Регистрация: 25.09.2020
06.05.2022 22:45:50
nikolz, Ни секунды не было сомнений, что "робот с любым числом алгоритмов и любым числом инструментов должен работать в одном скрипте QUIK"
На весь скрипт имеется один-единственный колбек, который, естественно, существует в одном экземпляре.
Любой алгоритм для работы робота пишется в виде скрипта на чистом луа, без QLUA и выполняется в потоке main для всех инструментов.
Параметры по инструменту или портфелю хранятся в одной глобальной переменной (таблице Lua) и никуда не передаются.
И никаких индикаторов!
Тестировал данную реализацию на разном количестве инструментов - обычно до двух тысяч (пробовал и на 20000, но притормаживает).
Ну очень нравится как оно работает в любой из версии Lua и QUIK.
Всё это работает вообще без каких-либо библиотек.
Очень быстро у меня исчезли любые пожелания по допиливанию QUIK. Я их просто боюсь - не все ещё глупости сделаны.
А насчёт HFT на QUIK согласен: это диагноз.
Пользователь
Сообщений: Регистрация: 12.05.2020
07.05.2022 10:08:43
Цитата
TGB написал: Мое предложение от 22.04.2021 15:59:54
Добавлю: 1) Я уже тогда написал, что вариант предлагаемого решения проверен мною на моем стенде имитации QLua (исключая его API). 2) Последний случай бурного обсуждения системной ошибки QLua, устраняемой моим предложением . Причем этот случай далеко не первый.
Пользователь
Сообщений: Регистрация: 30.01.2015
07.05.2022 12:12:06
Цитата
Владимир написал: , Ни секунды не было сомнений, что "робот с любым числом алгоритмов и любым числом инструментов должен работать в одном скрипте QUIK"
На весь скрипт имеется один-единственный колбек, который, естественно, существует в одном экземпляре.
Любой алгоритм для работы робота пишется в виде скрипта на чистом луа, без QLUA и выполняется в потоке main для всех инструментов.
Параметры по инструменту или портфелю хранятся в одной глобальной переменной (таблице Lua) и никуда не передаются.
И никаких индикаторов!
Тестировал данную реализацию на разном количестве инструментов - обычно до двух тысяч (пробовал и на 20000, но притормаживает).
Ну очень нравится как оно работает в любой из версии Lua и QUIK.
Всё это работает вообще без каких-либо библиотек.
Очень быстро у меня исчезли любые пожелания по допиливанию QUIK. Я их просто боюсь - не все ещё глупости сделаны.
А насчёт HFT на QUIK согласен: это диагноз. ::
Так тоже делал. ---------------------------- Но узкое место в таком решении - это один поток main для всех инструментов. -------------------- Если тестировали, то хорошо бы увидеть конкретное затраченное время на обработку изменений всех инструментов в потоке main. ------------------ Возможно, что вас устраивает такое решение, а мне интересно иное. ------------------ Мое решение позволяет масштабировать робота по алгоритмам , инструментам и приложениям. --------------- К сожалению, не видел пока каких-либо подробных тестов по быстродействию сторонних решений , в том числе и Ваших . =========== В моем варианте реакция робота на заявку и изменение цены составляет не более 100 мкс. ------------------------ Это время вполне соизмеримо с реакцией существующих HFT роботов. ----------------------------- А уж в сравнении с человеком, который играет в стакане с реакцией в 1000 раз медленнее, чем мое решение Вообще говорить не серьезно. ------------------------- Так что HFT робот вполне реально, но должен быть в дата центре. ============ Кроме того мое решение универсально и позволяет делать скрипты на луа многопоточные,. ============= Следующим этапом моего решения будет самообучающийся робот. ------------------- Следите за новостями.
Пользователь
Сообщений: Регистрация: 30.01.2015
07.05.2022 12:35:12
и еще... ------------------- вам только кажется, что скрипт в main у Вас на чистом луа. --------------- На самом деле вы используете в main QLUA А она на СИ. ============ Кроме того, есть срытый от Вас тормоз, который заложен в основание main. ================= Дело в том, что все функции колбека объявляются как глобальные . все функции библиотеки QLUA тоже являются глобальными. -------------------------- Т е скрипт в основном потоке и в потоке main имеют общий глобальный стек. Это значит, что main и колбеки не могут одновременно как минимум записывать данные в глобальные переменные. А как максимум, вообще обращаются к глобальному стеку последовательно. ================= Т е поставьте тормоз в колбеке на глобальной функции и функция main начнет глючить и тормозить либо пропускать обработку Можно сделать и наоборот. =============== Поэтому периодически и вылетают непонятки, которые особо пытливые ловят и выкладывают на форуме. Но прикольно то, что разработчики такие глюки не поймают от слова никогда, так как им для этого надо весь глючный скрипт и соответствующий поток данных. ============== В итоге, так как проблема в концепции построения скриптов, то бороться с ней Вы будете вечно. Желаю успехов.
Пользователь
Сообщений: Регистрация: 12.05.2020
07.05.2022 14:43:28
Цитата
nikolz написал: Так что HFT робот вполне реально, но должен быть в дата центре.
Дата центр вам не поможет. Вам надо арендовать для вашего QUIK специальный сервер на бирже с прямыми каналами доступа к торгам. Но и это вам не поможет при использовании стандартного рабочего места QUIK, так как API взаимодействия QLua с QUIK выполняется в среде Lua, в которой автоматическое управление памятью, и в произвольные моменты времени может запускаться сборка мусора. Сборка мусора может вносить заметные задержки (не исключено миллисекундные) при взаимодействии вашей программы с QUIK. Вы, конечно, можете отключить сборку мусора, но тогда флаг вам в руки . Попробуйте. ---------- Вообще, надо заниматься тем, о чем есть хоть какое-то понятие. HFT роботы не "манна небесная" и о проблемах их использования (как технических так и алгоритмических) достаточно информации в интернете.
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
07.05.2022 18:37:46
Цитата
TGB написал: Прошел год. ----------------- Напомню описание ситуации и вариант ее устранения. --- Бывают ситуации зависания в QLua, когда основной поток обслуживания колбеков всех скриптов пользователя, а также таблиц QUIK (это не таблицы Lua), блокируется выполнением длинного цикла пользовательской программы на «чистом» Lua, в котором нет ни вызова seep ни вызова дру-гих C-функций.
TGB, как я понял, проблемы-то и нет вовсе. Или что вам продемонстрировала реальная жизнь?
Надо делать так, как надо. А как не надо - делать не надо.
Пользователь
Сообщений: Регистрация: 12.05.2020
07.05.2022 19:51:06
Цитата
Старатель написал: TGB , как я понял, проблемы-то и нет вовсе. Или что вам продемонстрировала реальная жизнь?
Читайте:
Цитата
TGB написал: 2) Последний случай бурного обсуждения системной ошибки QLua, устраняемой моим предложением . Причем этот случай далеко не первый.
Что именно? В той теме человеку и объяснили, что пример написан криво. Отдать 100% CPU под два оператора - такое себе. Реальный пример есть?
Надо делать так, как надо. А как не надо - делать не надо.
Пользователь
Сообщений: Регистрация: 25.09.2020
07.05.2022 21:17:18
nikolz, Один поток main для всех инструментов - это единственное устойчиво работающее решение при всех глюках системного софта.
Мне плевать на "конкретное затраченное время на обработку изменений всех инструментов в потоке main". Я уже говорил, что раз в секунду опрашиваю все курсы из ТТТ, за которыми следит скрипт. Раньше опрашивал раз в полсекунды, но особой необходимости в этом нет - точность измерений почти одинаковая. Отчего же меня не устраивает такое решение? Тысячу-другую тикеров скрипт держит без проблем - чего ещё желать? А уж про масштабирование и заикаться нечего: всё прекрасно масштабируется и числу тикеров, и по величине кошелька, и по частоте сделок. По чему ещё требуется масштабировать?
Ах, Вы опять ловлей этих дурацких микросекунд занялись. Ну, флаг в руки. Когда коту делать нечего...
Лапуль, HFT предполагает высокую частоту СДЕЛОК, а не суходроч с заявками. А сделкам насрать на все Ваши микросекунды - они будут тогда, и только тогда, когда найдётся покупатель на продаваемую мной сделку и продавец на покупаемую.
Да, лапуль - со мной вообще говорить не серьёзно. Мой алгоритм работает и зарабатывает, а Ваш суходроч только на тесты мудацкие годится. Это в лучшем случае.
ЗА КАКИМ ХЕРОМ, лапуль, Вам "делать скрипты на луа многопоточные"? Что, зарабатывающие делать не получается, Данила-мастер?
О! Самообучающийся робот - это круто! Раз у разработчика мозгофф не хватает, так вдруг самообучающийся робот сам справится? Браво, лапуль! Бурные продолжительные аплодисменты, переходящие в овацию!
Мне, честно говоря, настать, чистый там луа или QLUA и даже чем они отличаются. Оба языка есть полное говно, а в сортах говна разбираться я не намерен.
Лапуль, сколько можно повторять? У меня НЕТ никаких тормозов, мой скрипт спокойно работает с ТЫСЯЧАМИ тикеров, чего, как я полагаю, Ваше "микросекундное" говно делать не способно. Я прав?
Лапуль, сколько можно повторять? Коллбек у меня ВААПЩЕ ОДИН! Строго говоря, два, но один из них OnStop, и сохранён лишь для того, чтобы корректно отработать, если рука даванёт на кнопку "Остановить". Какая, в жопу, разница, как там "функции колбека объявляются"? ДА НАСРАТЬ, лапуль! Коллбек - это обычное прерывание. ЗА КАКИМ ХЕРОМ им "одновременно записывать данные в глобальные переменные"? Заняться больше нечем? Мой коллбек просто снимает полученные данные, забрасывает их в стек и тут же заканчивает работу. Ах, да - ещё обработка прерываний от юзера. Но там тоже обработчик снимает данные о нажатой клавише или мышки и тоже немедленно уё в мейн. ОТКУДА, блин, здесь может быть "тормоз в колбеке"? С КАКОГО БОДУНА "функция main начнет глючить и тормозить либо пропускать обработку"? Вы ХОТЬ ЧТО-НИБУДЬ понимаете в программировании?
TGB, Специальный сервер на бирже с прямыми каналами доступа к торгам тоже не поможет - Квик, батенька! Да ещё и Луа. А, ну да - ещё не дочитал до конца.
Предлагаю определение: HFT роботы не "манна небесная", а индикатор отсутствия у разработчика хоть одного мало-мальски пригодного алгоритма торговли.
Пользователь
Сообщений: Регистрация: 12.05.2020
07.05.2022 22:31:31
Цитата
Владимир написал: TGB , Специальный сервер на бирже с прямыми каналами доступа к торгам тоже не поможет - Квик, батенька! Да ещё и Луа. А, ну да - ещё не дочитал до конца.
Согласен.
Пользователь
Сообщений: Регистрация: 12.05.2020
07.05.2022 22:38:53
Цитата
Старатель написал: пример написан криво. Отдать 100% CPU под два оператора - такое себе.Реальный пример есть?
Ну, если вам этот пример не нравится, то ждите дальше.
написал: Так что HFT робот вполне реально, но должен быть в дата центре.
Дата центр вам не поможет. Вам надо арендовать для вашего QUIK специальный сервер на бирже с прямыми каналами доступа к торгам. Но и это вам не поможет при использовании стандартного рабочего места QUIK, так как API взаимодействия QLua с QUIK выполняется в среде Lua, в которой автоматическое управление памятью, и в произвольные моменты времени может запускаться сборка мусора. Сборка мусора может вносить заметные задержки (не исключено миллисекундные) при взаимодействии вашей программы с QUIK. Вы, конечно, можете отключить сборку мусора, но тогда флаг вам в руки :: . Попробуйте. ---------- Вообще, надо заниматься тем, о чем есть хоть какое-то понятие. HFT роботы не "манна небесная" и о проблемах их использования (как технических так и алгоритмических) достаточно информации в интернете.
объясняю почему у меня сборщик не мешает. Тестировал своего робота на выставлении и снятии заявок по 200 инструментам. При этом осуществлялся прием данных по каждому из инструментов по таймам 1,3,30 мин. Работал примерно 4 часа. выставил и снял 150 тысяч заявок. Размер памяти скрипта составил 5 Мбайт. При работе моих скриптов практически нет мусора. Если сборщик будет мешать, то я его могу отключить от слова навсегда. При этом размер матрицы -маппинг фалов на диске открывался по 2 Мбайта на инструмент. т е 400 Мбайт. -------------------
Пользователь
Сообщений: Регистрация: 30.01.2015
09.05.2022 16:23:04
и еще в тесте с выставление заявок загрузка процессора не превышала 5%.
Лапуль, да хрен бы с ним, со сборщиком! На кой Ваш сраный "сервер в датацентре", если торгуете через брокера? А у брокера сервер где? Прямая торговля на бирже? А за каким тогда нужен этот убогий Квик с не менее убогим Луа? И говорил уже: Ваш суходроч с ЗАЯВКАМИ не говорит вообще ни о чём. Вот когда Вы "примерно за 4 часа совершите 150 тысяч СДЕЛОК", тогда можете о чём-то говорить. Хотя слабо верится, что у Вас денег хватит хотя бы на одну минуту такой работы.
Пользователь
Сообщений: Регистрация: 14.10.2021
10.05.2022 03:52:26
Цитата
nikolz написал: и еще в тесте с выставление заявок загрузка процессора не превышала 5%.
тест и боевой режим сильно отличаются между собой , одни дубли сообщений от биржи на каждую выставленную заявку и каждое её изменение сжирают ресурса компа не меряно , а потом еще и дубли и на свершившиеся сделки сильно тормозят процесс . Плюсом нужно вести учет своих заявок в стакане и своих исполнившихся сделок , и в боевом режиме это начинает нарастать как снежный ком и ваш комп начинает притормаживать через несколько часов а к концу дня уже тормозит по страшному . Но знаю точно что с 7 утра до 23,50 вечера на мощном компе и через Квик и Луа реально совершать 100 тысяч сделок . А вот для NFT нужны другие програмульки и протокола прямого доступа на биржу , и самостоятельно их создать и отладить проблематично . Брокеры в отличии от Квика или Транзака нам их не предоставляют и даже за деньги а на просьбу отвечают ссылкой например на Михаила Сухова с ценой по 150 т.р за один протокол . Да и биржа неслабую ежемесячную плату взимает за такой прямой доступ и особенно за размещение в своем дата центре.
Пользователь
Сообщений: Регистрация: 25.09.2020
10.05.2022 13:25:10
БорисД, Согласен: 100 тысяч сделок в сутки - это всё равно никакой не HFT, это примерно две сделки в секунду. А если в портфеле сотня тикеров, то в среднем у них и вообще получается одна сделка в три минуты. А если 1000 тикеров... Но для Квика это почти предельная скорость.
Пользователь
Сообщений: Регистрация: 12.05.2020
12.06.2022 15:58:52
Код приведенный в моем сообщении 174: был проверен мною давно для Lua 5.3.5.
Для Lua 5.4.1 аналогичный код (но есть отличие), проверенный мною недавно и устраняющий блокировку потоков в QUIK выполнением длинного цикла пользовательской программы на «чистом» Lua, следующий: 1. В файле lstate.h после строки: volatile l_signalT hookmask; добавить: int Счетчик_для_переключения_State; 2. В файле lstate.с после строки: L->errfunc = 0; добавить: L->Счетчик_для_переключения_State = 0; 3. В файле lstate.с: - после строки: L1->ci = ci; добавить: L1->Счетчик_для_переключения_State = 0; - после строки: L->oldpc = 0; добавить: L->Счетчик_для_переключения_State = 0; 4. В файле lvm.с после строки: StkId ra; /* instruction's A register */ добавить: int const Период_переключения_State = 1000; if (++L->Счетчик_для_переключения_State > Период_переключения_State) { L->Счетчик_для_переключения_State = 0; // ! Имитация вызова "пустой" C-функции -- ProtectNT((lua_unlock(L), lua_lock(L))); }
Пользователь
Сообщений: Регистрация: 30.01.2015
12.06.2022 18:22:42
"чистый" луа - это как "чистая" грязь. понятие бессмысленное. ----------------------------- Рассуждая о "чистом" луа Вы полезли в функции СИ , которые исполняют этот чистый луа, вместо того, чтобы написать грамотно свой длинный цикл. -------------------------------- Длинный цикл в программах обработки данных в реальном времени - верх непрофессионализма в программировании и дилетантства в обработке данных. -------------------- Так как поток колбеков и main имеют общий глобальный стек, то , во многих случаях, проблема зависания квика ликвидируется заменой глобальных переменных локальными.
Лапуль, почти полвека программирую, но что такое "длинный цикл" - первый раз слышу! А знать бы надо, раз уж это дело "верх непрофессионализма в программировании и дилетантства в обработке данных". Не соблаговолите ли рассказать про этот "верх"?
Лапуль, ДА НАСРАТЬ, что "поток колбеков и main имеют общий глобальный стек"! Если они его, конечно, имеют - какая разница?. Лично я завёл в самом скрипте ТРИ "глобальных стека", и все эти "проблемы зависания квика" просто перестали существовать.
Лапуль, а вот для меня понятие "чистый" луа очень даже осмысленное. Это означает, что весь код скрипта написан ТОЛЬКО на Lua, без всяких библиотек, сишных конструкций и прочего дерьма, причём работает он на ЛЮБОЙ версии Lua, то есть не загажен операторами, зависящими от версии языка. Например, мой скрипт именно такой, на чистом Lua - чище не бывает!
Пользователь
Сообщений: Регистрация: 12.05.2020
12.06.2022 23:05:09
Цитата
nikolz написал: Рассуждая о "чистом" луа Вы полезли в функции СИ , которые исполняют этот чистый луа, вместо того, чтобы написать грамотно свой длинный цикл.
Где вы увидели мой код с длинным циклом? Вы филосов ? И готовы комментировать критически все, что угодно, не разбираясь в комментируемом лишь бы накропать свой очередной безумный текст? Вы, что, до сих не поняли, что в комментируемых вами моих последних сообщениях данной ветки я выступаю не как пользователь, лично со своей проблемой, а обращаю внимание на общую, системную ошибку текущей реализации QUIK?
Пользователь
Сообщений: Регистрация: 30.01.2015
13.06.2022 06:33:35
Цитата
TGB написал: Для Lua 5.4.1 аналогичный код (но есть отличие), проверенный мною недавно и устраняющий блокировку потоков в QUIK выполнением длинного цикла пользовательской программы на «чистом» Lua
вот цитата Вашего эссе: Для Lua 5.4.1 аналогичный код (но есть отличие), проверенный мною недавно и устраняющий блокировку потоков в QUIK выполнением длинного цикла пользовательской программы на «чистом» Lua
Пользователь
Сообщений: Регистрация: 25.09.2020
13.06.2022 06:51:36
nikolz, Так что же такое "длинный цикл"? Гугл тоже не знает: по запросу выдаёт ссылки на менструальый цикл. Но что бы это ни было, лапуль, он спрашивал: "Где вы увидели МОЙ код с длинным циклом?", а Вы привели его цитату про блокировку потоковв QUIK выполнением длинного цикла ПОЛЬЗОВАТЕЛЬСКОЙ ПРОГРАММЫ.
Пользователь
Сообщений: Регистрация: 12.05.2020
13.06.2022 17:29:32
Цитата
Владимир написал: nikolz , Так что же такое "длинный цикл"? Гугл тоже не знает: по запросу выдаёт ссылки на менструальый цикл. Но что бы это ни было, лапуль, он спрашивал: "Где вы увидели МОЙ код с длинным циклом?", а Вы привели его цитату про блокировку потоковв QUIK выполнением длинного цикла ПОЛЬЗОВАТЕЛЬСКОЙ ПРОГРАММЫ.
Длинный цикл на «чистом» Lua - это сленг данной ветки, обозначающий долго выполняющийся фрагмент скрипта, в котором нет вызовов C-функций. Например, sleep это С-функция. С -функциями являются функции из стандартного пакета Lua и многие функции из подключаемых C-пакетов. Простейшим примером длинного цикла на «чистом» Lua может быть следующий фрагмент кода: for i = 1, 5000000000 do end Если вы вставите этот цикл в свой скрипт сразу после function main (), то увидите, что пока этот цикл исполняется, ваш терминал полностью «подвиснет» и вы не сможете даже остановить свой скрипт. Приведенный пример, конечно, искусственный, но кто запрещает пользователю написать содержательный фрагмент кода без использования C-функций и исполняющийся достаточно долго. Такое «подвисание» QUIK, по-хорошему, надо бы устранить, но, с учетом того что такие ситуации, наверное, редкие, а их устранение – правка сложной виртуальной машины Lua разработчиком QUIK, то я все больше склоняюсь к тому, что это тот случай, когда можно оставить это как есть. -------------- Вы точно отметил: nikolz досих пор не понял, что у меня ник TGB, а не «пользователь».
