Версия 4.2

К сожалению, лишь частично. Как я тут (http://stocksharp.com/posts/m/23724/) написал, ситуация улучш...

2013-04-01T08:41:22Z

К сожалению, лишь частично. Как я тут (http://stocksharp.com/posts/m/23724/) написал, ситуация улучшилась, но с увеличением количества дней (но не параллельно работающих EmulationTrader'ов) OutOfMemory неизбежен. Прошу прощения, что не обновил тему по результатам последующих тестов.

Тоесть ошибка осталась? Тогда можете привести минимальный код, воспроизводящий то, о чем вы пишите?

К сожалению, лишь частично. Как я тут (http://stocksharp.com/posts/m/23724/) написал, ситуация улучш...

2013-03-31T21:37:39Z

В качестве пожелания - рассмотрите возможность ухода от использования Ecng библиотеки, то, как она р...

2013-03-30T13:50:34Z

В качестве пожелания - рассмотрите возможность ухода от использования Ecng библиотеки, то, как она работает с памятью - это ужасно (http://stocksharp.com/posts/m/23646/). Попытка оптимизации параметров стратегии на истории с генерацией стаканов в ренже хотя бы месяц и, скажем, ±200 комбинаций параметров гарантированно заканчивается OutOfMemory и на послених версиях также.

Разве эту ошибку не полечили? Вы отписались, что она исправлена.

В качестве пожелания - рассмотрите возможность ухода от использования Ecng библиотеки, то, как она р...

2013-03-29T12:59:05Z

А почему попросту не привлечь реактивную модель Reactive Extensions (Rx) for .NET, которая как раз и...

2013-03-29T05:28:51Z

А почему попросту не привлечь реактивную модель Reactive Extensions (Rx) for .NET, которая как раз и заточены (и уже давненько) под решение таких проблем?
Кстати, разработка Rx была проопенсорсена и переведена в https://rx.codeplex.com/

VassilSanych

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

Это неочевидно при параллельном (мультиядерном) multicore, multiprocessor and/or (и распределённом кросс-машинном) multimachine программировании

Это неочевидно при параллельном (мультиядерном) multicore, multiprocessor and/or (и распределённом к...

2013-03-29T08:18:56Z

Терпила

Я вообще-то о бизнес-требованиях говорил.
Или "у меня есть золотой молоток и всё кругом - гвозди"?

Кстати. Ещё один вариант - уйти в многопоточности условно от транзакций Serializable к Read Committed. Т.е. где возможно, лочить только запись, а не чтение.
Я даже в своих исходниках в паре мест это реализовал через ConcurrentDictionary.
Должно повысить отзывчивость.

О стэйтлесс: Зачем стэйтлесс, когда в системе одновременно может быть принято только одно решение, п...

2013-02-13T19:55:03Z

О стэйтлесс:

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

Не зря делегаты иногда называют замыканием. Ой не зря. Я бы не перебарщивал с функциональщиной. Всем...

2013-02-13T19:45:01Z

Mikhail Sukhov

Не зря делегаты иногда называют замыканием. Ой не зря.

Я бы не перебарщивал с функциональщиной.
Всему своё место.
Есть место ООП, а есть место data driven или реляционной логике.
Есть место функциональщине, есть - старой доброй императивщине.
Трейдинг - штука глубоко императивная: получили сигнал - приняли решение на основе существующих статусов. Функции принятия решения, в свою очередь, до отупения просты.
Понимаю, что не модно. Зато актуально.

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

2013-02-13T19:22:50Z

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

событие пакуется в Action и кладется в очередь И это есть самая грубая ошибка. Не зря делегаты иногд...

2013-02-13T18:19:09Z

Mikhail Sukhov

ra81

событие пакуется в Action и кладется в очередь

И это есть самая грубая ошибка. Не зря делегаты иногда называют замыканием. Ой не зря.

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

событие пакуется в Action и кладется в очередь И это есть самая грубая ошибка. Не зря делегаты иногд...

2013-02-13T18:09:55Z

ra81

событие пакуется в Action и кладется в очередь

И это есть самая грубая ошибка. Не зря делегаты иногда называют замыканием. Ой не зря.

Получается, что пока одно событие из очереди полностью не обработано - все стоит и ждет? Совершенно...

2013-02-13T17:54:12Z

Den

Получается, что пока одно событие из очереди полностью не обработано - все стоит и ждет?

Совершенно верно. Вот так нехорошо и плохо происходит :)). Но в случае многопоточной работы происходит совершенно тоже самое. Пока ваш рулес не отпашет, другой рулес сидит и курит в локе, при этом запирает нафиг весь поток. Моя же схема так не делает, событие пакуется в Action и кладется в очередь, лок есь тока в фазе укладки Событий в очередь. Очень незначительный. Надыбаю нормальную неблокирующую очередь будет вообще четко. Пока не парился этим.
Ну и есеесно нет глюков дедлоков итд. Да и бошку греть не надо как разрулить весь этот гемор с потоками, тут надо было профессором чтобы все грамотно сделать. А в одну струю и ламер разберется.

Тогда снова вопрос, как будет реализоваться эта процедура? В предыдущем посте вопросы все в общем о...

2013-02-13T17:21:57Z

ra81

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

Получается, что пока одно событие из очереди полностью не обработано - все стоит и ждет?

А в чем беда использовать SyncronizedTrader?? Смысл уйти от локов к лок-фри, а не создавать еще новы...

2013-02-13T10:28:39Z

Mikhail Sukhov

ra81

А в чем беда использовать SyncronizedTrader??

Смысл уйти от локов к лок-фри, а не создавать еще новых локов.

А в чем беда использовать SyncronizedTrader?? Смысл уйти от локов к лок-фри, а не создавать еще новы...

2013-02-13T09:24:29Z

ra81

А в чем беда использовать SyncronizedTrader??

Смысл уйти от локов к лок-фри, а не создавать еще новых локов.

Новая потоковая модель. Это о чем? Сейчас стратегия выполняется в нескольких потоках. Это происходит...

2013-02-13T08:19:52Z

pyhta4og

ra81

Новая потоковая модель. Это о чем?

Сейчас стратегия выполняется в нескольких потоках. Это происходит от того что стаканы приходят в одном потоке, а сделки в другом. Как результатнеобходимость использования блокировок для доступа к полям например объекта Order.

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

Я то думал... эрланг... крутизна.
В механизмы того как сейчас все работает я неплохо посвящен. Куча локов и прочей ерунды включая пачку потоков.
А в чем беда использовать SyncronizedTrader?? Он ведь делает ту же самую петрушку? Через что планируется сделать синхронизацию, то есть как будет реализована вот эта самая очередь куда будет все заноситься? Она будет делаться на входе в стратегию для каждой стратегии?? А сам Trader кидать данные будет так же в многопоточном режиме?

Новая потоковая модель. Это о чем? Сейчас стратегия выполняется в нескольких потоках. Это происходит...

2013-02-13T08:10:48Z

ra81

Новая потоковая модель. Это о чем?

Как-то дискуссии не выходит. Выходит констатация фактов. Мы изменим и все. А на вопрос про потоковую...

2013-02-13T03:38:57Z

Как-то дискуссии не выходит. Выходит констатация фактов. Мы изменим и все. А на вопрос про потоковую модель ответа не услышал :(

Раз уж и так жёстко ломаете API, то наверное стоит проследить за более чёткой типизацией. Например, ...

2013-02-12T19:12:33Z

VassilSanych

Раз уж и так жёстко ломаете API, то наверное стоит проследить за более чёткой типизацией.
Например, Candle сделать дженериком от типа Arg, а то приведение object к нужному типу как-то не правильно и, наверное, не производительно, учитывая боксинг-анбоксинг и т.п.

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

Раз уж и так жёстко ломаете API, то наверное стоит проследить за более чёткой типизацией. Например, ...

2013-02-12T05:43:38Z