Ошибки, баги, вопросы - страница 2284
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Так ведь тики хранятся не в оперативке же. Закачиваются по мере необходимости по частям, как я понимаю.
Если по реальным тикам, то да.
Можно в одиночном проходе посмотреть статистику, сколько памяти потрачено на хранение тиков. При оптимизации в памяти хранится одновременно не более 320 мегов. Всё остальное - на диске.
Мы сейчас обдумываем решение, чтобы в общей памяти держать все тики, чтобы все локальные агенты из этой памяти читали. Тогда обращений к диску не будет, и оптимизация быстрее будет.
Если по реальным тикам, то да.
Можно в одиночном проходе посмотреть статистику, сколько памяти потрачено на хранение тиков. При оптимизации в памяти хранится одновременно не более 320 мегов. Всё остальное - на диске.
Мы сейчас обдумываем решение, чтобы в общей памяти держать все тики, чтобы все локальные агенты из этой памяти читали. Тогда обращений к диску не будет, и оптимизация быстрее будет.
Да, это архиважно. Если я правильно понимаю, то сейчас у вас, что на диске, что в памяти, тики и минутные бары хранятся в незапакованном виде, т.е. для бара (структура MqlRates) это 60 байт, а для тика (структура MqlTick) -52 байта.
Ужас! Уже давно надо с этим что-то делать.
Я понимаю, что главная проблема для сжатых массивов - это организация быстрого доступа к каждому элементу массива.
Но ведь даже если хранить незапакованными только каждый 256-й элемент массива, а в других элементах хранить только приращения к незапакованным, то на глазок размер массива сократиться в 4-5 раза, а время доступа к каждому элементу не очень сильно увеличиться (может на 1-2 наносекунд), зато колоссальная экономия времени на сохранение и считывания массива с диска и на диск.
Почему при Оптимизации постоянно идет обращение (лампочка мерцает с высокой частотой) к SSD?
Вот именно поэтому я не использую тики, а использую логарифмическую структуру данных(я уже говорил об этом), которая в данный момент времени состоит из пару тысяч тиков, далее пару тысяч минутных баров, 2000 M2, 2000 M5 , M10, M30, H1, H3, H6, H12, D1, W1... все бары MN1.
Формируется такая структура полных исторических данных на любой момент времени меньше милисекунды, и занимает в ОЗУ (точнее даже не в ОЗУ, а в кеше процессора) всего 1.5 МБ. И все заточенные под эту структуру алгоритмы просто летают.
Ведь наше зрение устроенно по такому же логарифмическому масштабу: чем дальше мы смотрим, тем меньше замечаем мелких деталей.
ЗЫ Вот когда в не очень далеком будущем в компьютерах все устройства памяти (жесткий диск, ОЗУ, кэш процессора) будут физически только одним устройством, а именно кэшем процессора размером цифры с 13 нулями, вот тогда я тоже перейду на тики :))
...
Хотя, возможно, это я не в тему, т.к. при такой структуре данных при оптимизации лампочка тоже будет мерцать. Ведь тики все равно все будут подгружаться :((
Если по реальным тикам, то да.
Можно в одиночном проходе посмотреть статистику, сколько памяти потрачено на хранение тиков. При оптимизации в памяти хранится одновременно не более 320 мегов. Всё остальное - на диске.
Мы сейчас обдумываем решение, чтобы в общей памяти держать все тики, чтобы все локальные агенты из этой памяти читали. Тогда обращений к диску не будет, и оптимизация быстрее будет.
Сначала лог Оптимизации
Tester optimization finished, total passes 714240 Statistics optimization done in 7 hours 31 minutes 06 seconds Statistics local 714240 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%) Core 1 connection closed Core 2 connection closed Core 3 connection closed Core 4 connection closed Core 5 connection closed Core 6 connection closed Core 7 connection closed Core 8 connection closed Tester 714240 new records saved to cache file 'tester\cache\Test.FILTER_EURUSD.rann_RannForex.M1.20180226.20180909.40.2D734373DF0CAD251E2BD6535A4C6C84.opt'В течение этих 7.5 часов шло обращение к SSD с огромной частотой. Если на каждом проходе считывались тики, то получается в среднем 26 раз в секунду в течение 7.5 часов. Отсюда и такое дикое моргание - более 700 тысяч считываний.
Лог одиночного прогона
Видно, что используется ~130K тиков и 60K баров (в Тестере выбран режим "Вся история"). Т.е. ну очень малое количество истории.
Сама история кастомного символа в Терминале содержит такое количество исторических данных
Т.е. в истории символа совсем немного больше, чем использует Тестер.
ЗЫ Жалко смотреть на SSD... Во сколько же могла быть скорость Оптимизации выше? Странно, что ОС не кеширует эти данные, ведь меньше 7Мб тиков в несжатом виде.
Но ведь даже если хранить незапакованными только каждый 256-й элемент массива, а в других элементах хранить только приращения к незапакованным, то на глазок размер массива сократиться в 4-5 раза, а время доступа к каждому элементу не очень сильно увеличиться (может на 1-2 наносекунд), зато колоссальная экономия времени на сохранение и считывания массива с диска и на диск.
Рената на вас не хватает ) Cкоко раз уж предлагалось оптимизировать хранение истории. Особенно учитывая, что на сжатие (а это наиболее ресурсоёмкая часть) ничего тратить не нужно, т.к. данные изначально приходят с сервера сжатыми. А в распакованном виде держать только кэш, который постоянно используется... Но тут обычно всегда начинаются лекции в стиле: если вы не можете себе купить более объёмный или быстрый винт - на МТ вам делать нечего. И про медленные VPS всегда речь заходит почему-то.
Рената на вас не хватает ) Cкоко раз уж предлагалось оптимизировать хранение истории. Особенно учитывая, что на сжатие (а это наиболее ресурсоёмкая часть) ничего тратить не нужно, т.к. данные изначально приходят с сервера сжатыми. А в распакованном виде держать только кэш, который постоянно используется... Но тут обычно всегда начинаются лекции в стиле: если вы не можете себе купить более объёмный или быстрый винт - на МТ вам делать нечего. И про медленные VPS всегда речь заходит почему-то.
еще раз повторю, что главная проблема упакованных массивов - это организация быстрого доступа к любому элементу массива, а не их последовательное считывание. Поэтому здесь нужен другой формат сжатия (точнее даже формат хранения), да такой, чтобы не требовалось его распаковка и упаковка. В ~10 раз сжатие как у zip, png и др. конечно не получится, но думаю в 5 раз возможно.
Ну действительно, если подумать в MqlRates для хранения информации о минутном баре (а хранятся именно только минутные) под close, open, high, low выделено аж 8*4=32 байта, хотя в 99 % случаев эти значения отличаются меньше, чем на байт информации, т.е. уже почти достаточно 8+1+1+1=11 байт, даже если не привязываться к прошлым барам. И time в 99 % случаев отличается от предыдущего значения ровно на 60 (т.е. в 99 % случаев достаточно 1 бита информации - 60 или не 60 ). И для этого тоже отводится 8 байтов.
еще раз повторю, что главная проблема упакованных массивов - это организация быстрого доступа к любому элементу массива, а не их последовательное считывание. Поэтому здесь нужен другой формат сжатия (точнее даже формат хранения), да такой, чтобы не требовалось его распаковка и упаковка. В ~10 раз сжатие как у zip, png и др. конечно не получится, но думаю в 5 раз возможно.
Если мы говорим о хранении на диске, то доступ к конкретному элементу не имеет смысла, т.к. файловая операция сама по себе затратна. Поэтому считывается сразу крупный кусок. Например файлы баровой истории разбиты по годам, тики - по месяцам. Хотя лучше бы конечно дробить помельче. А если вы имеете ввиду вообще держать историю в памяти в упакованном виде, постоянно распаковывая на лету каждый элемент, то боюсь это мало кого устроит.
Я только что придумал формат хранения, который хранит блоки по 256 элементов MqlRates и занимает в среднем 2900 байт(размер блока будет плавающим), т.е. на одну структуру MqlRates будет выделяться 2900/256= ~ 12 байт, что в 5 раз меньше, как я и предполагал.
Доступ к каждой элементу упакованной такой структуры MqlRates достаточно шустрый ( 2-3 суммы, 2-3 проверки, 2-3 сдвига, т.е. вряд ли больше 1 наносекунды)
Если мы говорим о хранении на диске, то доступ к конкретному элементу не имеет смысла, т.к. файловая операция сама по себе затратна. Поэтому считывается сразу крупный кусок. Например файлы баровой истории разбиты по годам, тики - по месяцам. Хотя лучше бы конечно дробить помельче. А если вы имеете ввиду вообще держать историю в памяти в упакованном виде, постоянно распаковывая на лету каждый элемент, то боюсь это мало кого устроит.
Она будет и на диске храниться в "сжатом" виде и в память также считываться в этом же формате. Никакого преобразования в полный формат производиться не будет, только лишь будет вычисление в момент считывания конкретного элемента структуры MqlRates. И это будет значительно быстрее с учетом того, что работы с диском будет в пять раз меньше.
Доступ к каждой элементу упакованной такой структуры MqlRates достаточно шустрый
...
Она будет и на диске храниться в "сжатом" виде и в память также считываться в этом же формате. Никакого преобразования в полный формат производиться не будет, только лишь будет вычисление в момент считывания конкретного элемента структуры MqlRates.
Угу, только понятие "шустрый" в вашем случае очень относительно. Одно дело пользователь запросил массив баров - ему просто скопировался участок памяти. Либо запросил какую-то конкретную таймсерию, то тоже идёт простое копирование данных с постоянным шагом, равным размеру структуры. А другое дело - дополнительные вычисления и преобразования над каждым числом.
Хотя лично я бы предпочёл сжатую историю, чтобы не тратить понапрасну память, т.к. всё-равно организую собственные массивы по её хранению. Поэтому потерпеть небольшую задержку готов. Но большинство других пользователей вас растерзало бы за такое )
p.s. Хотя в идеале, было бы хорошо иметь такую опцию в терминале, чтоб выбирать режим хранения истории в памяти. Например если в системе мало ОЗУ, но быстрый процессор, то это очень пригодилось бы.