Serge123 написал: Видимо, имелось в виду, что длл получает инфо, что коллбэк что-то записал в очередь, и длл запускает main, которая всё остальное время спит. Или что-то подобное.
Если не ошибаюсь, Вы осваиваете написание dll для луа. Вроде бы уже выкладывал исходник для event и wait ----------------- Можете взять библиотеку w32 для Lua:
Почему в этой программке утекает память??
Пользователь
Сообщений: Регистрация: 30.01.2015
25.04.2024 17:04:34
пардон, печатка: Да именно sleep в main. Когда очередь пустая, то main остановится на указанное время.
написал: Кроме того, у меня нет sleep. Поэтому задержка на обработку любого колбека не более 0.1 ms. Это на порядки меньше чем задержка со sleep.
Здесь я не понял, о каком sleep идёт речь. У меня в скрипте sleep(10) используется один раз в main в цикле обработки очереди от коллбэков. В Lua по-моему нельзя прервать паузу, если в мой массив (очередь) коллбэк что-то записал.
Да именно sleep в main. Когда очередь main остановится на указанное время. Все это время колбеки будут забивать очередь и даже для sleep(10) . Но при sleep(10) будет пустая трата времени ядра. Посмотрите сколько у вас будет загрузка процессора, если sleep(10) или sleep(1000). ------------------------- Вместо sleep ставим wait в и создаем event. в итоге main просыпается сразу по срабатыванию колбека и спит произвольное время, если сигналов нет. Пустой траты времени нет совсем. И main реагирует на колбек примерно в 100 раз быстрее. ------------- Кроме того, с помощью wait можно реализовать дополнительно запуск main по таймеру. --------------- Например, делал так: -------------------- main запускается колбеками, но не реже 1 раз в секунду(10 секунд).
написал: так как вызов функции getQuoteLevel2 существенно меньше рисования стаканов.
А у Вас обработка сравнима по времени с getQuoteLevel2 и другими необходимыми Вам вызовами qlua? Я тестирую на том, чем сам потом пользоваться буду, для меня пока нет разницы. В очереди для стаканов не вижу смысла, кстати, я просто хэш-таблицу заюзаю с ключами по sec и содержимым sent,updates,received,стакан.
Обработка сравнима. Создаю потоки из пула системных потоков и в них запускаю Luajit (из всего, что пробовал это быстрее всех работает). В указанном ранее тесте в отдельные моменты создавалось максимум 11 потоков. ------------------ Я не рисую стаканы. Скальпингом не занимаюсь. Использовал стакан при реализации алгоритма закрытия позиции по стопу. Но в основном использую либо лучшие предложения либо по рынку, так как торгую лишь ликвидными акциями.
Я провёл тест, который не выявил разницы. Может быть, getQuoteLevel2 не нужна синхронизация? Запустил два почти одинаковых скрипта, рисующих стакан каждый в своём потоке (настроено так, чтобы гуи рисовался в main скрипта, а не в главном потоке квика). Ниже часть кода одного из скриптов с комментами про замены, чтобы получить второй скрипт. Единственная стабильная разница, что вызов в main даёт на 1 секунду больше CPU time, хотя этот скрипт был запущен на 4 секунды позже (запускал в дневной клиринг, как видно на скрине, чтобы не было обновлений стакана на срочке)
Код
Мы с Вам о принципиально разных решениях говорим. -------------------------------------- В вашем тесте - один инструмент, стакан которого вы рисуете. В этом случае Вы не заметите разницы, так как вызов функции getQuoteLevel2 существенно меньше рисования стаканов. ============== Моя постановка задачи для теста такая. ---------------------- Торгуется портфель инструментов. Поток main работает по событиям. Все события формируют очередь(может быть несколько очередей) ---------------- 1) В этом случае, если getQuoteLevel2 вызывать в колбеке, то в очередь попадет весь стакан и clas и sec. Т е время работы колбека всегда будет включать запрос стакана. ========= 2) Если в колбеке не запрашивать стакан, то в очередь запишется clas и sec. Т е время работы колбека будет меньше всегда, чем в первом случае. -------------------- В main будет вызываться функция getQuoteLevel2 . Она находится в глобальном стеке и обращение к ней уже синхронизировано в библиотеке QLUA. Но так как к ней никто вне main не обращается, то ее вызов не будет ничего тормозить и ничего блокировать не надо. ------------------ Если рынок очень активен, то в первом варианте Вы получите целую толпу стаканов, которые уже устарели. --------------------- Во втором варианте в очереди будет всего один колбек и в main будет прочитан самый последний стакан. -------------------- У меня робот работает именно так.
Почему в этой программке утекает память??
Пользователь
Сообщений: Регистрация: 30.01.2015
24.04.2024 11:36:00
, Если хотите определить причину, то запишите в лог значения времени : время выставления заявки скриптом, время колбек транзакции время колбека заявки время колбека сделки ----------------- По этим данным Вы увидите что тормозит. ----------------- Относительно тормоза при проигрывании музыки Специально для вас выкладывал исходник с асинхронным проигрыванием. Чтобы не ждать, надо в нем установить второй параметр 0.
написал: Если вы на открытии сделки совершаете, то помимо непосредственно ваших сделок ещё и большой поток информации в эти моменты приходит, поэтому Квик это тяжело переваривает.
Да, я видел, что причина торможения во время моих сделок в том, что иногда почему-то идёт большое число мелких сделок, напр., десятки сделок по 1 акции. Я так и не могу понять, зачем кто-то выставляет заявки по одной акции, как будто кто-то отлаживает свою программу или что-то тестирует. Если нет потока мелких сделок, то торможения нет.
По одной заявке выставляют HFT роботы, скальперы и ММ.
написал: Предполагаю, что Сергей описывал ситуацию зависания при приходе его личных сделок ("когда идёт много моих сделок, я ясно вижу торможение") , хотя конкретики мало дал. Отключать алгоритм Нейгла ему смысла нет. Его никто не отключает и у всех всё работает, значит, не в нём дело.
Точно, я даже предположил, что особенно на задержку влияют звуковые сигналы. Какая нужна конкретика? Где-то до октября 2023 я и в утреннюю и в вечернюю сессии удачно выставлял заявки с пом. скрипта, иногда даже видел по содержимому стаканов в файле, что я в очереди первый. Первым быть не всегда хорошо, потому что во время премаркета бывает в сумме крупная встречная заявка, за это снимают деньги. Но потом перестало получаться попадать в начало очереди на вечерней сессии (а утром по-прежнему всё ОК). Такое впечатление, что мосбиржа вечером варьирует время начала приёма заявок в пределах 2 секунд. То ли вечером возникли какие-то задержки (в том числе с получением ответов от сервера на заявки). Поэтому я и решил попробовать вечером отключить алгоритм Нейгла, но от этого получился полный затык в работе Квика.
Попробуйте вывести в лог файл время прихода колбеков OnTransReply и OnOrder и сравните с временем регистрации сделки из таблицы сделок. Если выложите эти времена, то можно будет что-то конкретное сказать.
написал: В моем тесте использовался колбек опParam , а это и есть сообщения, которые отображаются в ТТП. Там не только сделки, но и любые изменения по инструменту. Тест выставлял заявки по инструменту, по которому совершена сделка. Снимал заявку, когда она зарегистрирована сервером, т е выставлена в стакан. Тормоз 2-3 секунды наблюдается в КВИКЕ, если много окон и других приложений открыто. Я такое наблюдал давно на одноядерном компе по XP. ------------------ Можно увидеть это вечером, когда мало сделок или на неликвиде.. --------------- Но что конкретно происходит без логов сказать точно невозможно.
Видимо, тут и есть недопонимание. Я писал про сделки совершенные мной лично и таблицу сделок в режиме их прихода. Когда их разом приходит много, бывают (не всегда) зависания по 2-3 секунды (окна и прочее у меня всегда одни и те же). Поэтому ваш тест не показателен, он про другое. Предполагаю, что Сергей описывал ситуацию зависания при приходе его личных сделок ("когда идёт много моих сделок, я ясно вижу торможение") , хотя конкретики мало дал. Отключать алгоритм Нейгла ему смысла нет. Его никто не отключает и у всех всё работает, значит, не в нём дело. Вы первый человек на моей памяти, который его отключал.
Предположу следующее. Зависит от того каким образом обрабатывать таблицы сделок и заявок. В моем случае в таблице заявок в конце теста было 200 000 строк, но я обрабатываю колбеки до появления соответствующих изменений в таблицах. Поэтому я не лезу в эти таблицы. Если туда ходить, то задержки существенно увеличиваются. ------------------- Кроме того, у меня нет sleep. Поэтому задержка на обработку любого колбека не более 0.1 ms. Это на порядки меньше чем задержка со sleep.
Вызвать regedit, перейти в ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\P arameters\Interfaces\ и далее зайти в подветку, где есть параметр DhcpIPAddress, который равен моему IP. Добавить/изменить 2 параметра (вначале их там нет): DWORD 32 бита TcpAckFrequency и TCPNoDelay со значением 1. Для его восстановления надо установить эти 2 параметра в 0. Для вступления в силу изменённых параметров надо перезагрузить ПК.
вроде все так. Этот алгоритм с давних времен отключают для игр по интернету. ----------------------- проверил ничего не виснет.
AlgoPack Mocex, FinRL China
Пользователь
Сообщений: Регистрация: 30.01.2015
22.04.2024 17:04:38
пардон, опечатка AlgoPack Moex, FinRL China
AlgoPack Mocex, FinRL China
Пользователь
Сообщений: Регистрация: 30.01.2015
22.04.2024 17:03:01
В 2023 году Мосбиржа запустила Algopack и выложила на Гитхаб библиотеку на python – moexAlgo,
которая должна упростить работу с AlgoPack API.
AlgoPack — это данные, сигналы и аналитика для алгоритмической торговли через API
Загружать большой набор исторических данных
Тестировать свои торговые гипотезы
Построить алгоритмическую торговлю
В рамках интерфейса доступны следующие типы информации: статические данные о рынках (режимы торгов и их группы, финансовые инструменты и их описание), данные для построения графиков ("свечей"), сделки (анонимно), котировки, исторические данные, различные метаданные.
Аналогично продукту MOEX Trade INFO, который также работает через ИСС,
данные могут предоставляться или по подписке в режиме реального времени или в свободном доступе (без авторизации, но с задержкой).
Взаимодействие с сервером осуществляется по протоколу http.
На питоне работает. свечи: period_map = {'1m': 60, '10m': 600, '1h': 3600, '1D': 86400, '1W': 604800, '1M': 2678400, '1Q': 8035200} ---------------------- Использую для создания истории для ИИ на основе FinRL: Библиотека глубокого обучения с подкреплением для автоматизированной торговли акциями
на питоне работает. версия питона не выше 3.10 выше тоже можно, но сложнее. работаю на 3.12.
Почему в этой программке утекает память??
Пользователь
Сообщений: Регистрация: 30.01.2015
22.04.2024 07:20:49
, Я отключал этот алгоритм даже на одноядерной машине.
написал: Возможно Вы знаете, но причина тормозов при отправке заявки может быть из-за алгоритма Нэгла.
Я попробовал его отключить, но Квик начал очень сильно тормозить, занятость ЦП 82%, только и делал, что крутил бублик вместо курсора мыши, я не смог ничего сделать. Поэтому отключение этого алгоритма не для этого 2-ядерного ПК. Попробую на другом ПК.
Если правильно отключаете, то этого быть не может даже теоретически. алгоритм не связан с числом ядер. Он просто не отсылает Ваши пакеты в интернет пока они не станут большими или не пройдет достаточно много времени. Если Вы ничего не посылаете, то нет никакой разницы включен он или нет.
написал: Это не очень нормальное поведение. У меня бывает до 1000 транзакций. Каких-то особых "зависаний" не наблюдается.
Цитата
написал: В результате 4 часового теста было выставлено и снято более 200 тысяч заявок (это 400 тысяч транзакций) по 200 инструментам. Никаких тормозов я не заметил.
Как я понял, он про сделки писал, а не про транзакции. На транзакциях у меня тоже не наблюдается задержек, а когда много сделок приходит разом, бывает что бублик 2-3 секунды крутится, особенно, если в этот момент пытаешься в Квике что-то делать. При этом в лог всё в нормальное время пишется без особых задержек, так что я не думаю, что здесь проблема из-за интернета. Для процессора на 4ГГц будет задержка в 1-1,5 секунды в подобной ситуации и на неё внимание просто не обращают. Прямая зависимость времени зависания от количества поступивших на обработку записей в таблицу сделок и частоты процессора. Сергей не написал какое количество записей в таблицу сделок пришло, какой у него проц по частоте и сколько зависание в секундах длилось, а так по его описанию у меня тоже бывают такие моменты, но 2-3 секунды это не проблема, конечно.
В моем тесте использовался колбек опParam , а это и есть сообщения, которые отображаются в ТТП. Там не только сделки, но и любые изменения по инструменту. Тест выставлял заявки по инструменту, по которому совершена сделка. Снимал заявку, когда она зарегистрирована сервером, т е выставлена в стакан. Тормоз 2-3 секунды наблюдается в КВИКЕ, если много окон и других приложений открыто. Я такое наблюдал давно на одноядерном компе по XP. ------------------ Можно увидеть это вечером, когда мало сделок или на неликвиде.. --------------- Но что конкретно происходит без логов сказать точно невозможно.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
Пользователь
Сообщений: Регистрация: 30.01.2015
22.04.2024 07:08:56
Цитата
VPM написал: , Легкий поток в Lua - это сопрограмма, которая может быть приостановлена и возобновлена независимо от основного потока приложения. Это позволяет выполнять код асинхронно, не блокируя основной поток. Легкие потоки являются более легкими и эффективными, чем потоки операционной системы, что делает их подходящими для приложений с большим количеством одновременных задач. Именно этот подход я и хочу обсудить, применительно к нашей прикладной задачи. Отслеживать события способом сопрограмм с обратным вызовом, ну к примере как Вы предлагали сделать общею таблицу событий и ее обрабатывать, удобней наверно даже в виде класса, что можно было масштабироваться и забыть про эту проблематику.
По-моему мнению, Вы ошибаетесь. Если железо одноядерное, то последовательное выполнение - это есть блокирование . При сопрограммах у вас основной поток луа останавливается. иначе это будет параллельное исполнение. Я говорил выше, что сопрограммы это всего диль отдельный стек для луа машины. т е не надо сохранять содержимое основного стека , так как отельный стек не занимается основным потоком. При работе с сопрограммами делается просто переход на другой стек вместо его сохранения и восстановления. Это позволяет прерывать исполнение функций в лбом месте и продолжат их исполнения с этого места. Это все. Но все это последовательно с остановкой всех , кроме одного.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
Пользователь
Сообщений: Регистрация: 30.01.2015
22.04.2024 07:00:23
Цитата
VPM написал: , Ну о какой Вы последовательности исполнения говорите, событие или пришло в основную последовательность, забрав на себя исполнение, и сломав последовательность, или не пришло и все исполняется последовательно. На минутку подставим что у нас не одно событие, а отслеживаем несколько? И каждое выскакивает когда вздумается. Похоже нужно дать определения. Но ведь у нас не абстрактные рассуждения мы говорим о луа (а это значить по умолчанию один поток). последовательность исполнения в котором постоянно ломают сопрограммы.
Не соглашусь с Вами. Обычно механизм прерываний по одной из двух схем. 1) Для событий делается очередь. События обрабатываются из очереди. пришло новое , встало в очередь. Если у событий есть приоритет, то оно может прервать выполняемое событие, если оно ниже по приоритету. 2) Пришло событие. Оно блокирует прием новых событий до исполнения этого. ---------------- Обе схемы обеспечивают последовательное выполнение событий. ---------------- Я говорю не абстрактно. Именно так реализуется обработка событий на уровне железа и OC. --------------------- Кораунды это яля потоки на уровне виртуальной машины. Бесспорно, так как железное ядро одно, то все работает последовательно. ----------------------- Если софт написан правильно, то ничего никто не ломает.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
Пользователь
Сообщений: Регистрация: 30.01.2015
20.04.2024 18:32:22
Мое понимание сопрограмм такое: ------------------------- Сопрограмма это VMLua, для которой выделен локальный стек в области памяти основной VMLua. ---------------------------- Поэтому у сопрограммы и основной программы общие глобальные переменные и функции. ------------------------- Запуск скрипта как сопрограммы позволяет останавливать выполнение скрипта сопрограммы и не портить локальные параметры функции,которая вызвана как сопрограмма, так как у каждой сопрогаммы свой стек VMLua. ---------------------- Если функцию вызвать без создания сопрограммы, то другая функция может быть запущена лишь по завершению этой, так как они исполняются в одном стеке ---------------------------- Использование сопрограмм не приводит к параллельному вычислению, а лишь позволяет последовательно исполнять функции по частям. -------------------------- В QUIK сопрограмма запущена в отдельном потоке и называется main.
И ещё я вижу торможение, когда окно "Доступные скрипты" располагаю поверх стаканов. В этом случае хорошо видно, что циферки занятости памяти напротив скрипта перерисовываются не мгновенно. Хотя, GPU в диспетчере тоже простаивает, как и CPU. Поэтому я не знаю, как объяснить это торможение. Если перенести это окно на фоновую область окна Квика, то циферки рисуются мгновенно.
Перед началом работы я в диспетчере задач на всякий случай ставлю процессу info.exe высокий приоритет. Но каких-то изменений в связи с этим я не заметил.
Сказать, что конкретно у Вас тормозит не делая лог файлы не реально. ------------------ Могу лишь рассказать результаты моих тестов, которые указывают на то, что КВИК может работать очень быстро. Я выкладывал результаты КРАШ теста, который делал на демо сервере. В тесте я принимал инструменты по колбеку onParam и выставлял на принятый инструмент заявку на покупку в очередь, После подтверждения регистрации заявки на сервере, я отменял ее. В результате 4 часового теста было выставлено и снято более 200 тысяч заявок (это 400 тысяч транзакций) по 200 инструментам. Никаких тормозов я не заметил. Терминал тратил на отправку очередной транзакции не более 0.1 ms. ----------------- После этого теста получил предупреждение от разработчиков, чтобы больше так не грузил их сервер. ------------------------ Поэтому полагаю у Вас может быть либо проблема с Вашим скриптом, либо с Вашим брокером. Сделайте вывод в лог файл в колбеке и в main и сделайте анализ задержек.
339 сделок по одному тикеру в течение 1 мкс
Пользователь
Сообщений: Регистрация: 30.01.2015
19.04.2024 08:26:34
этот механизм брокеры активно использовали раньше для ухода от налогов
написал: Ну например, может оно как-то использует оконные сообщения.
Сомнительно: не видно логики для неработоспособности этой функции в консольных программах. И в документации на сайте МС нет такого предупреждения... Аналогично для более современной функции PlaySound. Как тогда МС вообще планирует использование звука в консольных программах??
Вроде все работает. Попробуйте сделать такую функцию в dll и добавьте sF в таблицу luaL_Reg В данном примере это luaL_Reg nks[]
написал: вот пример сделок по одной цене и время все в пределах 200000 мкс и таких много:
И что? Долбят по мелочи заявку маркетмейкера на миллиард. А потом маркетмейкер решил подвинуться на один пункт и сгреб всех разом...
Время сделки должно совпадать со временем регистрации заявки, вызвавшей эту сделку. Иначе будут вопросы: "Почему по моей заявке сделка прошла по более высокой цене, хотя последняя сделка по низкой цене была на пять микросекунд позже, чем зарегистрирована моя заявка?"
Не соглашусь с Вами. По-моему, маркет мейкер не выставляет очень большие пакеты. ----------------- Я предположил что это сделка РЕПО. ММ эти сделки не делает. РЕПО - это передача акций в долг. Эти сделки делают проф участники между собой.
Нет, ядра у Вас не сильно заняты. Вы можете это увидеть в диспетчере задач. -------------------- У Вас в main используется sleep(1000) т е Вы останавливаете поток Main на 1 секунду. В винде квант, который выделяется задаче составляет 15 ms. У Вас VMLua в потоке работает 1 квант из 60, т е примерно 2% доступного времени.
Почему в этой программке утекает память??
Пользователь
Сообщений: Регистрация: 30.01.2015
18.04.2024 12:34:53
, Чтобы не гонять постоянно сборщик, я создаю таблицы требуемого размера изначально и потом не уничтожаю их. В результате сборщику просто нечего делать.
сборщик мусора в настоящее время используется во многих языках. И основное отличие - алгоритм самой сборки и определение момента сборки. Если кратко, то в луа сборщик контролирует скорость выделение памяти и ее увеличение и в зависимости от этого начинает утилизацию. У вас память растет медленно и мало. Нет смысла запускать сборщик, так как он будет тормозить VMLua. Если памяти на компе достаточно, то его даже вообще отключают. Вы можете поиграть с настройками и подобрать нужный для вас режим сборки.
339 сделок по одному тикеру в течение 1 мкс
Пользователь
Сообщений: Регистрация: 30.01.2015
18.04.2024 12:22:21
и еще... одинаковое время какое-то подозрительное: ...000877
написал: В файлике a1.txt видно, что два рекорда по числу сделок с неизменным временем были не на аукционе открытия. А почему время сделок не меняется, можно только предполагать, а может кто-то, кто сидит ближе к мосбирже, спросит у неё: как объясняется этот феномен?
Я уже предлагал объяснение:
Цитата
Да элементарно. 339 разных заявок в стакане кто-то собрал одной крупной встречной заявкой.
Это же lqdt? Там цена почти не меняется, куча разных заявок стоит в стакане по одной цене. Старый анекдот: Скрытый текст В автобусе: -А вы выходите на следующей? -Да, выхожу. -А люди, которые перед вами, тоже выходят? -Да. Но они об этом еще не знают... Не важно, с какой скоростью сервер обрабатывает транзакции. Все сделки произошли в тот момент, когда прилетела крупная встречная заявка. Но сервер об этом еще не знает - он не успел всё обработать...
Я бы согласился с этой версией, если бы она повторялась. Но такого нет. Да и быть не должно для разных заявок, так как время регистрации заявки - это юридический факт и регистрироваться она должна не в момент прилета большой заявки, а в момент их встречи. Т е если встречные заявки в очереди, то сделки регистрируются последовательно. Ранее давал ссылку на статью, где представитель биржи хвалился что им удалось реализовать 8 сделок в мкс на уровне ядра. В данном случае 339 сделок, т е в 40 раз быстрее. что быть не может для разных биржевых заявок. Объяснить это могу лишь адресной сделкой(заявкой) В ней время сделки будет одно и тоже. вот пример сделок по одной цене и время все в пределах 200000 мкс и таких много:
Код
10:22:39.461441 1.3797 350 B
10:22:39.463233 1.3797 20 B
10:22:39.465084 1.3797 320 B
10:22:39.467713 1.3797 9540 B
10:22:39.469318 1.3797 1 B
10:22:39.470061 1.3797 10 B
10:22:39.472512 1.3797 10 B
10:22:39.474243 1.3797 420 B
10:22:39.486819 1.3797 340 B
10:22:39.508194 1.3797 60 B
10:22:39.513099 1.3797 350 B
10:22:39.515203 1.3797 320 B
10:22:39.516766 1.3797 9540 B
10:22:39.519155 1.3797 10 B
10:22:39.520698 1.3797 20 B
10:22:39.525620 1.3797 10 B
10:22:39.527351 1.3797 420 B
10:22:39.530555 1.3797 340 B
10:22:39.569123 1.3797 60 B
10:22:39.572256 1.3797 350 B
10:22:39.574998 1.3797 10 B
10:22:39.576334 1.3797 20 B
10:22:39.579190 1.3797 10 B
10:22:39.580370 1.3797 420 B
10:22:39.582377 1.3797 270 B
10:22:39.584148 1.3797 9540 B
10:22:39.585802 1.3797 340 B
10:22:39.609057 1.3797 3490 B
10:22:39.614191 1.3797 30 B
10:22:39.619099 1.3797 60 B
10:22:39.625574 1.3797 350 B
10:22:39.628100 1.3797 10 B
10:22:39.629686 1.3797 350 B
10:22:39.638879 1.3797 20 B
10:22:39.645045 1.3797 10 B
10:22:39.646747 1.3797 420 B
10:22:39.648311 1.3797 9540 B
10:22:39.650056 1.3797 340 B
Почему в этой программке утекает память??
Пользователь
Сообщений: Регистрация: 30.01.2015
18.04.2024 08:13:24
Цитата
Serge123 написал: С каждой записью в файл утекает ~ 50 байтов памяти, а почему она не собирается сборщиком мусора??
Код
попробуйте так:
Код
function main ()
for i = 1 , 20 do toFile() sleep ( 1000 ) end
collectgarbage("collect")
end
не хватает только теста под реальной нагрузкой для учёта эффекта синхронизаций
Пока не придумал. Есть варианты алгоритма теста?
До каких пор живёт таблица, передаваемая функции?
Пользователь
Сообщений: Регистрация: 30.01.2015
17.04.2024 15:55:00
, Придумал лишь одно объяснение Вашему примеру, где не изменяются ни время ни цена. Это возможно в режиме договорной сделки. Когда через биржу один крупный игрок продает конкретно другому игроку большой объем, например, сделка РЕПО. Но это лишь мое предположение. ------------------
До каких пор живёт таблица, передаваемая функции?
Пользователь
Сообщений: Регистрация: 30.01.2015
17.04.2024 15:51:07
Цитата
funduk написал: , ну вот да, поэтому у меня и вопрос, что больше тормозит главный поток квика -- вызов qlua функций из колбэков или из main с синхронизацией. Если число таких вызовов одинаково (что бывает, если main обрабатывает данные быстрее, чем они поступают), должно получиться, что тормозить больше будут вызовы из main, потому что число синхронизаций вырастет. Если же main не успевает за колбэками, и можно не все данные колбэков обрабатывать, то вызов qlua в main может быть быстрее, чем в колбэках, просто потому, что вызовов будет меньше, но накладные расходы на синхронизацию могут всё равно свести преимущество на нет. Поэтому и вопрос был, есть ли у Вас тест на это.
Рассмотрим два варианта В первом колбек читает стаканы и помещаются в очередь их вместе с clas и sec. main читает стаканы из очереди, при этом main еще читает из очереди clas и sec. -------------------- Во втором колбек помещает в очередь clas и sec main читает clas и sec и если надо, то читает стаканы. --------------------- Полагаю, что второй вариант бесспорно лучше. Второй вариант будет еще в разы лучше, если вместо sleep использовать event. -------------------- что не так?
До каких пор живёт таблица, передаваемая функции?
Пользователь
Сообщений: Регистрация: 30.01.2015
17.04.2024 13:01:49
, Относительно очистки памяти при выходе из функции или удалении таблицы, ----------------- Сборщик мусора работает по определенному алгоритму у которого есть настраиваемые параметры. ------------------- Чтобы увидеть уменьшение занятой памяти надо запустить сборщик принудительно. пример:
Код
local M=10000000
local t={}
count1 = collectgarbage("count") print("объем занятой памяти",count1//1);
for i=1, M do t[i]=i end
count1 = collectgarbage("count") print("объем занятой памяти массивом",count1//1);
t=nil -- удаляем массив
count1 = collectgarbage("count") print("объем занятой памяти после удаления массива ",count1//1);
collectgarbage("collect") count1 = collectgarbage("count") print("объем занятой памяти после сборщика массива ",count1//1);
os.exit()
результат:
Код
>D:/lua53/lua53.exe -e "io.stdout:setvbuf 'no'" "Test.lua"
объем занятой памяти 58.0
объем занятой памяти массивом 262202.0
объем занятой памяти после удаления массива 262199.0
объем занятой памяти после сборщика массива 50.0
>Exit code: 0
До каких пор живёт таблица, передаваемая функции?
Пользователь
Сообщений: Регистрация: 30.01.2015
17.04.2024 12:51:27
и еще... Я как-то выкладывал результаты теста, в котором видно, что колбеки тормозят main поток.
написал: getQuoteLevel2 лучше вызывать в main, чтобы не тормозить основной поток.
У Вас есть какой-нибудь скрипт, подтверждающий это?
Я когда дампил квик через procdump, постоянно видел, что вызовы qlua (типа SetEmptyCallback) из main стояли на входе в критическую секцию, а вот вызовы из главного потока - никогда.
Вес функции qlua в основном стеке. Основной стек в главном потоке. стек main - это дополнительный стек. колбеки блокируют доступ main к глобальному стеку. Поэтому вызов функций qlua в колбеках не требует дополнительной синхронизации. Ее уже сделали при вызове колбека
До каких пор живёт таблица, передаваемая функции?
Пользователь
Сообщений: Регистрация: 30.01.2015
17.04.2024 12:41:16
Цитата
Serge123 написал: Интересно: как можно проверить, что мой вариант скрипта, в котором я перенёс обработку стаканов и обезл. сделок в main, имеет смысл? Мне кажется, что добавилось лишней работы в потоке main с разбором очереди, а в потоке Квика работа уменьшилась неощутимо...
Вы правильно мыслите. Если хотите получить эффект, то надо убирать sleep и использовать event.
написал: getQuoteLevel2 лучше вызывать в main, чтобы не тормозить основной поток.
У Вас есть какой-нибудь скрипт, подтверждающий это?
Я когда дампил квик через procdump, постоянно видел, что вызовы qlua (типа SetEmptyCallback) из main стояли на входе в критическую секцию, а вот вызовы из главного потока - никогда.
Это написано в документации. Могу объяснить на коде почему это так. ----------------- Кроме того, если эта таблица создана глобально, то она будет всегда, если вы явно не присвоите ей nil. ------------------ Проверить можно на СИ. Могу рассказать как.
У Вас время 09:50:00 не содержит микросекунд. Это время Вашего компьютера, а не биржи. Говоря о сделках в 1 мкс Вы очевидно имели ввиду вот это:
Код
9:59:32.000877 1.3796 270 S
09:59:32.000877 1.3796 5 B
09:59:32.000877 1.3796 36 B
09:59:32.000877 1.3796 39689 B
09:59:32.000877 1.3796 11 B
09:59:32.000877 1.3796 5000 B
09:59:32.000877 1.3796 29076 S
09:59:32.000877 1.3796 1000 S
09:59:32.000877 1.3796 200 S
09:59:32.000877 1.3796 1325128 S
09:59:32.000877 1.3796 1 S
09:59:32.000877 1.3796 1 S
09:59:32.000877 1.3796 2 S
09:59:32.000877 1.3796 25500 S
09:59:32.000877 1.3796 65 S
09:59:32.000877 1.3796 5 B
09:59:32.000877 1.3796 243000 S
09:59:32.000877 1.3796 732 S
09:59:32.000877 1.3796 178 S
09:59:32.000877 1.3796 62 S
09:59:32.000877 1.3796 1000 S
09:59:32.000877 1.3796 210 S
09:59:32.000877 1.3796 3718 S
09:59:32.000877 1.3796 2 S
09:59:32.000877 1.3796 100 S
09:59:32.000877 1.3796 4 S
09:59:32.000877 1.3796 4063 S
09:59:32.000877 1.3796 5332 S
09:59:32.000877 1.3796 4 S
09:59:32.000877 1.3796 8 S
09:59:32.000877 1.3796 45 S
09:59:32.000877 1.3796 1700 S
09:59:32.000877 1.3796 382 S
09:59:32.000877 1.3796 86 S
09:59:32.000877 1.3796 100 S
09:59:32.000877 1.3796 803 S
09:59:32.000877 1.3796 10000 S
09:59:32.000877 1.3796 1 S
09:59:32.000877 1.3796 13000 S
09:59:32.000877 1.3796 395 S
09:59:32.000877 1.3796 100 S
09:59:32.000877 1.3796 4 S
09:59:32.000877 1.3796 71952 S
09:59:32.000877 1.3796 47 S
09:59:32.000877 1.3796 7 S
09:59:32.000877 1.3796 7 S
09:59:32.000877 1.3796 7 S
09:59:32.000877 1.3796 200 S
09:59:32.000877 1.3796 58 S
09:59:32.000877 1.3796 511 S
09:59:32.000877 1.3796 10 S
09:59:32.000877 1.3796 578 S
09:59:32.000877 1.3796 566 S
09:59:32.000877 1.3796 3000 S
09:59:32.000877 1.3796 39 S
09:59:32.000877 1.3796 1000 S
09:59:32.000877 1.3796 220 S
09:59:32.000877 1.3796 33 S
09:59:32.000877 1.3796 6 S
09:59:32.000877 1.3796 295 S
09:59:32.000877 1.3796 406 B
09:59:32.000877 1.3796 14 B
09:59:32.000877 1.3796 500 B
09:59:32.000877 1.3796 1036 B
09:59:32.000877 1.3796 2242 B
09:59:32.000877 1.3796 9900 B
09:59:32.000877 1.3796 200 B
09:59:32.000877 1.3796 5000 B
09:59:32.000877 1.3796 1000 B
09:59:32.000877 1.3796 21 B
09:59:32.000877 1.3796 65 B
09:59:32.000877 1.3796 330 B
09:59:32.000877 1.3796 55 S
09:59:32.000877 1.3796 20000 S
09:59:32.000877 1.3796 2 S
09:59:32.000877 1.3796 2 S
09:59:32.000877 1.3796 1244960 S
09:59:32.000877 1.3796 100000 S
09:59:32.000877 1.3796 30000 S
09:59:32.000877 1.3796 1000 S
09:59:32.000877 1.3796 26756 S
09:59:32.000877 1.3796 7000 S
09:59:32.000877 1.3796 1004 S
09:59:32.000877 1.3796 9000 S
09:59:32.000877 1.3796 2233 S
09:59:32.000877 1.3796 10500 S
09:59:32.000877 1.3796 1400 S
09:59:32.000877 1.3796 1000 S
09:59:32.000877 1.3796 150 S
09:59:32.000877 1.3796 59 S
09:59:32.000877 1.3796 1 S
09:59:32.000877 1.3796 13 S
09:59:32.000877 1.3796 145000 S
09:59:32.000877 1.3796 5000 S
09:59:32.000877 1.3796 1360 S
09:59:32.000877 1.3796 2101 S
09:59:32.000877 1.3796 15 S
09:59:32.000877 1.3796 1 S
09:59:32.000877 1.3796 11378 S
09:59:32.000877 1.3796 139 S
09:59:32.000877 1.3796 20 S
09:59:32.000877 1.3796 2000 S
09:59:32.000877 1.3796 15135 S
09:59:32.000877 1.3796 110000 S
09:59:32.000877 1.3796 73 S
09:59:32.000877 1.3796 1 S
09:59:32.000877 1.3796 8000 S
09:59:32.000877 1.3796 1000 S
09:59:32.000877 1.3796 1670 S
09:59:32.000877 1.3796 5000 S
09:59:32.000877 1.3796 20000 S
09:59:32.000877 1.3796 100 S
09:59:32.000877 1.3796 33000 S
09:59:32.000877 1.3796 1000 S
09:59:32.000877 1.3796 12046 S
09:59:32.000877 1.3796 10000 S
09:59:32.000877 1.3796 5000 S
09:59:32.000877 1.3796 10200 S
09:59:32.000877 1.3796 1000 S
09:59:32.000877 1.3796 9510 S
09:59:32.000877 1.3796 1000 S
09:59:32.000877 1.3796 6000 S
09:59:32.000877 1.3796 160000 S
09:59:32.000877 1.3796 1000 S
09:59:32.000877 1.3796 100 S
09:59:32.000877 1.3796 700 S
09:59:32.000877 1.3796 241000 S
09:59:32.000877 1.3796 10320 S
09:59:32.000877 1.3796 87950 S
09:59:32.000877 1.3796 251344 S
09:59:32.000877 1.3796 2 S
09:59:32.000877 1.3796 2 S
09:59:32.000877 1.3796 2 S
09:59:32.000877 1.3796 615250 S
09:59:32.000877 1.3796 7000 S
09:59:32.000877 1.3796 362845 S
09:59:32.000877 1.3796 168328 S
09:59:32.000877 1.3796 100000 S
09:59:32.000877 1.3796 14873 S
09:59:32.000877 1.3796 493469 S
09:59:32.000877 1.3796 25000 S
09:59:32.000877 1.3796 1200000 S
09:59:32.000877 1.3796 1407296 S
09:59:32.000877 1.3796 181423 S
Обратите внимание, что не изменяются в этих записях время и цена. Т е это не исполнение одной большой заявки по рынку, а продажи большому покупателю, который выставил большой пакет на покупку по фиксированной цене и его обгрызают продавцы. Т е в него стукаются прилетающие заявки. Так делают HFT роботы, но они не могут прилететь все за 1 мкс. Что-то тут не так со временем.
До каких пор живёт таблица, передаваемая функции?
Пользователь
Сообщений: Регистрация: 30.01.2015
16.04.2024 08:50:45
getQuoteLevel2 лучше вызывать в main, чтобы не тормозить основной поток.
До каких пор живёт таблица, передаваемая функции?
Пользователь
Сообщений: Регистрация: 30.01.2015
16.04.2024 08:45:33
Цитата
Serge123 написал: Смутно помнится, в документации на lua.org я видел, что жизнь таблицы из параметров функции гарантируется до выхода из этой функции (т.е. до выхода из OnAllTrade). Какая-то ерунда пока получается с этим переносом обработки таблиц в поток main...
Жизнь локальных параметров прекращается с выходом из функции. А таблица, которую Вы передали через фактические параметры в функцию создана вне этой функции. поэтому она будет утилизирована лишь когда на нее не будет ссылок вообще. Когда вы ее указатель помещаете в очередь, а очередь существует вне функции, то таблица живет своей жизнью и дальше.
написал: Сервер не может провести 339 заявок за 1 мкс.
В 1-м моём сообщении речь шла о сделках. Ошибочно сделки перетекли в заявки...
Суть ответа не меняется. Вы прочитали статьи? Там есть ответ на Ваш вопрос. Поясняю: В вашем вопросе 339 сделок совершено за 1 мкс. Это значит 339 миллионов сделок в секунду . ------------------------- в статье сказано: "8 млн в сек – это внутренняя производительность алгоритма на ядре системы. 50 тыс. – это поток, образуемый клиентской нагрузкой в реальной инфраструктуре – с полным набором компонентов/серверов, резервированием, репликацией, сетевыми устройствами." ------------------------ Т е Ваши 339 это в 40 раз быстрее, чем реально достигнуто на уровне ядра системы на бирже При этом, в системе на момент совершения первой сделки все заявки должны быть уже в очереди(стакане) в оперативной памяти сервера. --------------------
написал: 339 разных заявок в стакане кто-то собрал одной крупной встречной заявкой.
А, ясно, почему такая высокая скорость. А если бы мелкие заявки собирали мелкими, то сервер не успел бы за 1 мкс провести все 339 сделок и образовалась бы очередь?
Сервер не может провести 339 заявок за 1 мкс. это почти миллиард транзакций в секунду. ------------------------ Скорее всего Вы что-то не так поняли. Поэтому и предлагал Вам показать. --------------------- Например, сервер QUIK делает примерно 1000 транзакций в секунду. ---------------------- Делал тест сервера на 4 ядрах. Получил 50 000 транзакций в секунду. -------------------- Сомневаюсь, что на бирже сервер в миллион раз быстрее. --------------------- В вашем случае, сервер биржи должен иметь десятки тысяч ядер .
Альтернатива CanSell/CanBuy
Пользователь
Сообщений: Регистрация: 30.01.2015
13.04.2024 12:07:02
Цитата
Cyber написал: У трех брокеров всегда использовал getBuySellInfo(FIRM_ID,CLIENT_CODE,CLASS_CODE,SEC_CODE,price).can_sell для подсчета возможной позы. И там где не давали шортить can_sell = 0 выдавал. Но тут у БКС выяснилось, что эти значения не соответствуют реальности, и шортить не дают бумаги у которых can_sell не равон нулю. Есть ли в квике какая-то другая таблица с реальными значениями? Откуда еще можно узнать доступную позу?
Запретить шорт по конкретным инструментам и конкретным клиентам - это право брокера . Спросите у брокера список инструментов, которые доступны Вам в шорт.
339 сделок по одному тикеру в течение 1 мкс
Пользователь
Сообщений: Регистрация: 30.01.2015
13.04.2024 12:02:22
Цитата
Serge123 написал: Сегодня наблюдал сабж по некоторой акции на мосбирже с пом. моего скрипта с OnAllTrade. При этом время сделки было то же самое по самую микросекунду. Это произошло сразу после смены цен покупки/продажи. Как такое возможно? Действительно ли эти 339 сделок произошли менее, чем за 1 мкс?
Можно ли где-то получить общее представление о том, как организованы торги на мосбирже и какие там характеристики у серверов (какая ОС, память, ЦП, диски, пропускной канал, ...)? Т.е. как бы совершить виртуальный тур по бирже. Примерно, как в видео на ютюбе о работе tsmc, где клепают лучшие ЦП.
Можете показать фрагмент этих сделок?
Утечка памяти в обработчике SetTableNotificationCallback, Функция обратного вызова обработчика событий пользовательской таблицы не освобождает память между вызовами
Пользователь
Сообщений: Регистрация: 30.01.2015
13.04.2024 11:56:01
Цитата
БорисД написал: Николз может все таки ответишь в этой теме на вопросы заданные тебе ?
А то мы все много раз читали в твоих сообщениях что ты доктор технических наук а каких именно даже в догадках не можем предположить . И про созданный тобой в 1975 году и в одиночку ИИ ( над которым по прежнему бьются все компании программистов мирового уровня ) признайся что это были твои враки , ну типа переборщил ты в самовосхвалении . Иначе дай нам посмотреть на этот твой ИИ от 1975 года выпуска.
Мое сообщение было направлено конкретному человеку. --------------------- Удовлетворять больное любопытство хамов нет желания.
