← Назад

Любопытные проекты.

anothar2 12 февраля 2012 · 1 мин чтения · 1 984 просмотров

клуб алготрейдеров

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

Комментарии (11)

Вход или Создать аккаунт, Войдите или зарегистрируйтесь, чтобы оставить комментарий

Mikhail Sukhov 12 февраля 2012

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

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

oshelest 15 февраля 2012

Mikhail Sukhov:

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

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

то есть как это без ООП? это что все в одну строчку как функциональное программирование :) и как это без выделения памяти? что совсем без памяти программа работает? :)

нет уж позвольте обьяснить свою точку зрения

Mikhail Sukhov 15 февраля 2012

oshelest: то есть как это без ООП? это что все в одну строчку как функциональное программирование :) и как это без выделения памяти? что совсем без памяти программа работает? :)

нет уж позвольте обьяснить свою точку зрения

За кучей папок я нашел самую сердцевину http://wpfrealtime.codeplex.com/SourceControl/changeset/view/11996#153533 Идея, как я понял, заключается в том, чтобы не запускать GC. Нет запущенного GC, значит код работает детерминировано. В .NET единственный способ не запускать GC - или его принудительно запускать после определенных действий (что неправильно, и только снизит производительность), или не пользоваться выделением памяти, и работать только со стековыми объектами (скорее всего, еще и с неким пулов объектов, так как чисто на стеке сделать программу такого уровня как на картинке невозможно). Последнее, как я понял и используется в приведенной ссылке. Тоесть, мы оперируем не множеством объектов, к которому может применять LINQ преобразования, а с обычной таблицей, и применяем уже табличную трансформацию.

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

anothar 16 февраля 2012

Хмм любопытно в стеке хранятся по идее только структуры, которые и были созданы для того чтобы их можно было в большом объеме создавать. Правда тогда прощай ооп-нет поддержки наследования. LINQ поддерживает сруктуры. Какую обычную таблицу вы имеете ввиду? DataTable?-она то хранится как раз таки в куче. А вот приведенный код скорее просто генератор случайных данных-просто пример коннектора. Стек тоже очищается при выходе за пределы. А так у C# впринципе неплохая скорость-тут впринципе интерес только в том как грамотно распределять потоки. Судя по статье- основная фича там в том что есть небольшое запаздывание в уведомлении гуи об изменениях, чтобы множество изменений выполнилось как одно-идея вполне разумная если скажем у вас открыта куча стаканов и графиков-то есть при множественном обновлении.

Mikhail Sukhov 19 февраля 2012

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

Да, это интересно. Можете кинуть прямой ссылкой именно на сам исходник, как это реализуется? Я лично это делаю через Unity + свой вспомогательный класс GuiDispatcher, который в себе содержит авто запускаемый DispatcherTimer.

До конца не дочитал статью. Я начал читать и честно ее дочитал до начала сравнения платформ. Введение было вообщем и ни о чем, или я так до сих пор и не понял о чем проект. Сравнение тоже какое-то скудное, на Stack-е описание лучше. Потом какие то картинки со слабо разборчивым шрифтом, и далее код-код-код... Вообщем из статьи ничего не понял. Из титульника на КП тоже слабо понятно, что это такое: библиотека, некая концепция или готовое приложение-демонстрация.

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

oshelest 20 февраля 2012

Mikhail Sukhov:

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

Да, это интересно. Можете кинуть прямой ссылкой именно на сам исходник, как это реализуется? Я лично это делаю через Unity + свой вспомогательный класс GuiDispatcher, который в себе содержит авто запускаемый DispatcherTimer.

До конца не дочитал статью. Я начал читать и честно ее дочитал до начала сравнения платформ. Введение было вообщем и ни о чем, или я так до сих пор и не понял о чем проект. Сравнение тоже какое-то скудное, на Stack-е описание лучше. Потом какие то картинки со слабо разборчивым шрифтом, и далее код-код-код... Вообщем из статьи ничего не понял. Из титульника на КП тоже слабо понятно, что это такое: библиотека, некая концепция или готовое приложение-демонстрация.

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

"основных" идей несколько:

"небольшое запаздывание" или буферизация данных http://wpfrealtime.codeplex.com/SourceControl/changeset/view/11996#153595
неблокирующая синхронизация http://wpfrealtime.codeplex.com/SourceControl/changeset/view/11996#153534

3.Медиатор http://wpfrealtime.codeplex.com/SourceControl/changeset/view/11996#153548

А так же реализован планировщик задач реального времени http://wpfrealtime.codeplex.com/SourceControl/changeset/view/11996#153583

Чего там непонятного? вроде все так доступно описал и шуточки добавил про жизнь свою что б товарищи не ленились до конца дочитать. А Михаил говорит даже титульник не понял :( Там же русским языком написано "trading application framework".

То есть если хочешь как GUI framework использовать - пиши свои маркет адаптеры + модули и торгуй и богатей А хочешь вытащить многопоточную модель как советует anothar тогда Mediator.cs (п.3) и PriorityTaskScheduler.cs (п.4) твои друзья. Их можно к любому GUI прикрутить

Mikhail Sukhov 01 марта 2012

Возник вопрос по маршалингу у WPF. Есть ObservableCollection, в который добавляется элемент. Элемент реализует INotPropChanged. Свойства стреляют изменяются из разных потоков. Соответственно, событие так же выстреливает. Почему WPF не выбрасывает исключение о попытке обратиться не из графического потока, а корректно отображает изменения?

oshelest 02 марта 2012

Mikhail Sukhov: Возник вопрос по маршалингу у WPF. Есть ObservableCollection, в который добавляется элемент. Элемент реализует INotPropChanged. Свойства стреляют изменяются из разных потоков. Соответственно, событие так же выстреливает. Почему WPF не выбрасывает исключение о попытке обратиться не из графического потока, а корректно отображает изменения?

ну там же все написано :) это не совсем " ... 2) Обычная реализация INOtifyPropertyChanged ...".

Элемент реализует INotifyPropertyChanged но OnPropertyChanged не вызывается сразу в set{ ... OnPropertyChanged ("...")} а предлагается отдельным методом. Поэтому элемент обновляется на разных потоках а NotifyCollection через определеные интервалы времени зовет OnPropertyChanged для изменившихся полей элемента на GUI потоке

Mikhail Sukhov 02 марта 2012

oshelest: Элемент реализует INotifyPropertyChanged но OnPropertyChanged не вызывается сразу в set{ ... OnPropertyChanged ("...")} а предлагается отдельным методом. Поэтому элемент обновляется на разных потоках а NotifyCollection через определеные интервалы времени зовет OnPropertyChanged для изменившихся полей элемента на GUI потоке

Спасибо больше. А вы (я так понял вы и есть автор проекта) планируете сделать это модульно? Сырцы конечно интересны, но мне было бы проще с готовым FW поработать.

А вопрос был чисто из теории. У нас сейчас примеры через обычный ObservableCollection сбайдены с ListView.ItemsSource. Добавлять в ObservableCollection нельзя, делаем GuiAsync. А вот данные в ячейках почему то тикают. Этого понять не могу, так как свойство точно не из графического потока обновляются.

oshelest 05 марта 2012

Mikhail Sukhov:

oshelest: Элемент реализует INotifyPropertyChanged но OnPropertyChanged не вызывается сразу в set{ ... OnPropertyChanged ("...")} а предлагается отдельным методом. Поэтому элемент обновляется на разных потоках а NotifyCollection через определеные интервалы времени зовет OnPropertyChanged для изменившихся полей элемента на GUI потоке

Спасибо больше. А вы (я так понял вы и есть автор проекта) планируете сделать это модульно? Сырцы конечно интересны, но мне было бы проще с готовым FW поработать.

А вопрос был чисто из теории. У нас сейчас примеры через обычный ObservableCollection сбайдены с ListView.ItemsSource. Добавлять в ObservableCollection нельзя, делаем GuiAsync. А вот данные в ячейках почему то тикают. Этого понять не могу, так как свойство точно не из графического потока обновляются.

Это я автор .... планирую ... но пока как то все времени не хватает :(

А вот данные тикают потому что Binding автоматом для вас потоки переключает

http://stackoverflow.com/questions/2553333/wpf-databinding-thread-safety

но я предпочитаю это сам контролировать - так как можно тики накапливать, задерживать и так далее

anothar 21 февраля 2012

Основан на Reactive Extensions-по сути опрашивает события с заданным интервалом.
Обычная реализация INOtifyPropertyChanged, но с пакетным уведомлением(обычная ObservableCollection уведомляет о каждом чихе). 3)Рапределение задач по шедулерам-периодические задачи получают главный приоритет(ака реалтаймовость)- а именно они и обновляют гуи. 4)Планировщик задач реального времени по сути просто запускает число задач соответствующее числу ядер(строчка _backgroundTaskFactory.StartNew(() => { while (true) {... ), что мне не очень нравится. Через заданные промежутки времени кладет в очередь сообщения а задачи их считывают-по идее надо динамически создавать число потоков(не меньше одного но и не больше стольки то-мне казалось что тут можно и какими-то стандартными средствами реализовать).