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

Новый комментарий
 
Renat Fatkhullin #:
о, поставил тикет на исп

Добрый вечер. Проверьте, пожалуйста, и вот такую особенность в работе компилятора MQL5 (воспроизводится на билде 4424)

Следующий код не компилируется

namespace ns
{
  template<typename T>
  class A
  {
  public:
    A(int) {}
  };
}

class B : public ns::A<string>
{
public:
  B() : A<string>(1) {}
};

Если класс A объявить в глобальном пространстве имен, или сделать его не шаблонным, то все хорошо. А вот шаблон в именованном пространстве имен компилятор не может "переварить".

Нашел воркэраунд - помогает объявить шаблон за пределами неймспейса.

Так собирается:

namespace ns
{
  template<typename T>
  class A
  {
  public:
    A(int) {}
  };
}

template<typename T>
class A;

class B : public ns::A<string>
{
public:
  B() : A<string>(1) {}
};
 

После обновление в окошке с тиками, которое появляется при открытии позиции, перестали двигаться эти самые тики.

2024.08.20 20:40:28.431 Terminal        MetaTrader 5 x64 build 4486 started for MetaQuotes Software Corp.
2024.08.20 20:40:28.432 Terminal        Windows 7 Service Pack 1 build 7601, 8 x AMD FX-8350 Eight-Core, AVX, 24 / 31 Gb memory, 225 / 1794 Gb disk, admin, GMT+3


 
b4503, для одиночного прохода не хватило памяти и выскачило такое сообщение Тестера. 
2024.08.27 16:44:41.341 Core 01 cannot add real tick event (events' array size is 458752)

Что это за массив с таким количеством эвентов?


Сейчас ищу причину, почему одиночные прогоны (без ордеров) потребляют в пять раз больше памяти, чем оптимизационные...

 
fxsaber #:

Сейчас ищу причину, почему одиночные прогоны (без ордеров) потребляют в пять раз больше памяти, чем оптимизационные...

b4505, одиночный прогон потребляет в несколько раз больше памяти, чем оптимизационный.


Воспроизведение на  MetaQuotes-Demo.

#property tester_no_cache

input int inRange = 0;

double OnTester()
{
  return(TerminalInfoInteger(TERMINAL_MEMORY_USED));
}


Одиночный.

Core 01 OnTester result 3893
Core 01 EURUSD,M1: 164312588 ticks, 2452676 bars generated. Environment synchronized in 0:00:00.089. Test passed in 0:01:09.761 (including ticks preprocessing 0:00:47.203).
Core 01 EURUSD,M1: total time from login to stop testing 0:01:09.850 (including 0:00:00.089 for history data synchronization)
Core 01 3892 Mb memory used including 163 Mb of history data, 3328 Mb of tick data


Оптимизационный (оставлял включенным только один локальный Агент).

Tester  optimization finished, total passes 2
Statistics      optimization done in 1 minutes 38 seconds
Statistics      shortest pass 0:00:21.476, longest pass 0:01:14.168
Statistics      local 2 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%)


Разница более, чем в три раза по потреблению памяти. Task Manager подтверждает порядок чисел.

Если делать бэктест не за несколько лет, а за год, то потребление RAM совпадает и у одиночного и у оптимизационных.


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


ЗЫ Возможно ли не пересобирать каждый раз тиковую историю при запуске одиночных прогонов один за другим?


Строка для поиска: Oshibka 115.

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

Компилятор: b4410 vs b4512.


Такой код выдает разный результат при отключенной оптимизации.

void OnStart()
{
  Print((string)TerminalInfoInteger(TERMINAL_BUILD) + " - " +
        (string)IsOptimizationCompiler()); // https://www.mql5.com/ru/forum/170952/page247#comment_52620994
}
4410 - false
4512 - true

Т.е. в 4512 включена какая-то оптимизация, по сравнению с b4410.


Время компиляции.

Настройки компилятора b4410 b4512
Debug 5392 msec 10528 msec
Release (оптимизация выключена) 4832 msec 12200 msec
Release (оптимизация включена) 87060 msec 42578 msec


В таблице приведено время, уходящее на компиляцию большого проекта. Хорошо видно, что ждать дебага в 4512 приходится в два раза дольше, чем в b4410. При этом полная оптимизация в b4512 происходит в два раза быстрее!

Очевидно, что дебаг выгоднее проводить в b4410, т.к. каждый запуск происходит в два раза быстрее (ждать 10 секунд каждый раз - дорого).


Время выполнения.

Настройки компилятора b4410 b4512
Debug 42% 50%
Release (оптимизация выключена) 46% 53%
Release (оптимизация включена) 100% 100%


Видимая разница только в первых двух режимах. В них b4512 стал на 25% быстрее, но достигается это увеличением времени компиляции в два/три раза. Хотелось бы, чтобы в этих режимах b4512 вел себя, как b4410 - не замедлял компиляцию за счет включения доп. оптимизаций (см. начало поста).

 
Unfortunately the translation feature of the site is currently not working.
 

Вот в такую засаду я сейчас попал.

Просто в перерыве отладки на истории прилетело обновление. Я согласился и после перезапуска ни один код не компилируется.

Какие файлы сюда выложить для понимание ситуации:

 
Alexey Viktorov #:

Вот в такую засаду я сейчас попал.

Просто в перерыве отладки на истории прилетело обновление. Я согласился и после перезапуска ни один код не компилируется.

Какие файлы сюда выложить для понимание ситуации:

Тоже так

 
Alexey Viktorov #:

Вот в такую засаду я сейчас попал.

Просто в перерыве отладки на истории прилетело обновление. Я согласился и после перезапуска ни один код не компилируется.

Какие файлы сюда выложить для понимание ситуации:

Сейчас все исправим, подождите 45 минут, пожалуйста.

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