Как расходуется память при многократном пересоздании массива в цикле? - страница 3

 
Igor Makanu:

замерил скорость:

2020.03.02 22:40:21.269 tst (EURUSD,H1) Test №1 = : loops=10000000 ms=15938

2020.03.02 22:40:37.179 tst (EURUSD,H1) Test №2 = : loops=10000000 ms=15906


т.е. варианты 1 и 2 по скорости выполнения по сути одинаковы

А я вот запустил тоже самое


А это пустой цикл, без  //array[i] = rand() % i; 


Это что получается - компиляторы разные? у меня стандартный МЕ.

 
Dmitry Fedoseev:

Единственное преимущество с++ программистов пред всем осталным миром в томю, что они почему-то непоколебимо уверены в своей неу-нной опупенности. 
Угу, ничего не выделяется не осовбождается... а если рекурсивный вызов?

Не хочется опять обидеть такую высокочувствительную личность,
но если бы вы хоть немного читали других участников форума, то могли бы узнать о рекурсивных вызовах:

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

Как расходуется память при многократном пересоздании массива в цикле?

Sergey Dzyublik, 2020.03.03 01:47

2) Перезаполнить стековую память можно просто вызвав функцию с бесконечной рекурсией.
В стеке сохраняется адрес возврата при выходе из функции - это адрес инструкции, которая будет выполнятся после выхода из функции.
В бесконечной рекурсии адрес возврата бесконечно записывается на стек, пока его не переполнит. Запущенная программа вылетает с ошибкой stack overflow.

 
Sergey Dzyublik:

Не хочется опять обидеть такую высокочувствительную личность,
но если бы вы хоть немного читали других участников форума, то могли бы узнать о рекурсивных вызовах:

А каких других? Членов клуба жертв с++? Этих читаю регулярно, ни одного поста не пропускаю)) Даже в цирк перестал ходить.

 
Aleksey Mavrin:

А я вот запустил тоже самое
Это что получается - компиляторы разные? у меня стандартный МЕ.

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

2020.03.03 10:42:26.019 ProjectSerCom (EURUSD,M5)       Test №1 = : loops=10000000 ms=45672
2020.03.03 10:43:11.932 ProjectSerCom (EURUSD,M5)       Test №2 = : loops=10000000 ms=45922

Результат показывает общую тенденцию, но не дает достоверную оценку разности времени выполнения.
Так как не учитывается множество факторов: "холодная" память, кеши процессора, ...

 
Sergey Dzyublik:

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

Он показывает общую тенденцию, а не дает достоверную оценку разности времени выполнения.
Так как не учитывается множество факторов: "холодная" память, кеши процессора, ...

Нет не отладочный, я кидаю на график скомпилированный скрипт. Пару раз проверил думал может случайная загрузка ЦП и т.п. 

Но я в МТ4 тестил, ветка же. Неужели в МТ4 что-то это настолько неоптимизировано, а в МТ5 всё норм.

 
Dmitry Fedoseev:

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

Aleksey Mavrin:

А я вот запустил тоже самое


А это пустой цикл, без  //array[i] = rand() % i; 


Это что получается - компиляторы разные? у меня стандартный МЕ.


нет

те тесты которые компилятор заоптит будут длиться 1 секунду, мои тесты по 17 секунд - там все нормально

компилятор пустые циклы умеет оптимизировать, а вот предсказывать (будут ли в дальнейшем эти данные использоваться) - не умеет ;)


Sergey Dzyublik:

Под стек выделяется память определенного размера - детали #property stacksize
Для скрипта максимальный размер стека - 64МБ, если локальные переменные требуют больше - терминал не запустит скрипт на выполнение MT5 (build 2345) и выдаст ошибку:

в MQL своеобразная модель распределения памяти

все что выяснил  (или по крайней мере, что интересовало) - ошибки переполнения стека будут если описывать глобально статические массивы, если массив динамический или статически распределенный массив описан внутри функции, то ошибка переполнения стека не появится

 
Вы так все уверены в том, чего никогда не видели и в том, чего потргать невозможно?
 
Igor Makanu:

замерил скорость:

2020.03.02 22:40:21.269 tst (EURUSD,H1) Test №1 = : loops=10000000 ms=15938

2020.03.02 22:40:37.179 tst (EURUSD,H1) Test №2 = : loops=10000000 ms=15906


т.е. варианты 1 и 2 по скорости выполнения по сути одинаковы

Запустил этот скрипт, вот результат:

2020.03.03 17:10:00.590 1 USDCHF,H1: Test ¹2 = : loops=100000 ms=5218

2020.03.03 17:09:55.369 1 USDCHF,H1: Test ¹1 = : loops=100000 ms=21000

Только сначла изменил #define LOOPx10 7 на #define LOOPx10 6, а то вообще конца не было видно, может быть в этом секрет тех 17-и секунд?

Однозначно утверждать не буду, но не представляю особой сложности компилятору определить используется результ из переменной или нет. Неиспользуемые переменные прекрасно определяются, а тут нескоько сложнее, но тем не менее... К тому же Ренат писал про это - про то, что если результаты вычислений не используется, то код выкидывается компиляторм.

 

То было в МТ4.

А теперь понятно, почему у вас тут у некторых результат одинаковый, потому что в МТ5 запускали этот скрипт. А попробуйте посмотреть на название раздела форума в котором находится эта тема.

Конечно, интересно, почему результаты так отличаются (между МТ4 и МТ5), наверно разработчики подшаманили что-то. Возможно зависит от сложности кода, результаты которого не использубются. Но я не уверен, это только здесь некоторые уверены, в том чего ни провреить ни потрогать.

 
Dmitry Fedoseev:

А попробуйте посмотреть на название раздела форума в котором находится эта тема.

Захожу в тему с главной страницы сайта и понятия не имею, что речь о МТ4.
Если специально не искать - то и не узнать.