Почему double, а не decimal?

Поздно конечно пить боржомии...
Напишу основной минус, который вижу для себя.
Размер необходимой памяти для дабл в два раз больше.
И для хранения в SQL и для ОЗУ.

Если с SQL не так все критично, можно докупить диски,
то с памятью конечно больше неприятностей.

На текущий момент бэктестинг еле влезает в 8Гб ОЗУ.
Больше ОЗУ добавить низя. Нужен новый сервер.
Правда там же крутится SQL.

Крайне неохото разбивать процесс на этапы, что бы
оставаться на том же железе. Пока еще не перевел
все на decimal. Очень надеюсь, что все влезет.

Вначале пути тоже выбирал double или decimal.
Выбрал double исключительно из-за ОЗУ.

Это все так... Лирика.
Больше некому поплакаться, не поймут. [rolleyes]

При тестировании на истории Sql не используется. Насчет занимаемой памяти я так и не понял, возросло с переходом на decimal или не возросло.

Данные для тестирования беру из SQL.
Результаты тестирования сохраняю в SQL.
SQL кушает порядка гигабайта.

Насчет того, насколько увеличилось потребление памяти
при переходе на decimal сейчас сказать не могу. Все еще
в процессе переделывания на новый лад. Как сделаю, напишу.
Перенос всей программы на decimal то еще увлекательное мероприятие :)

Но чисто теоретически, double занимает 8байт, decimal 16 байт.
71млн значений цены для сбера занимали ~500Мб, теперь должны занимать ~1000Мб.
Производных данных от цены меньше, но надо будет посмотреть сколько это все вместе
будет теперь занимать.

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

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

Проехали :)

Основная мысль, что переход на decimal для меня тот еще геморой.
А с другой стороны все устраивало на double.

Вот кстати сегодня тоже обнаружил что мой робот кушает 470мб оперативки.
Это работа с 4мя квиками (где берутся ленты и стаканы из каждого квика), и по 3 стратегии на каждом квике.

Не знаю много это или нет, т.к. не помню сколько было.

Перевел на decimal.
Потребление ОЗУ увеличилось с 5.6Гб до 6.6Гб.
Пока что влажу в лимит.

Эх, все же придется задуматься об оптимизации алгоритмов.

Также замечу, что некоторые методы Math и DateTime не принимают Decimal.
Лишнее преобразование в Double :)

B для этого Вам нужно забивать 7 гигов памяти? А не проще ли сохранять значения в sql или подгружать данные не все разом а постепенно пакетно? А вообще мне очень интересно как Вы умудряетесь забить 5-7 гигов памяти, ведь наверняка активно пользуете намного меньше.

Алгоритм приблизительно такой:
пробегаем по всем историческим данным и находим несколько производных значений от цены и объема, например, для каждой секунды.
Конечно, можно сделать разбиение на части и уложится даже в 10Мб.

Но зачем усложнять жизнь, если все можно одним куском в память запихнуть?

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

Если у Вас несколько таких роботов будет, то сколько памяти потребуется? И нет тут никакого особого усложнения жизни - сделаете еще одного робота, и придется все равно ее себе "усложнять". И дело не в double-decimal, а в проектировании программы: если так делать, то Вам вскорости никакой памяти не хватит.

Все правильно, размер Trade увеличился на 1.18. Меня пугает размер 5.6. Это получается что-то порядка 136 282 616 тиков. Уверены, что такой сайз нужен в памяти? Больше выделение объемов памяти плохо сказывается на производительности GC. Плюс не совсем понятно, зачем такой объем держать. Чтобы оптимизировать стратегию необходимо небольшой участок данных. Далее, найденные значения применяются ко всему периоду, который подгружается частями и выгружается. Держать больший период в памяти имеет смысл, если на нем идет частая проверка данных. Если это как раз оптимизация - то это уже плохо с точки зрения поиска на истории, так как идет подгонка параметров.

Все верно пишите.
Только как раз не хотелось заниматься разбитием процесса на части (загрузки и выгрузки частями).

Если касательно торгового робота (где я использую S#), то 5.6 гигов необходимо один раз, при первом старте стратегии, что бы просчитать все данные которые, были с начала истории по текущий момент.


Если касательно бэктестинга, то там я S# не использую. Но там много памяти надо постоянно :)


Считаю, что если алгоритм с небольшим количеством параметров (у меня ~7) дает хорошие результаты на 10 годах истории, то с большой вероятностью он будет хорошим и в ближайшие пол года. То есть подгонка в некоторых случаях имеет право на жизнь.
Вы не согласны?