Ошибки, баги, вопросы - страница 2285
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Угу, только понятие "шустрый" в вашем случае очень относительно. Одно дело пользователь запросил массив баров - ему просто скопировался участок памяти. Либо запросил какую-то конкретную таймсерию, то тоже идёт простое копирование данных с постоянным шагом, равным размеру структуры. А другое дело - дополнительные вычисления и преобразования над каждым числом.
Хотя лично я бы предпочёл сжатую историю, чтобы не тратить понапрасну память, т.к. всё-равно организую собственные массивы по её хранению. Поэтому потерпеть небольшую задержку готов. Но большинство других пользователей вас растерзало бы за такое )
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 байт на тик.
Так как доступ к тикам строго последовательный, то нет проблем с организацией быстрого доступа к каждому элементу массива
Большая просьба выложить исходник записи "Tester\cache\*.opt". По содержимому видно, что формат очень простой.
Работать с результатами Оптимизации очень нужно. Спасибо!
По какой-то причине производительность Тестера падает с нарастанием количества сделок. При этом никакого обращения к торговой истории не происходит со стороны советника.
Такое положение видится неправильным.
В Тестере запоминается интервал, соответствующий режиму "Вся история". Добавляю в кастомный символ историю, перегружаю Терминал, а интервал соответствующий "Вся история" остается неизменным.
При этом если выбрать всю историю, задав всю историю вручную, то все норм. Просьба поправить.
В обозначенно месте не хватает крестика - удаление соответствующей строке записи в кеше.
Много делаю оптимизаций. Некоторые уже давно не актуальны. А механизма удаления этих вариантов нет. Выпадает иногда огромный список и начинаешь искать среди ненужных свой вариант.
Поэтому просьба рассмотреть возможность удаления ненужных данных по крестику в обозначенном на картинке месте.
Ошибка при выполнении
Результат: true:false:7:4
Это как это строки разной длины оказались вдруг равны? При том что сравнение с помощью StringCompare дает противоположный == результат
Спасибо за сообщение, изменили поведение посимвольного сравнения строк.
Если раньше строки сравнивались как Z-строки (до нулевого символа), то теперь они сравниваются как PASCAL-строки (с учётом длины).
На существующие коды с "нормальными" строками (без Z-нулевого символа внутри) данное изменение не повлияет.