Михаил Шардин, как понять для чего? 

мат. расчет оценки стратегий в разных состояний рынка и разными системами управления, кривая же как итог оптимизации

го для оптимизации — раст для торговли ...

могу порекомендовать - 

1. Strategy layer
   Только генерирует намерение: открыть/закрыть/изменить позицию. Не считает брокерскую позицию и не знает деталей исполнения.

2. Execution layer
   Отправляет заявки, получает статусы, fills, ошибки, частичные исполнения. Это адаптер к брокеру/бирже.

3. Position ledger
   Главный внутренний источник правды по позициям стратегий. Строится только из fills/events, а не из текущего ответа брокера.

4. Position manager / risk
   Работает с внутренней позицией: SL/TP, trailing, лимиты, сопровождение, закрытие.

5. Broker snapshot
   Отдельный слой фактической позиции у брокера. Его задача — сверка, восстановление, контроль расхождений, но не основная бизнес-логика стратегии.

6. Reconciliation
   Сравнивает внутренний ledger с брокером и решает, что делать при расхождениях: warning, block trading, force sync, manual review.

Главная рекомендация: не смешивать strategy position и broker position. Стратегия должна жить от внутреннего ledger, брокер — только подтверждать реальность и помогать ловить рассинхрон.

Ключевое: не вести позицию “из брокера наверх”. Лучше вести ее “из событий вниз по контуру”.

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

<code>Strategy
-> Signal/Intent
-> Execution
-> Fill events
-> Internal ledger
-> PM/Risk
-> Broker reconciliation</code>

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

Пример с MFE хорошо показывает связь TSLab и ARANEA.

В TSLab это обычный кубик из TSLab.Script.Handlers.dll:

<code>TSLab.Script.Handlers.MFE
Execute(IPosition pos, int barNum) -> double</code>

По смыслу он берет MFE позиции на выбранной свече. В API TSLab это выглядит как:

<code>pos.OpenMFE(barNum)
pos.OpenMFEPct(barNum)
pos.MFE()
pos.MFEPct()</code>

То есть MFE — это максимальный возможный доход позиции от цены входа до выбранного бара / закрытия сделки.

В ARANEA логика та же, только она вынесена в расчетный контур:

<code>func MFE(isLong bool, entryPrice, maxH, minL float64) float64 {
    if isLong {
        return maxH - entryPrice
    }
    return entryPrice - minL
}</code>

Для процентов:

<code>mfePct = mfeAbs / entryPrice * 100</code>

Для long берется максимум High после входа:

<code>MFE = max(high) - entryPrice</code>

Для short наоборот:

<code>MFE = entryPrice - min(low)</code>

Поэтому перенос логики между TSLab и ARANEA не является проблемой. Я изначально делал совместимые по смыслу сущности: PM, параметры, MFE/MAE, stop/take/trailing. Разница в том, что в TSLab это кубик внутри визуального конструктора, а в ARANEA это часть бэктестера, оптимизатора и торгового движка, которую можно массово считать по миллионам профилей.

Vadim S, 
1. Основной стек ARANEA — Rust/Go. На нем написаны вычисления, оптимизация, бэктестер и торговый движок. Это не только оптимизатор, а полный контур для проверки, расчета профилей и дальнейшей работы с торговой логикой.
2. С переносом в TSLab проблем нет. Когда я создавал ARANEA, я изначально брал конфиги и логику расчетов из TSLab: названия параметров, PM, правила, структуру оптимизации. То есть ARANEA считает ту же логику, но быстрее за счет другого стека и другой архитектуры вычислений.

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

Открывать доступ к ARANEA как к программе я не планирую. Рассматриваю два формата: оптимизация стратегий под заказ или партнерство в разработке ПО/торгового контура.

Согласен, точнее сказать не “сигнал портится”, а “меняется качество ситуации после сигнала”. Сам факт сигнала уже произошел, но дальше каждый бар меняет контекст: цена, объем, MAE/MFE, волатильность, расстояние до уровня, скорость движения.

Я как раз описываю не модель “запрограммировал стратегию под конкретный PM и подогнал stop/take”, а другой слой: сначала измерить, что происходит после входа, и уже по изменению показателей выбирать подходящий PM.

То есть не сразу: сигнал -> stop/take -> лучшие параметры.
А сначала: сигнал -> поведение после сигнала -> оценка качества ситуации -> выбор управления позицией.

Не, не дипфейк :)

Просто тема такая, что в три абзаца не влезает. Тут не “купил/продал”, а входы, выходы, PM, отсечения, OOS, CPU/GPU и вся кухня вокруг исследований.

Если где-то накосячил в логике или цифрах — тыкай, обсудим. А что длинно, да, грешен.

Хороший пример. Но по сути вы описали не одну стратегию, а уже готовый контур отбора: 300 вариантов одной логики, 8 критериев, Excel, распределение денег, комиссия, ролловер и 7 лет OOS.

Именно это я и автоматизирую в ARANEA, только без ручного Excel-слоя и с масштабированием на большее число правил, PM, активов и таймфреймов.

Показатели у вас хорошие, период большой, сделок много. Я бы дальше как раз делил историю на участки, смотрел устойчивость этих 300 вариантов по разным рыночным режимам, проверял, какие профили живут стабильно, какие держатся на отдельных годах, и уже потом исследовал правила/PM глубже.

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

Пример с результатами я буду показывать на той же банальной идее из статей: ложный пробой дневного уровня, те же общие правила, те же “краски” и тот же контур отбора. Без деталей, которые превращают это в готовую торговую инструкцию. Если бы цель была похвастаться результатами или открытиями, я бы начал серию не с “2 000 000 вычислений в секунду в TSLab”, а с “2 000 000 в месяц на TSLab”. Но это была бы уже совсем другая статья.

Я не пытаюсь показать “супер-пупер подход”. Наоборот, подход довольно логический: сначала понять, что именно считаем, потом отсечь бессмысленные ветки, потом проверить не одного чемпиона, а семейства профилей, потом смотреть out-of-sample/правую сторону. Для меня “супер-пупер подход” — это скорее когда быстро нашли лучший набор параметров по одной метрике и отправили его в бой. Вот это как раз путь на убой.

По рынкам: речь не только про акции. ARANEA строится как контур под разные рынки: крипта spot/futures, MOEX, forex, US stocks. TSLab в статьях используется как понятная визуальная точка отсчета, а не как место, куда я пытаюсь запихнуть весь мульти-рынок и переключение фьючерсов.

По тестированию: суть везде одна. Можно прогнать 200-300 стратегий вперед-назад, поработать с аналитикой, потом запустить их в бэктест или на правую часть истории. Это мало чем отличается от проверки на правой стороне графика: важно не то, где именно нажата кнопка, а выдерживает ли профиль новые данные, соседние параметры, комиссии, просадку и смену рыночного режима.

Поэтому “лопата” здесь не самоцель. Инструмент нужен не ради красивой скорости, а чтобы не путать исследование с подбором лучшей строки в таблице. Результат для меня — это не один красивый equity-график, а набор профилей, которые прошли отбор, правую сторону и не развалились при нормальной проверке.

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

Но в моем эксперименте важен еще и масштаб контура. Сейчас замеры идут на старом Intel Core i5 750: это 4-ядерный процессор 2009 года, но в конфиге расчет ограничен 3 ядрами. На нем ARANEA на разных стратегиях дает разную скорость: где-то 100k оценок/сек, где-то 600k+, на отдельных простых участках бывает около 1M. Разброс зависит от PM, длины жизни сделки, pruning и структуры входов.

Я пробовал переносить часть вычислений на GPU. На отдельных PM-batch-ах CPS действительно рос примерно в 6-20 раз. Но вместе с этим кратно росли и затраты: сложность архитектуры, память, нагрев, требования к железу и устойчивость длинного прогона. Когда сценарий становится не “одна стратегия и одна функция качества”, а массовое исследование: сотни стратегий, разные таймфреймы, 1000+ правил, десятки PM, сотни индикаторных рядов, GPU начинает упираться уже не только в математику, но и в память, температуру, передачу данных и неоднородность задач.

Поэтому я и не ставлю GPU в центр статьи. GPU — сильный backend для подготовленных плотных batch-ей. Но исследовательский контур должен сначала решить, что считать, что отсечь, какие ветки сохранить и как проверить правую сторону. Старый CPU в этом смысле показателен: он может несколько дней стабильно жить на огромной расчетной сетке, потому что архитектура режет мусор, переиспользует данные и ведет расчет последовательно.

Так что мой тезис не “GPU не нужен”. Наоборот, GPU может быть вторым исполнительным контуром. Мой тезис: скорость отдельной симуляции и скорость исследования — разные вещи. Если оптимизировать только одну метрику одной стратегии, GPU выглядит идеально. Если строить карту гипотез по множеству стратегий, правил, PM и рынков, то сначала нужна архитектура исследования, а уже потом CPU/GPU как вычислительные исполнители. Я позже в статьях обязательно раскрою эту тему подробно, но это будет позже)

Да, с ветвлениями на GPU согласен. Поэтому я и не говорю про наивный брутфорс всего пространства на GPU. GPU хорошо работает, когда задача уже приведена к плотному однотипному batch-у: сигналы подготовлены, ветки отсечены, данные лежат в памяти, и дальше надо массово прогнать PM-варианты.

Но тогда важно уточнить, что означает “200 000 комбинаций/сек”. Это один PM? одна стратегия? одна структура правил? уже подготовленные сигналы? включены ли разные PM-семейства, stop/take/trailing, pruning, комиссии, сохранение метрик и правая сторона? Без этого это скорость конкретного backend-слоя, а не скорость полного исследования.

В статье пример специально идет на старом компьютере: i5 750, 16 GB RAM, AMD R9 200 2 GB. На таком железе задача как раз показать не рекорд скорости, а роль архитектуры: что сначала нужно отсечь, что переиспользовать, что не считать вообще и как собрать расчетный план.

Если перенести ARANEA на сервер уровня AMD EPYC 9554 64C/128T, 128-256 GB RAM и добавить 2-4 GPU уровня RTX 4090 / RTX 6000 Ada / L40S, то плотный PM-batch можно вынести на GPU и получить уже не сотни тысяч, а сотни миллионов PM-оценок в секунду на подходящих задачах. Но полный pipeline ускорится меньше, потому что вокруг PM остаются entry-prep, группировка, pruning, winners, артефакты и правая сторона.

Поэтому я не спорю, что GPU может быстро считать. Мой тезис другой: скорость backend-а не равна качеству исследования. 200 000 комбинаций/сек — это хорошая скорость исполнительного слоя. Но если нет карты гипотез, отсечения, проверки правой стороны и понимания, какие ветки вообще живые, то это больше похоже на быстрый перебор, чем на управляемое исследование стратегии.

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

Но я в статье говорю не только про скорость одного слоя симуляции. У меня задача шире: одновременно исследовать и сопровождать много стратегий, правил, PM-семейств и рынков, а не просто прогнать одну сетку параметров.

ARANEA — это не “еще один быстрый бэктестер”. Это контур, где нужно собрать карту гипотез, подготовить entry, отсечь пустые ветки, переиспользовать ряды и сигналы, прогнать PM, сохранить артефакты, проверить правую сторону, собрать пулы, а потом еще связать это с торговым runtime.

Поэтому GPU в такой архитектуре может быть одним из backend-слоев для массового прогона. Но он не заменяет саму архитектуру исследования. Он ускоряет участок, где задача уже приведена к плотной параллельной форме.

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

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

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

GPU может быть отличным backend-слоем внутри такого контура. Но он не заменяет сам контур. Он быстро считает то, что уже приведено к удобной для GPU форме.

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

В моей статье проблема шире: не просто прогнать одну стратегию по сотням тысяч параметров, а построить исследовательский контур, где есть разные entry-ветки, фильтры, PM-семейства, отсечения, группировка входов, pruning, сохранение артефактов, правая сторона истории и повторяемость экспериментов.

Для GPU важна однородность задачи. Чем больше в расчете ветвлений, разных правил выхода, разной длины сделок, условий остановки, sparse-сценариев и логики отбора, тем сложнее это эффективно уложить в один массовый kernel. Поэтому “сотни тысяч комбинаций в секунду” и “управляемый перебор триллионной карты гипотез” — не одно и то же.

Плюс тут важно сравнивать не только скорость симуляции, а полный pipeline: подготовка данных, расчет сигналов, переносы памяти, фильтрация пустых веток, PM-прогон, метрики, сохранение результатов и повторный запуск. Если CPU-подготовка занимает существенную часть времени, то GPU ускоряет только один слой, а не всю исследовательскую систему.

GPU — отличный инструмент для плотной массовой симуляции, когда задача уже правильно разложена. Но саму проблему архитектуры исследования он не отменяет. Сначала нужно понять, что считать, что отсечь, что сохранить и как проверять на правой стороне. А уже потом выбирать, где считать: CPU, GPU, Rust, C++, Python/numba или смешанным контуром.