Добрый день, Ищу решение следующей проблемы. ---------------- Сейчас у меня реализовано так: -------------------- В функции main для каждого инструмента запускается свой поток. Потоки берутся из пула. Если свободного нет, то создается новый. ------------------ Данные передаются в поток через параметры скрипта и мапинг-файлы. ------------------ Прием данных от источника и стаканов реализуется в main. ----------------- Все работает замечательно. Но узким местом является прием данных всех инструментов в одном потоке main. ----------------------- Хочу принимать данные и стаканы в отдельном потоке каждого инструментов. ------------------ Применение общего глобального стека не дает результата. ---------------------- Если кто-то решил данную проблему, просьба сказать каким методом. ------------ Спасибо ================= Отдельная пожелание разработчикам. Реализовать указанные функции для приема данных и стаканов для произвольного потока.
Пользователь
Сообщений: Регистрация: 02.02.2015
миру мир!
09.05.2022 08:27:07
Цитата
В функции main для каждого инструмента запускается свой поток. Потоки берутся из пула.
Без иллюстрации кодом вот этого момента, сказать что-то предметное - невозможно. Ибо не понятно чем ваши потоки (где не работает) отличаются от потока main (где работает).
В функции main для каждого инструмента запускается свой поток. Потоки берутся из пула.
Без иллюстрации кодом вот этого момента, сказать что-то предметное - невозможно. Ибо не понятно чем ваши потоки (где не работает) отличаются от потока main (где работает).
У меня в потоках запускаются скрипты, но в них нет библиотеки QLUA. Как ее туда включит пока не разобрался. --------------------- Относительно main. Возможно ошибаюсь, Но как я понял, в main и основной программе скрипта используется общий глобальный стек. Делал так, и вроде бы работает получение данных, но неустойчиво. =============== В настоящее время я принимаю данные для всех инструментов в main. ---------- А в скриптах других потоков использую матрицу данных, которая реализована через мапинг. Через эту матрицу все скрипты получают доступ к любым данным любого потока. При этом нет дублирования данных, но могу работать с векторами данных до 2 миллиардов элементов и таким же числом векторов. -------------------- Так как реализую принцип - один пишет - все читают, то никакой синхронизации не требуется , так как нет конфликтов потоков. -------------------- Синхронизацию требуется между колбеком, main и вызовом потока для конкретного инструмента. ----------------------- Так как возможна ситуация, когда в очереди уже есть инструмент, либо для этого инструмента уже запущен поток. -------------- Тут я использую синхронизацию колбека и майн через системный event, а синхронизацию потока и очереди через атомарные операции. ----------------- Все работает просто замечательно. =============== Провел тест максимального числа потоков,. В результате получилось, что в пуле было открыто 11 потоков. ------------------ Причем первый поток запускался 23 тысячи раз, а одиннадцатый - 2 раза. ------------------ Потоки и прием данных активировались по колбеку onParam по 200 инструментам на тестовом сервере. -------------------- Время вызова колбека составляло в основном 10 мкс. ----------------------- Понятно, что данные на самом деле приходили пакетом и в данном случае это время реакции на очередную запись в пакете данных. ================ В итоге, пока не получилось разнести прием данных по различным потокам, чтобы работало устойчиво. ------------------ Причину не знаю. ------------------------- Если что-то подскажите, буду признателен.
Пользователь
Сообщений: Регистрация: 25.09.2020
09.05.2022 17:08:37
nikolz, Лапуль, подсказываю: 1. Слово "подскажите" в данном случае нужно писать через "е". 2. Потоки - понятие алгоритмическое, они могут быть организованы в любом количестве, но, как правило, в этом нет никакой необходимости: они являются главным источником тормозов и глюков. Идиотизм нынешней реализации QUIK как раз в том, что юзерам (по определению малоквалифицированным) подсунули ДВА потока, да ещё и подали этот маразм как крутое решение. То же самое со стеками: в моих программах не раз встречалось несколько стеков (максимально 5 или 6 - уже не помню), но это только для ОЧЕНЬ специфических задач! Для такой же примитивной задачи, как организация торговли, у меня изначально не было НИ ОДНОГО стека. А сейчас их целых ТРИ, и все до единого созданы лишь с целью борьбы с последствиями работы банды полуграмотных придурков, сварганивших ТАКОЙ программный интерфейс. Лапуль, дружеский совет: перестаньте заниматься хернёй, забудьте, как страшный сон всякие вумные словечки, вроде "вектора", "потоки", "пакеты", "мьютексы" и прочую белиберду - пишите в ОДНОМ потоке. И будет Вам ЩАСТЬЕ! Вот слова "синхронизация", к сожалению, забыть не получается, поскольку у этих дебилов всё-таки ДВА потока. Впрочем, я давно понял, что Ваша задача не написать нормальный скрипт, а изображать из себя крутого программера. Плохо получается, лапуль. Позорно плохо!
Пользователь
Сообщений: Регистрация: 30.05.2020
10.05.2022 10:09:43
Цитата
nikolz написал: Прием данных от источника и стаканов реализуется в main. ----------------- Все работает замечательно. Но узким местом является прием данных всех инструментов в одном потоке main. ----------------------- Хочу принимать данные и стаканы в отдельном потоке каждого инструментов.
А разве приём данных идёт не через основной поток? Хоть тысячу отдельных потоков сделай, они все встанут в очередь при обращении к хранилищу. Или вы располагаете другой информацией?
написал: Прием данных от источника и стаканов реализуется в main. ----------------- Все работает замечательно. Но узким местом является прием данных всех инструментов в одном потоке main. ----------------------- Хочу принимать данные и стаканы в отдельном потоке каждого инструментов.
А разве приём данных идёт не через основной поток? Хоть тысячу отдельных потоков сделай, они все встанут в очередь при обращении к хранилищу. Или вы располагаете другой информацией?
Как сделали разработчики, знают лишь они. --------------- Могу предположить, что есть как минимум два слоя приема данных. ----------------------- Первый - это прием по каналу связи данных с сервера и запись их в архив терминала. ------------------------- Возможно, что на этом этапе мы можем данные получать через колбек источника. --------------------- Второй - это чтение уже принятых данных из хранилища терминала - это делают функции O,H,L,C,V,T. ================= Для многопоточного получения этих данных важным фактом является то, что нам не надо писать эти данные в архив. --------------------------- Так как в потоках мы лишь читаем из архива уже размещенные там банные , то никакой синхронизации потоков нам не требуется. ------------------- Т е в данном случае потоки работают по принципу один пишет - остальные читают. ============== Поэтому прием данных лишь в основном потоке реализуется в худшем случае лишь в первом слое. ================= Я не использую колбек источника данных для приема , поэтому предполагаю возможность одновременно ходить в архив любому количеству потоков.
Пользователь
Сообщений: Регистрация: 30.05.2020
10.05.2022 13:21:28
Наверное, это можно проверить опытным путём.
Если обращение к хранилищу данных реализовано через одну дверь - основной поток, - то все остальные потоки, сколько бы их не было запущено, выстроятся в одну очередь у входа в дверь. И при запуске нескольких скриптов, "одновременно" запрашивающих, например, данные стаканов мы не увидим сколько-нибудь существенного ускорения по сравнению с одним скриптом, запрашивающим по очереди такое же количество стаканов. Проверим:
Код
function main()
local t = os.clock()
for _ = 1, 100000 do
getQuoteLevel2(class, sec)
end
message(tostring(os.clock() - t))
end
Проведём несколько тестов с 1-м, 2-мя, 3-мя, 4-мя одновременно запущенными скриптами.
Результаты: 1 скрипт: 6.5 сек 2 скрипта: по 15.2 сек каждый 3 скрипта: по 23.1 сек каждый 4 скрипта: по 30.4 сек каждый
При этом, во всех случаях было загружено только одно ядро процессора, что как бы намекает на использование только одного потока для доступа к данным.
Пользователь
Сообщений: Регистрация: 25.09.2020
10.05.2022 13:49:36
Незнайка, Несколько потоков и несколько скриптов - разные вещи: скрипт - это процесс, и он не обязательно однопоточный. Другое дело, что для торговли ни то, ни другое нафиг не нужно. Впрочем, не совсем так: мои три стека можно обозвать и "потоками", но все они сделаны не для упрощения кода (как раз наоборот) и не для ускорения обработки (они её замедляют), а исключительно для компенсации глюков системного софта Квика. Приходится буферизовать а) подачу заявок в Квик б) получение данных о сделках по прерываниям и в) обработку этих данных.
А так согласен: "Хоть тысячу отдельных потоков сделай, они все встанут в очередь при обращении к хранилищу".
Пользователь
Сообщений: Регистрация: 30.01.2015
14.05.2022 12:43:48
Цитата
Незнайка написал: Наверное, это можно проверить опытным путём.
Если обращение к хранилищу данных реализовано через одну дверь - основной поток, - то все остальные потоки, сколько бы их не было запущено, выстроятся в одну очередь у входа в дверь. И при запуске нескольких скриптов, "одновременно" запрашивающих, например, данные стаканов мы не увидим сколько-нибудь существенного ускорения по сравнению с одним скриптом, запрашивающим по очереди такое же количество стаканов. Проверим:
Код
function main ()
local t = os.clock ()
for _ = 1 , 100000 do
getQuoteLevel2 (class, sec)
end
message (tostring( os.clock () - t))
end
Проведём несколько тестов с 1-м, 2-мя, 3-мя, 4-мя одновременно запущенными скриптами.
Результаты: 1 скрипт: 6.5 сек 2 скрипта: по 15.2 сек каждый 3 скрипта: по 23.1 сек каждый 4 скрипта: по 30.4 сек каждый
При этом, во всех случаях было загружено только одно ядро процессора, что как бы намекает на использование только одного потока для доступа к данным.
Относительно приема с сервера данных в одном потоке я уже писал ранее и приводил тест аналогично вашему. ---------------------------- это связано с тем, что для реализации приема в майн используется общий глобальный стек луа - т е единственная область памяти и следовательно доступ к ней сделан с блокировкой. ================ Относительно приема данных в различных потоках есть разница в получении данных по свечам и по стаканам. -------------- История Стаканов очевидно не хранится в архиве, поэтому прием стакана выполняется в основном потоке и изменяет образ стакана в архиве. ---------------- Со свечами дело иначе. Закрытые свечи - это история и она накапливается в архиве. Прием же выполняется лишь по незакрытой свече. Поэтому чтение свечи из истории вполне допустимо в различных потоках одновременно. ------------------ Но чтобы это было возможно, надо реализовать в QLUA механизм работы с глобальным стеком Один пишет -все читают. А это очевидно разработчики делать не стали. Поэтому и не выходит каменная чаша. ============= Но даже в этом случае , прием в различных потоках пусть и последовательно позволяет ускорить вычисления по сравнению с приемом в одном потоке. ---------------- Приняв на грудь стакан, поток приступает к его обработке, а следующий поток примет свой стакан и начнет его обрабатывать параллельно с первым. ------------- Таким образом, даже в случае последовательного приема потоками стаканов, обработку их содержимого потоки будут делать параллельно . ------------------ Так как основное время умный робот тратит не на прием стаканов, а на анализ их содержимого и беседу с товарищами, которые тоже приняли по стакану, то прием даже по очереди стаканов актуален и перспективен.
Относительно приема данных в различных потоках есть разница в получении данных по свечам и по стаканам.
Ни малейшей! И то, и другое реализовано в Квике настолько безобразно, что пользоваться ни тем, ни другим просто нельзя - это глюки и тормоза, тормоза и глюки. А приём данных в разных потоках - это готовые ошибки синхронизации. А умный робот не тратит время ни на приём стаканов, ни на анализ их содержимого: работа со стаканом в принципе дурость, а ещё и в Квике это дурость в квадрате.
Прям заинтересовался: кому и на кой может понадобиться стакан? Полистал пяток первых попавшихся статеек на эту тему от тех, кто эту хрень рекламирует. В смысле, считает хоть как-то полезной. Имеем:
1. Обнаружение айсберг-заявок. Обсуждалось когда-то здесь. Выяснилось, что они нафиг не нужны, а обнаружить их в стакане можно лишь тогда, когда их подаёт очень тупой инвестор. Или, наоборот, очень умный, который хочет, чтобы его заявки были обнаружены. А спрятать айсберг от доморощенных аналитиков при желании проще простого.
2. Ух ты! "Сейчас биржевые стаканы считаются довольно устаревшей моделью анализа рынка и поэтому все меньше трейдеров ими пользуются". Дык я про то и говорю! Лично я этим говном не пользовался никогда. Разве что при ручной торговле, ещё до появления своего первого скрипта. И не для анализа, разумеется, а для совершения сделок. Ну да, тут и говорят про то, что всякие кукловоды доят лохов на фиктивных заявках и других "стаканных" разводках.
3. Собссно, больше в этих статьях ничего и не написано - так, ликбез, что такое стакан, бид, аск и прочая лабуда. Ха-ха-ха! "Вникать в анализ биржевого стакана полезно скальперам. Трейдерам на более длинных дистанциях следует ориентироваться на уровни поддержки/сопротивления и различные индикаторы". Детский сад!
4. О! "Кому нужен биржевой стакан цен". Вот я как раз и пытаюсь выяснить. Так кому же? Не, ну болтовня на тему "таблица предоставляет возможность отслеживать текущие сделки по ценной бумаге, оценивать настроения рынка и сформировать собственную линию поведения" меня не интересуют - кому и на кой? Увы, больше ничего, кроме блеяния на тему "внимание следует обращать на крупные лоты, а если у вас не крупные инвестиции, то достаточно аск и бид" или "необходимо применять комплексный подход". В общем, говно этот стакан. Как и "уровни поддержки/сопротивления и различные индикаторы". Как и многопоточность.
Относительно приема данных в различных потоках есть разница в получении данных по свечам и по стаканам.
Ни малейшей! И то, и другое реализовано в Квике настолько безобразно, что пользоваться ни тем, ни другим просто нельзя- это глюки и тормоза, тормоза и глюки. А приём данных в разных потоках - это готовые ошибки синхронизации. А умный робот не тратит время ни на приём стаканов, ни на анализ их содержимого: работа со стаканом в принципе дурость, а ещё и в Квике это дурость в квадрате. ------------------------------- В Квике гоняться за данными из стакана вообще то можно , но очень сложно . Так как уже сам Квик настолько глючный и хреновый софт что мало у кого получилось создать на основе данных из Квика свой собственный и прибыльный робот ..... по крайней мере на этом сайте никто не заявил об этом однозначно с предоставлением фактов подтверждающих это. А Умный робот при помощи этого глючного Квика это просто научная фантастика ( теоретически возможно а практически не выполнимо в ближайшие много лет , тем более что разработчикам и брокерам это совсем не нужно от слова "совсем " . Поэтому про умный робот на Луа и в Квике лучше даже не мечтать , не для трейдеров создавалась прога Квик и трейдерам она поэтому предоставляется бесплатно.
Прям заинтересовался: кому и на кой может понадобиться стакан? Полистал пяток первых попавшихся статеек на эту тему от тех, кто эту хрень рекламирует. В смысле, считает хоть как-то полезной. Имеем:
---------------------------------- Имеем или предполагаем ? Сначала предполагаем что актуальные решения трейдер может принимать всего лишь по нескольким аналитическим данным получаемым от биржи : ------------1- Анализ текущей таблицы сделок по инструменту ---------------2- Анализ графика цен по одному или нескольким выбранным тайфреймам ---------------3- Анализ биржевого стакана , и если его правильно вытащить то именно биржевой стакан способен дать информации больше чем предыдущие два пункта так как он показывает и аналитику на перспективу а не попытку анализировать то что уже произошло в первых двух пунктах и соответственно уже отправилось в историю данных по выбранному инструменту. Но в Квике биржевой стакан по инструментам и особенно активным - отследить полноценно не возможно . Поэтому для трейдеров использующих Квик остается фактически только попытки проанализировать и по ним принять решения на основе графиков и чуточку возможности это попробовать на основе Таблицы всех сделок по инструменту. А вот использовать все три пункта в Квике из за глюков и наводок ( например дубли сообщений по вашим сделкам и вашим выставленным заявкам ) ---------------4- монетка : по принципу Орел или Решка. Но этот пункт для принятия решений для выставления заявок как был так и останется угадайкой. Конечно в нем можно потыркаться и попробовать найти свой грааль при помощи использования стоп-заявок и тейк -профитных заявок . но все равно это будет из разряда : "подкинь монетку. " ------------------5- математические прогнозы - здесь тоже не все так просто потому что прогнозы были и всегда останутся прогнозами , ну это тоже самое как правильно угадать будующую погоду , и гарантированно это предсказать по прежнему не может даже гидрометеоцентр - чего уж нам пытаться сдесь ловить ? ------------------6- айсберг заявки и прочая лабуда типа арбитражной торговли на мой взгляд совсем не заслуживает внимания и попыток это изучать и использовать. Ни один серьёзный маркет мейкер или кукловод эти вещи не использует , и к тому же они несут дополнительную биржевую комиссию для тех кто их пытается применять. Тут уж лучше монетку подкидывать чем айсберги и арбиртражные заявки выставлять .
1. Обнаружение айсберг-заявок. Обсуждалось когда-то здесь. Выяснилось, что они нафиг не нужны, а обнаружить их в стакане можно лишь тогда, когда их подаёт очень тупой инвестор. Или, наоборот, очень умный, который хочет , чтобы его заявки были обнаружены. А спрятать айсберг от доморощенных аналитиков при желании проще простого.
2. Ух ты! "Сейчас биржевые стаканы считаются довольно устаревшей моделью анализа рынка и поэтому все меньше трейдеров ими пользуются". Дык я про то и говорю! Лично я этим говном не пользовался никогда. Разве что при ручной торговле, ещё до появления своего первого скрипта. И не для анализа, разумеется, а для совершения сделок. Ну да, тут и говорят про то, что всякие кукловоды доят лохов на фиктивных заявках и других "стаканных" разводках. ----------- доят в основном не на этом а немного на другом . В биржевой торговле самый главный фактор для принятия решений это психология , и вот на этм трейдеров и доят.
3. Собссно, больше в этих статьях ничего и не написано - так, ликбез, что такое стакан, бид, аск и прочая лабуда. Ха-ха-ха! "Вникать в анализ биржевого стакана полезно скальперам. Трейдерам на более длинных дистанциях следует ориентироваться на уровни поддержки/сопротивления и различные индикаторы". Детский сад!
4. О! "Кому нужен биржевой стакан цен". Вот я как раз и пытаюсь выяснить. Так кому же? -------- Мне он конечно нужен , но в Квике это бесполезно пытаться использовать. Не, ну болтовня на тему "таблица предоставляет возможность отслеживать текущие сделки по ценной бумаге, оценивать настроения рынка и сформировать собственную линию поведения" меня не интересуют - кому и на кой? Увы, больше ничего, кроме блеяния на тему "внимание следует обращать на крупные лоты, а если у вас не крупные инвестиции, то достаточно аск и бид" или "необходимо применять комплексный подход". В общем, говно этот стакан. Как и "уровни поддержки/сопротивления и различные индикаторы". Как и многопоточность. --------- опять таки это справедливо для Квика с его Луа , но не в глобальном плане.
Пользователь
Сообщений: Регистрация: 25.09.2020
15.05.2022 11:32:36
БорисД, Борь, у меня сегодня ночью всё легло в единую схему, абсолютно всё! И фондовый рынок, и срочный, и свечная торговля, и спредовая. Пока меня лучше не кантовать денёк-другой, я тебе подробно отпишу потом по мылу. Коротко по твоему сообщению:
1. В Квике гоняться за данными из стакана, строго говоря можно, но действительно очень сложно (особенно, если учитывать проблемы с синхронизацией), а самое главное - и не нужно: данные в стакане очень быстро меняются вблизи бид и аск, но там тупо нет времени на анализ стакана - те же данные в миллион раз быстрее можно получить из ТТТ. Остальные же данные стакана довольно статичны (даже для ручной торговли), но именно из-за удалённости от текущего состояния курса они тоже не нужны: здесь решения лучше принимать по свечам, а не по стакану, то есть стакан (даже без учёта его тормознутости и глюковатости) для принятия решений не нужен вообще. Свечами, получаемыми из Квика, тоже пользоваться нельзя - слишком ужасен софт для их получения, но мы с тобой, слава богу, знаем, что здесь нужно делать.
2. Умный робот на Луа и в Квике возможен. Не этот долбаный ИИ, конечно, а просто очень качественный, который заткнёт за пояс любого трейдера, торгующего руками.
3. Нет, "имеем" не значит "предполагаем", это значит "удалось выяснить из прочитанных статей".
4. Анализ текущей таблицы сделок по инструменту (если ты имеешь в виду таблицу обезличенных сделок) также неприменим из-за жутких тормозов и постоянного риска получать недостоверные данные. Графики скрипту не нужны, так что это только дополнительные тормоза. Но у нас есть свечи, а это лучше и надёжнее, чем любые графики и стаканы. Монетка хороша для высокочастотной торговли, поскольку там элемент случайности наиболее велик, но даже там есть информация, которая способна повысить вероятность принятия правильных решений.
5. Стоп-заявки и другие поручения брокеру совершить сделку хороши только для ручной торговли, чтобы не сидеть постоянно за монитором и портить глаза и жопу. Для скрипта использовать подобные технологии "просто неприлично", ведь он постоянно следит за рынком, а чем позже принимается решение, чем ближе оно к моменту совершения сделки, тем больше у нас информации для того, чтобы решение было правильным. Их использование может быть оправданным только если заявки ставятся достаточно далеко от спреда, на случай "а вдруг курс туда ломанётся", но вероятность срабатывания таких заявок стремится к нулю, так что погоды они не делают в любом случае, а сложности к алгоритму резко прибавляют.
6. Математические прогнозы по определению штука вероятностная, значит, во-первых, особая точность здесь не нужна и, во-вторых, любая заявка автоматически является прогнозом: мы надеемся, что курс пойдёт именно туда, куда нам надо. Но мы должны грамотно отработать обе ситуации: что делать, если курс пошёл туда, и что, если не туда.
7. Да, "доят лохов, в основном, не на этом", но и на этом тоже. А "психология" скрипт мало волнует: нервы у него крепкие, да и внимательность на высоте.
8. Да, с твоими аппетитами стакан нужен, как и собственный сервер на бирже, но в Квике это бесполезно пытаться использовать. Забыли, как страшный сон! Как говорил незабвенный Владимир Ильич: "Мы пойдём другим путём".
Пользователь
Сообщений: Регистрация: 30.01.2015
19.05.2022 18:07:48
Для тех, кому интересно. ---------------------- В результате тестов, получилось следующее решение: ---------------------------- 1) стаканы и обезличенные сделки принимаю в колбеках ----------------------- 2) свечи принимаю в main ------------------------- 3) индикаторы и алгоритмы решений реализую в отдельных потоках из пула потоков. ================== Вот затраты времени на тестовом сервере: Условие тестирование 220 инструментов 220 стаканов обезличенные сделки по всем акциям на демо сервер. =================
