Anton (Все сообщения пользователя)

А тут я б не поручился, на первый взгляд доступ к таблице тоже чисто байткод, но там внутри может дернуться метаметод, а он может дернуть сишное что-нибудь; при добавлении нового поля может дернуться коллектор, а там вообще мрак полный, кто там сейчас на очереди к удалению и есть ли у него финализаторы и не сишные ли они и т.д., в общем уже не отследить это все. Интересно вот что, если этот кусок таки окажется атомарным, то от зависания мы не ушли, получается? Тогда, получается, функцию Claster надо намеренно сделать неатомарной? Или я перемудрил уже?

Зато сам поллинг - архитектура.

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

Это не оптимизация, это вы архитектуру закладываете заведомо кривую. Потом ее "оптимизировать" - это переписать заново, вот это, видимо, и будет то самое полезное дело, куда полезнее, чем сразу написать ровно.

Артем, сидят два старпера, обсуждают потерю точности при обращении плохо определенных матриц. Подходит школотрон - ээээ, какая потеря точности, я джва года квадратные уравнения решал, нет никакой потери точности, дураки вы старперы, в утиль вас, прекрасное айти будущего наступает. Ну вот оно и наступает, точнее вступает, куда - видно. Чо там в вики про вытесняющую написано, как она задействуется, расскажите нам немедля, мы усе горим.

Архив больше? Там две длл, для core и mime. Если каждая длл больше, то скорее всего потому, что здесь рантайм встроенный, в других, видимо, отдельный. Скиньте какую-нибудь из этих других длл, посмотрю точно.

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

Ой. Прям вот на простейшую задачу сразу ядро отдадим? А если на компе два квика, то два, да? И принимающую сторону так же сделаем, еще два ядра минус. Ну а если уж нам задачу поставят UKF посчитать, мы сразу выкатим требования на датацентр, не меньше. Интел одобряет.

Да это моделька же.

Так и делаю на сях, там синхронизация есть человеческая. Тут если таймер поставить, его надо на ноль ставить, будет бесполезная дрызготня в цикле, включая выходные и праздники. Если на время поставить, будет задержка, в среднем половина этого времени. Задача как раз и рыбку съесть и пальчики облизать и все на чистом луа, без сей и виндов.

Вот так, ежли ничего не упустил опять

Не, прям вот так точно работать не будет, надо в качестве индекса в мейне отдельную переменную использовать, растущую от нуля и до эн, тогда может быть. А так он на одном месте будет пилить, пока колбеки идут.

Старатель,  что-то я протупил в аккурат до закрытия, теперь на ходу не проверить, а мысль пошла в такую сторону

А оно ведь тоже подвесит на первом же колбеке?

Была бы интересна функция вида
В ней можно было бы либо внутри достать новую строку (и все пропущенные, если таковые есть), либо переправить индекс в мейн и достать там. Но был бы недостаток: существование записи по этому индексу в момент попытки ее достать уже не гарантируется, т.е. можно и нил получить. Хотя это можно было бы явно оговорить в документации, не то чтобы проблема большая.

Я в колбеке ставлю событие и все, мейн по событию просыпается и вытаскивает все, чего еще не видел. Но это в длл, в луа не знаю, как без внешних сей засинхронизировать.

Будут-будут, главное не спешка, главное неуклонность. А вот в 8.13 добавилась vcomp140.dll, это крайне интересная инновация.

На фтп положили свежачок. Оно, видимо.

Даже на второй слишком лапидарно ответил. Поправлю: мое утверждение о том, что ваш вариант не допускает параллельную работу разных скриптов - неверно, допускает. Однако основное утверждение остается: ваш вариант - это ваш вариант, он сделан по-другому, нежели квиковский, хотя и в том же направлении. Так-то луа встроен во множество приложений, можно было взять из них любое многопоточное и привести как пример, вот, мол, не падает же. Это мало что дает. Интересно было бы воспроизвести в своем хосте похожие AV и докопаться до причины (благо сорцы своего хоста имеются, в отличие от квиковских).

Там тот же биас, что и в приведенных здесь изменениях. А именно, вы непринужденно залезаете в сорцы самого луа и переделываете их под свое видение прекрасного. Арка же, насколько я понимаю, старательно избегает этого. Что-то добавить - да, что-то менять - нет. Это в общем правильная позиция, переделанный луа автоматом становится аркиным творением и все косяки, как привнесенные, так и родные, ложатся на арку. Им это надо? Нет.

Затейливость была про удаление прицепленной структуры. В многопоточном приложении выделение объекта - тривиально, в этот момент о нем знает только выделяющий его поток и может с ним делать что угодно, в том числе и прибить. После того, как объект был показан другим потокам, удалить его - уже нетривиальная задача, надо сначала убедиться, что все потоки в курсе о том, что объект удаляется, и только потом физически удалить.

У вас, например, я не увидел DeleteCriticalSection, потому ли, что вы не нашли, куда бы ее приткнуть? Там есть куда, см. luai_userstateopen, luai_userstateclose, luai_userstatefree. Аналогичные макросы есть для потоков. Хайли лайкли косяк (был?) где-то в этих местах, что-то удаляется слишком рано. Ваш хост даже не пытается эту сторону промоделировать, чего же ему падать-то.

Уже не раз говорил, я сорцев квика никогда не видел. Но видел асм. Вы тоже можете на него посмотреть в отладчике, восстановить исходник интересующей части квика и сделать выводы. Это будет ближе к истине, чем пытаться придумать, как квик мог бы работать, если бы его писали вы.

Ага.

Получился именно свой стенд, довольно далекий от того, как сделано в квике. Отсюда и проигрыш квику в скорости. Квик перехватывает создание стейта для скрипта (для этого в луа есть соответствующие макросы под переопределение), прицепляет к стейту дополнительную структуру и создает критическую секцию в этой структуре, свою для каждого скрипта (именно поэтому разные скрипты таки могут выполняться параллельно друг другу, у вас - нет). Макросы lua_lock/lua_unlock устроены сложнее, чем у вас, они получают из стейта указатель на эту дополнительную структуру и захватывают/выпускают критическую секцию, принадлежащую данному скрипту (а не одну общую, как у вас). Кстати, удаляется эта дополнительная структура весьма затейливым образом, поскольку при наивном подходе существует вероятность возникновения гонок. В частности, попытка захватить прибитую критическую секцию дает как раз наш любимый ACCESS VIOLATION. Совпадение? Не думаю! (но может быть и совпадение) Еще учтите, что в квике все эти макросы выбирают не только нужный скрипт, но и нужную версию луа, то есть они еще сложнее, чем я описал, вариантов "хотеть как лучше, а получить AV в продакшене" у программистов арки больше, чем хотелось бы.

Не едет. То есть едет на ручной тяге и я б затруднился по пунктам расписать, что куда крутить в общем случае. К сожалению, семерку будут выдавливать и дальше и с этим ничего уже не сделать. Причем явно видно, что авторы опенсорца (не конкретно этого) радостно идут навстречу майкрософту, убивая совместимость со старыми студиями, все замены в их коде абсолютно не нужны с точки зрения работоспособности или каких-то там улучшений, просто чтобы в старых студиях не собиралось без танцев.

Собранные длл здесь. Все думаю где-то разместить "навеки", да руки не доходят.

Делал такое на хромиуме том же. Выбросил в итоге. То есть сама идея в теории привлекательная, но есть нюансы. Во-первых, хромиум тот еще уродец, а чего-нибудь получше (готового) не сыскать, во-вторых, html в качестве базы гуя плох изначально. VisualStudioCode отличный пример, как оно будет тупить, а там всего лишь текст раскрасить. Во что это превратится на тиковом графике и гадать не нужно. Чтобы получилось хорошо, надо вспомнить, что хтмл надстройка над дом, а над ней и другие надстройки есть (например xaml, хаха). Про операционную систему перебор, даже с учетом wasm оно все еще не более чем дом с колбеками.

Кривиться наверное. Кривляться не захочется разве что грубому гунну.

Шо значит могли бы. Если бы существовал нормальный браузер (а не агент гугла/яндекса/майкрософта с побочной функцией отрисовки хтмл), было бы здорово.

Это вы заказываете график по параметру last, а не просто график, последнее поле вообще не нужно указывать.

У меня самих спредов нет, не могу проверить.

Кстати говоря, побочно обнаружилось, что у финама тиковые данные тоже с неправильными направлениями. Клиенты финама, пните их, там походу вся база с момента введения синтетики битая. Ну не вся, а где синтетика есть.

С этим разобрался. Дело было так. В SiH1 активная заявка собирала стакан одним движением от 74102 до 74109. В SiM1 стоял оффер 74860, в SiH1SiM1 стоял бид 753 и вместе они давали синтетический оффер в стакане SiH1 по цене 74107 с объемом 10. Вот этот синтетический оффер был сожран вместе с обычными. Исполнение синтетического оффера привело к 1) выкупу оффера 74860 в SiM1 и 2) заливу в бид 753 в SiH1SiM1. Правильное направление должно быть КУПЛЯ. Таким же образом был сформирован и второй ордер по той же цене на 5 лотов и исполнился так же, направление тоже должно быть КУПЛЯ. Тут вопросов не осталось. Ваша картинка единственно правильная.

А вот тут есть только догадка. В ордерлог вроде как синтетика должна транслироваться как будто она не синтетика, а просто натуральная заявка, но она появляется только в момент матчинга, как бы вылетая навстречу активной заявке. Вот есть предположение, что сервер думает, что эта вылетевшая внезапно ниоткуда заявка и есть новая активная, и ставит направление по ней.

О чо есть. Там на стр.10 пример, кто что увидит в своей твс. Если у нас активная заявка в RiH1 собирала стакан, значит, спред туда должен бы войти с продажей, против активной, так вроде получается? Или же он влез с покупкой вперед активной и выжирал перед ней оффера? В презентации этот момент как-то слабо освещен, тут бы четкие формулировочки найти. Второй вариант прям как-то совсем уже отбито звучит, хотя по логике надо было именно купить.

Если у вас есть RiH1, а у меня есть RiM1, и вы купили у меня спред по 750, мы меняемся контрактами и вы мне доплачиваете 750, в базовые стаканы нам лезть вообще не надо. Туда нам надо лезть, если нас свели синтетически, как в презентации описано. Тут у нас, похоже, синтетика чистая:

строка 1 - купили первую ногу
строка 2 - купили вторую ногу
строки 3 и 4 - обменялись контрактами за углом (вне рынка; это видно только задним числом, в твс не попадает)

Не пройду все же мимо, спрошу: а меньшинство его сделок скока уносят?

Предлагаю топикстартеру посмотреть, что в новом терминале у него не транслируются спреды, а в старом транслируются. Ну и еще бы кого послушать, чтобы не на двух примерах выводы делать. У вас-то вот оно как, продажа или покупка?

Первая пара это что в твс было, вторая - единички следом установлены - это оффмаркет. Что кагбэ намекает, что спред выдергивался из стакана от имени не того, кто спред заказывал и потом на него переводился мимо рынка. В общем деталь техническая, как и фактически "критическая секция" в моменте, откуда и появляется "невозможная" продажа в потоке покупок.

А был бы спред на 100000 контрактов, вот это было бы щасте прям до планки. Интересно, у них такой сценарий закодили или будет как с минус нефтью.

А они не глючные. В военное время число пи может достигать четырех, а в нынешнем дивном мире направление сделки может достигать "покупка", ежли ровный пацан смотрит, который подписал бумагу шо фсе понял согласно фз как там его, о рынке короче.

Интересная там кухонька внутренняя. Взяли из стакана и тут же оффмаркетом слили, и номерочки последовательные. Тксть пусть весь мир подождет, мы тут спреды торгуем.

Скрытый текст

 

Посмотрел, что говорит финам, а финам согласен с моей картинкой. Свидетели путаюццо в показаниях. Ежли у кого есть ордерлог под рукой, было бы здорово.

Скрытый текст

 

Старатель, ваша картинка больше на правду похожа, очевидно же одним движением полстакана выжрали, как туда продажи могут вклиниться. Не все брокеры одинаково полезны, такой сделаем вывод.

Обновил до 8.12, перезаказал твс. Зе сейм
 

В 8.11 1025, как и твс показывает на картинке выше. Чудеса однако. Там явно 13 штук одной сделкой забрали, после покупки 3 продать 10 по той же цене в ту же микросекунду - очень сомнительно. Как в анекдоте, тут у них карта и поперла.

Но опять же цель не достигнута, сдали в итоге даже ниже цены условия, откуда только начинали тралить, лимитник на этом уровне давно бы залился и все были счастливы. Либо стоп по другой бумаге, если не хотелось палить лимитник в стакане раньше времени. В общем-то мои возражения тут больше направлены на какие-то чудесные ожидания, вот мол арка щас ченить накодит и прям вот все заработает, залезай в позу от балды, а квик сам собой в плюс ее покроет.

 

Разница кое-какая есть: рыночная, если в стакане совсем пусто, будет снята, лимитная - встанет все же в стакан и, возможно, кто-то сочтет ее достаточно вкусной. Это опять же уклон в сторону исполнить с максимальной вероятностью.

Усилю вышесказанное о методической ошибке. Тут само выставление заявки привязано к факту, что кто-то только что сожрал наиболее вкусные биды, то есть, получается, заявка вылетает в самый дурацкий момент, какой только можно было придумать. Вот этот сожравший биды чувак и съел вашу прибыль, а вы теперь пытаетесь за ним вдогонку бежать по выжженой поляне. Если есть хороший приток бидов, вас, возможно, закроют выше, но в этом случае и велик шанс, что это был локальный пичок с откатиком и по итогу цель протрейлить до максимума не достигнута, высадили. Собственно, так оно и будет происходить в большинстве случаев, а в меньшинстве будет ваш сценарий с передачей позиции внукам. Куда ни кинь - всюду клин. Выше хорошую фразу написали
Это ведь правильно написано, и, чтобы исполнить против, надо лить до того поспешного чувака. На чем основываясь - неважно в данном случае, главное что не на том, что чувак вас уже опередил.

Но проблема в том, что в этот момент нет желающих вам эту прибыль закрыть по указанной цене. Пока тики идут вверх, сигнала на закрытие нет. Сигнал появляется на тике вниз, вышедшем за отступ. Очевидно, что выше этого тика в моменте нет бидов, ставить туда - это ставить на отскок. Это может быть хорошо на спайках, хотя бы как "ну тогда вообще не исполняйте", но на реальном развороте это гарантирует неисполнение.

Приводился мт в пример. Но там дилер, мт отслеживает бид, то есть оферту от дилера провести сделку по данной цене, то есть в моменте есть предложение от дилера, остается его акцептовать. На биржевом рынке, как оказалось, мт тоже льет в пол, вообще безо всяких там спредов, тупо по рынку в пол.

Мое мнение - эта шняга под названием тейк-профит как тейкпрофит бесполезна и улучшить ее невозможно. Даже если смотреть на сумму лучших в стакане, попадем в аналогичную ситуацию, ведь бидов нет в этот момент и мы опять льем в пол или ставим на чудо. Использование этой автоматики - методическая ошибка, попытка закрыться по вчерашней (в широком смысле) цене.

Я тоже похоже.

Тут сетап: злой мейкер прибрал заявки из стакана и ткнул одним контрактом в небо, у народа посрабатывали тейки и вылили их позиции в пол, мейкер потирает ручки, народ безмолствует идет на форум выдвигать идеи, как с этим бороться. Ну вот типа так, выливать не в пол, а повыше. Кому повыше, ежли там бидов нет? А никому говорят, ставьте лимитник по нашей желаемой цене и фсе, не купят так не купят. Насчет трейлить его потом вверх тока дошло, ага, он же ж будет от текущей убегать, достанут только разве еще одим спайком, если сервер подвинуть не успеет. В общем оно все с самого начала вокруг вот этого вот крутится, мол как же так, тик есть, а бидов нету, как быть, куды бечь.

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

Это сообщение должно было быть где-то в начале. В такой формулировке вся ветка ни о чем, все работает правильно )
Как вы яхту назовете, так она и поплывет.

По задумке подтягиваться за ценой, когда та растет, и стоять на месте, когда не растет. Исполнится, когда цена откатится от очередного пика. Вообще говоря, много подобных вариантов пробовал в свое время (без квиковской автоматики, на своей) и ни один в продакшен не пошел, тупо лимитник "на чудо" в среднем выигрывает больше. Особенно если принять во внимание статистику, сколько в среднем недобирает закрытая позиция до ближайшего после закрытия пика.

shr540i, это все можно сделать на луа, погонять, посмотреть что будет, а то оно все как-то в сослагательном наклонении применительно к мамбе, мож там такие чудеса полезут, что дешевле лимитник сразу ставить безо всяких тралов. IB это IB, они для неразделенных счетов кухонька кухонькой, собсна и в сегрегированные они лапу запускали и попадались на этом, а арке-то об кого чудо-стопы крыть, об брокера? Брокер захочет ли, в конце концов софтину-то он заказывает, зачем же он себе во вред будет фичи просить. В начале ветки предложение было конкретное, сейчас ветка дошла до "сделайте хорошо, незнамо как, ну например так или эдак или вообще ортогонально двум предыдущим", это все из разряда мечтаний все же.

Про большой отступ это условие, чтобы лимитник провисел пару часов, двигаясь на каждый аптик. Размер там формулой задается. 2000 транзакций прошло, пусть сбор 1 рубль, имеем 200 рублей штрафа (минус 4 рубля, если сделка таки случилась). Очевидно, что куча юзеров выставит трейл, не вникая в подробности, и начнутся вопросы, за что денех взяли. Плюс лимит в 2000 транзакций уже превышен до конца дня и каждая следующая транзакция в классе будет платной. Есть большие сомнения, что использование такого "платного" трейла отобьет штрафы.

Надо листать п. 3.4.3

Есть штраф за бесполезное выставление заявок. Юзер выставит такой трейл с большим отступом, через пару часов после активации брокер влетает на штраф, кто его оплачивать будет?

Лучше на штуки, как-то давно предлагал. Однако есть минус, неожиданно много стороннего софта имеет 32-битные поля объема, много народу вляпается в проблемы.

В данном случае разве только "предполагающие" могут порезвиться. Видим два мейна, потоки 7108 (это, видимо, который ничего не делал, в слипе стоит) и 5524 (который, видимо, торговал и вызвал крэш). Видим, что основной поток 5812 выполняет код из qlist.dll, пытается что-то получить от луа и крэшится на этом. В арке в колстеке 5812 вместо смещений от PLUGIN_InitEx видят реальные функции (если символы подключить), так что, думается, им дальше догадаться быстрее, чем нам длл потрошить.

Чего уж в квике, прямо на бирже надо исправлять

Скрытый текст

Под скальперскими сделками для фьючерсов понимаются Срочные сделки, совершенные на основании безадресных заявок, приводящие к открытию и закрытию позиции по фьючерсу в течение одного Торгового дня. Величина биржевого сбора за совершение скальперских сделок с фьючерсами рассчитывается в соответствии с пунктом 3.1 Тарифов, с применением коэффициента в размере 0,5 (пять десятых) от суммарной величины биржевых сборов за совершение таких Срочных сделок.

С этим, впрочем, погорячился, много чего таки можно было бы трогать.