Новая версия платформы MetaTrader 5 build 5120: улучшения и исправления - страница 34

[Stanislav Korotky]

Rorschach #:

А если еще float использовать, то больше истории влезет и быстрее чтение из памяти будет.

пс Перевод всех расчетов в float увеличит скорость расчетов в 2 раза, но муторно перед каждой переменной (float) писать.

В кодобазу уже выложен "сжиматель" тиков на принципе использования float (правда не все инструменты "влезут" без потери точности - в частности, некоторая крипта). Но если уже хочется совсем убыстриться, то можно перейти на целочисленную математику с ulong (в "пунктах" денег, а-ля тип decimal, который присутствует во всех уважающих себя финансовых платформах и SQL-движках).

[Edgar Akhmadeev]

Stanislav Korotky #:

Но если уже хочется совсем убыстриться, то можно перейти на целочисленную математику с ulong (в "пунктах" денег, а-ля тип decimal, который присутствует во всех уважающих себя финансовых платформах и SQL-движках).

Можно использовать короткие целые из нескольких бит (в зависимости от нужного диапазона) и упаковывать в длинные целые. Я лет 30 назад так собирался делать, когда работал над собственным мобильным терминалом. Позже у меня появилось первое мобильное устройство (в 1999г.) А ещё раньше (в 1980х) изучал процессор  Intel i432 (?), в котором не было разбиения на байты. Команды и данные были переменной ширины. Проц так и остался концептом.

И в архиваторах так же делается, вроде.

Т.е. не преобразовывать 1.12345 в 112345, это большие числа. А взять последовательность цен, укладывающихся в диапазон (например, 1.1-1.2), и сохранять значение 1.12345-1.1 = 2345, а в заголовке последовательности указать базу 1.1. Надо просчитать, какие минимальные последовательности (при сужении диапазона) допускать, чтобы не было слишком большого оверхеда из-за частых заголовков.

Рапаковка будет медленнее, зато будет плотная упаковка. Можно ещё что-нибудь придумать. Только не использовать алгоритмы сверхсжатия из архиваторов, это слишком медленно.

[Edgar Akhmadeev]

Вот ещё вариант, кажется его я когда-то планировал.

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

[Rorschach]

Stanislav Korotky #:

Но если уже хочется совсем убыстриться, то можно перейти на целочисленную математику с ulong (в "пунктах" денег, а-ля тип decimal, который присутствует во всех уважающих себя финансовых платформах и SQL-движках).

float в 2 раза меньше памяти занимает. С векторизацией целых чисел не знаю как дела

[Rorschach]

Хотелось бы иметь более наглядную визуализацию в 2D режиме тестера.

[fxsaber]

Stanislav Korotky #:

В кодобазу уже выложен "сжиматель" тиков на принципе использования float (правда не все инструменты "влезут" без потери точности - в частности, некоторая крипта). Но если уже хочется совсем убыстриться, то можно перейти на целочисленную математику с ulong (в "пунктах" денег, а-ля тип decimal, который присутствует во всех уважающих себя финансовых платформах и SQL-движках).

Встроил.

Слева без компрессии, справа - с компрессией (в прицепе).

Расход памяти ожидаемо снизился в три раза.

[Rorschach]

fxsaber #:

Встроил.

Слева без компрессии, справа - с компрессией (в прицепе).

Расход памяти ожидаемо снизился в три раза.

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

[fxsaber]

Rorschach #:
Попробуйте еще раз поиграть с блоками. Сейчас в кеш должно больше влезать данных

У всех разная конфигурация, поэтому объединил в одном советнике и RAMDrive-вариант и FileMap-вариант с возможностью включения/выключения компрессии тиков.

И вот такой результат получил.

Понятия не имею, почему FileMap+Compression стал столь бешено-быстро работать - в 20 раз быстрее режима по тикам, превысив 100 миллионов тиков в секунду.

Включение компрессии ускоряет оба варианта: RAMDrive и FileMap. Эксперименты с inBlocks и inBlockSize оставил желающим (инструкция, для FileMap желательно убедиться, что не будет использоваться своп-файл).

[fxsaber]

fxsaber #:

Эксперименты с inBlocks и inBlockSize оставил желающим (инструкция, для FileMap желательно убедиться, что не будет использоваться своп-файл).

150 миллионов тиков в секунду.

[Aleksei Kuznetsov]

fxsaber #:

150 миллионов тиков в секунду.

У вас тоже 3 блока оказались лучшими. Может 2-канальная память тоже. Или еще почему-то... Может в памяти чипы переключать реже надо например...


Не пробовали вторую переменную адреса задействовать, может получится более 4Гб сохранять/читать?

HANDLE  CreateFileMappingW(HANDLE hFile,PVOID lpFileMappingAttributes,uint flProtect,uint dwMaximumSizeHigh,uint dwMaximumSizeLow,const string lpName);

uint dwMaximumSizeHigh
uint dwMaximumSizeLow

Эти два параметра определяют 64-битное число размера памяти из старших и младших 32-х бит. То есть, размер памяти может быть больше 4 Гб.

Эту функцию сам не использовал, но по логике так.