Ошибки, баги, вопросы - страница 2283

Новый комментарий
 

При переименовании графического объекта не формируются события описанные в примечании к функции ObjectSetString

int OnInit()
{
    EventSetTimer( 5 );
    ChartSetInteger( 0, CHART_EVENT_OBJECT_CREATE, true );
    ChartSetInteger( 0, CHART_EVENT_OBJECT_DELETE, true );
    return INIT_SUCCEEDED;
}
void OnTimer()
{
static int i = 0;
    string name = "ABC";
    switch ( ++i ) {
    case 1: Print( __FUNCTION__, ":", i ); if ( !ObjectCreate(    0, name, OBJ_VLINE, 0, D'2018.08.24', 0 )) Print(GetLastError()); ChartRedraw(); break;
    case 2: Print( __FUNCTION__, ":", i ); if ( !ObjectSetString( 0, name, OBJPROP_NAME, name + "2"       )) Print(GetLastError()); ChartRedraw(); break;
    case 5: Print( __FUNCTION__, ":", i, ":", GetLastError()); EventKillTimer();                                                                   break;
    }
}
void OnChartEvent(const int id, const long &lparam, const double &dparam, const string &sparam)
{
    Print( __FUNCTION__, ":", EnumToString((ENUM_CHART_EVENT)id ));
}

Результат:
2018.09.10 04:23:51.542 Test (EURUSD,H4) OnTimer:1
2018.09.10 04:23:51.549 Test (EURUSD,H4) OnChartEvent:CHARTEVENT_OBJECT_CREATE
2018.09.10 04:23:56.534 Test (EURUSD,H4) OnTimer:2
2018.09.10 04:24:11.553 Test (EURUSD,H4) OnTimer:5:0

Ожидалось:
2018.09.10 04:23:51.542 Test (EURUSD,H4) OnTimer:1
2018.09.10 04:23:51.549 Test (EURUSD,H4) OnChartEvent:CHARTEVENT_OBJECT_CREATE
2018.09.10 04:23:56.534 Test (EURUSD,H4) OnTimer:2
                                      Test (EURUSD,H4) OnChartEvent:CHARTEVENT_OBJECT_DELETE
                                      Test (EURUSD,H4) OnChartEvent:CHARTEVENT_OBJECT_CREATE
2018.09.10 04:24:11.553 Test (EURUSD,H4) OnTimer:5:0

 
Alexey Navoykov:
Вы возможно невнимательно прочитали вопрос, который я задавал.  Я не спрашивал, зачем закрыли сервис-деск.  Я спрашивал, почему полностью удалили всю историю заявок оттуда и можно ли их отыскать теперь.

Уничтожено много нужной инфы.

 
Почему при Оптимизации постоянно идет обращение (лампочка мерцает с высокой частотой) к SSD?
 
fxsaber:
Почему при Оптимизации постоянно идет обращение (лампочка мерцает с высокой частотой) к SSD?
Генетика?
 
Slava:
Генетика?

Полный перебор. 8 ядер. Сам советник ничего никуда не пишет и не считывает. Кастомный символ по реальным тикам.

 
fxsaber:

Полный перебор. 8 ядер. Сам советник ничего никуда не пишет и не считывает. Кастомный символ по реальным тикам.

Так ведь тики хранятся не в оперативке же. Закачиваются по мере необходимости по частям, как я понимаю.

 
Nikolai Semko:

Так ведь тики хранятся не в оперативке же. Закачиваются по мере необходимости по частям, как я понимаю.

Если по реальным тикам, то да.

Можно в одиночном проходе посмотреть статистику, сколько памяти потрачено на хранение тиков. При оптимизации в памяти хранится одновременно не более 320 мегов. Всё остальное - на диске.

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

 
Slava:

Если по реальным тикам, то да.

Можно в одиночном проходе посмотреть статистику, сколько памяти потрачено на хранение тиков. При оптимизации в памяти хранится одновременно не более 320 мегов. Всё остальное - на диске.

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

Да, это архиважно. Если я правильно понимаю, то сейчас у вас, что на диске, что в памяти, тики и минутные бары хранятся в незапакованном виде, т.е. для бара (структура MqlRates) это 60 байт, а для тика (структура MqlTick) -52 байта. 
Ужас! Уже давно надо с этим что-то делать.

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

Но ведь даже если хранить незапакованными только каждый 256-й элемент массива, а в других элементах хранить только приращения к незапакованным, то на глазок размер массива сократиться в 4-5 раза, а время доступа к каждому элементу не очень сильно увеличиться (может на 1-2 наносекунд), зато колоссальная экономия времени на сохранение и считывания массива с диска и на диск. 

 
fxsaber:
Почему при Оптимизации постоянно идет обращение (лампочка мерцает с высокой частотой) к SSD?

Вот именно поэтому я не использую тики, а использую логарифмическую структуру данных(я уже говорил об этом), которая в данный момент времени состоит из пару тысяч тиков, далее пару тысяч минутных баров, 2000 M2, 2000 M5 , M10, M30, H1, H3, H6, H12, D1, W1... все бары MN1.
Формируется такая структура полных исторических данных на любой момент времени меньше милисекунды, и занимает в ОЗУ (точнее даже не в ОЗУ, а в кеше процессора) всего 1.5 МБ. И все заточенные под эту структуру алгоритмы просто летают. 

Ведь наше зрение устроенно по такому же логарифмическому масштабу: чем дальше мы смотрим, тем меньше замечаем мелких деталей. 

ЗЫ Вот когда в не очень далеком будущем в компьютерах все устройства памяти (жесткий диск, ОЗУ, кэш процессора) будут физически только одним устройством, а именно кэшем процессора размером цифры с 13 нулями, вот тогда я тоже перейду на тики :))

...

Хотя, возможно, это я не в тему, т.к. при такой структуре данных при оптимизации лампочка тоже будет мерцать. Ведь тики все равно все будут подгружаться :((

 
Slava:

Если по реальным тикам, то да.

Можно в одиночном проходе посмотреть статистику, сколько памяти потрачено на хранение тиков. При оптимизации в памяти хранится одновременно не более 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 тысяч считываний.


Лог одиночного прогона

Core 1  FILTER_EURUSD.rann_RannForex,M1: 132843 ticks, 60283 bars generated. Environment synchronized in 0:00:00.140. Test passed in 0:00:00.827 (including ticks preprocessing 0:00:00.109).
Core 1  FILTER_EURUSD.rann_RannForex,M1: total time from login to stop testing 0:00:00.967 (including 0:00:00.140 for history data synchronization)
Core 1  322 Mb memory used including 36 Mb of history data, 64 Mb of tick data

Видно, что используется ~130K тиков и 60K баров (в Тестере выбран режим "Вся история"). Т.е. ну очень малое количество истории.

Сама история кастомного символа в Терминале содержит такое количество исторических данных

Saved ticks = 133331
Generated Rates = 60609

Т.е. в истории символа совсем немного больше, чем использует Тестер.


ЗЫ Жалко смотреть на SSD... Во сколько же могла быть скорость Оптимизации выше? Странно, что ОС не кеширует эти данные, ведь меньше 7Мб тиков в несжатом виде.

1...227622772278227922802281228222832284228522862287228822892290...3768
Новый комментарий