Ошибки, баги, вопросы - страница 2284
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Но ведь даже если хранить незапакованными только каждый 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. Хотя в идеале, было бы хорошо иметь такую опцию в терминале, чтоб выбирать режим хранения истории в памяти. Например если в системе мало ОЗУ, но быстрый процессор, то это очень пригодилось бы.
Угу, только понятие "шустрый" в вашем случае очень относительно. Одно дело пользователь запросил массив баров - ему просто скопировался участок памяти. Либо запросил какую-то конкретную таймсерию, то тоже идёт простое копирование данных с постоянным шагом, равным размеру структуры. А другое дело - дополнительные вычисления и преобразования над каждым числом.
Хотя лично я бы предпочёл сжатую историю, чтобы не тратить понапрасну память, т.к. всё-равно организую собственные массивы по её хранению. Поэтому потерпеть небольшую задержку готов. Но большинство других пользователей вас растерзало бы за такое )
p.s. Хотя в идеале, было бы хорошо иметь такую опцию в терминале, чтоб выбирать режим хранения истории в памяти. Например если в системе мало ОЗУ, но быстрый процессор, то это очень пригодилось бы.
Ну смотрите. Я только что замерил скорость считывания и записи на своем SDD. Получилось что время записи и чтения 8 байт (1 тип значения double или datetime или long) ~ 48 нс. А по моим расчетам время считывания 8 байт информации с упакованного массива 1-2 нс. Т.е. при том, что мы теряем 1-2 нс на доступе к элементу структуры, мы выигрываем 48*0,8= 38 нс на записи и чтения с диска. При этом еще имеем экономию ОЗУ и дискового пространства в 5 раз. Про HDD вообще молчу.
Ну смотрите. Я только что замерил скорость считывания и записи на своем SDD. Получилось что время записи и чтения 8 байт (1 тип значения double или datetime или long) ~ 48 нс. А по моим расчетам время считывания 8 байт информации с упакованного массива 1-2 нс. Т.е. при том, что мы теряем 1-2 нс на доступе к элементу структуры, мы выигрываем 48*0,8= 38 нс на записи и чтения с диска. При этом еще имеем экономию ОЗУ и дискового пространства в 5 раз. Про HDD вообще молчу.
С этим я и не спорю. Когда речь идёт конкретно о закачке данных с диска, то безусловно вы правы. У нас ещё 4 года назад был спор с Ренатом на эту тему, в то время когда SSD был ещё достаточной редкостью, и подавляющее большинство юзеров сидело на медленных HDD. Так вот я тогда (на примере своего SSD) пытался его убедить, что операции с жёстким диском - самое тормозное звено в системе, и нужно стараться минимизировать объёмы потребляемой информации с него, а не наоборот. Но у него были аргументы такие, что незачем нагружать процессор лишней работой, и вообще вы тут все дураки, ничего не понимаете, и т.д. В общем всё как обычно )
Правда в нынешнее время SSD заметно ускорились.
Получилось что время записи и чтения 8 байт
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Ошибки, баги, вопросы
fxsaber, 2018.09.10 21:28
Сначала лог Оптимизации
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Мб тиков в несжатом виде.
Какую папку Терминала через mklink разместить на RAM-диск, чтобы данные считывались/писались не с SSD, а из памяти? Готов предоставить данные, какое это даст ускорение при Оптимизации.
Да, это архиважно. Если я правильно понимаю, то сейчас у вас, что на диске, что в памяти, тики и минутные бары хранятся в незапакованном виде, т.е. для бара (структура MqlRates) это 60 байт, а для тика (структура MqlTick) -52 байта.
Ужас! Уже давно надо с этим что-то делать.
Я понимаю, что главная проблема для сжатых массивов - это организация быстрого доступа к каждому элементу массива.
Но ведь даже если хранить незапакованными только каждый 256-й элемент массива, а в других элементах хранить только приращения к незапакованным, то на глазок размер массива сократиться в 4-5 раза, а время доступа к каждому элементу не очень сильно увеличиться (может на 1-2 наносекунд), зато колоссальная экономия времени на сохранение и считывания массива с диска и на диск.
"Всё уже украдено до вас" (ц)
На начало дня - полный тик. Потом бид и/или аск и/или ласт полностью, всё остальное приращения, если есть. В среднем 10 байт на тик.
Так как доступ к тикам строго последовательный, то нет проблем с организацией быстрого доступа к каждому элементу массива