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

[Renat Fatkhullin]

fxsaber #:

Нашел - не принтовался результат выполнения функции, поэтому оптимизатор (он есть!) компилятора выкидывал то, что использоваться все равно не будет. Исправил исходник. Второй вариант все равно аутсайдер.

В общем, вывод такой, что в компиляторе оптимизатор есть, но вот с такой простой задачей не справляется.

Рекомендую проверить наличие в своих исходниках "второго варианта" (или, что еще хуже, "четвертого") и устранить его. Как быстро проверить - непонятно.

Как указали выше, все ваши затраты в необоснованных с вашей стороны копированиях структуры, которую компилятор не имеет права выкинуть.

Забудьте про const и ваше понимание языка программирования здорово улучшится. Const не влияет на оптимизацию в C++ языке. Это массовое заблуждение.

[fxsaber]

Renat Fatkhullin #:

Const модификаторы в C/С++ подобных языках сделаны для контроля случайных модификаций программистами + по мелочи.

Использую ради самоконтроля. Сильно выручало иногда. Даже на начальном этапе архитектуры const-модификаторы могут подсказать, что не до конца продумано что-то.

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

Спасибо, буду знать. Надеюсь, подтянется и MQL5.

[fxsaber]

Renat Fatkhullin #:

Как указали выше, все ваши затраты в необоснованных с вашей стороны копированиях структуры, которую компилятор не имеет права выкинуть.

Компилятор иногда много всего выкидывает. Почему здесь не может сделать оптимально, так и не понял.

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

И странно, что третий медленнее первого.

[Renat Fatkhullin]

fxsaber #:

Использую ради самоконтроля. Сильно выручало иногда. Даже на начальном этапе архитектуры const-модификаторы могут подсказать, что не до конца продумано что-то.

Спасибо, буду знать. Надеюсь, подтянется и MQL5.

В MQL5 это вовсю используется.

Вы зря думаете, что у нас недостаточная оптимизация.

[Renat Fatkhullin]

fxsaber #:

Компилятор иногда много всего выкидывает. Почему здесь не может сделать оптимально, так и не понял.

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

И странно, что третий медленнее первого.

Потому, что это неведомый объект с неизвестным поведением в отличие от простых типов.

Это простой тип типа int можно как угодно вертеть и оптимизировать. А объект/структуру он обязан скопировать.

Для информации: string - это тоже сложный объект.

[lynxntech]

Renat Fatkhullin #:

Потому, что это неведомый объект с неизвестным поведением в отличие от простых типов.

Это простой тип типа int можно как угодно вертеть и оптимизировать. А объект/структуру он обязан скопировать.

Для информации: string - это тоже сложный объект.

Ренат, интересует вопрос как раз по string, индикатор шпион можно передать по int и string-название символа,

если через int, сейчас передаю номер символа через int, а внутри функции уже из структуры берется название символа,

вопрос может запутан, если сразу можете дать рекомендацию

---

add

т.е. сразу передать в функцию название символа, или через int и внутри функции получить из структуры

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

[fxsaber]

Renat Fatkhullin #:

Потому, что это неведомый объект с неизвестным поведением в отличие от простых типов.

Разве штатные сложные типы (MqlTradeRequest, string) неизвестны? Если в кастомной структуре нет операторов и конструктора с деструктором, то что там может мешать?

Вроде, c PSO-структурами все отлично. Например, MqlTick.

Из Документации:

//--- теперь выведем первые 100 тиков последнего дня
   int counter=0;
   for(int i=0;i<ticks;i++)
     {
      datetime time=tick_array[i].time;
      if((time>=startday) && (time<endday) && counter<100)
        {
         counter++;
         PrintFormat("%d. %s",counter,GetTickDescription(tick_array[i]));
        }
     }

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

[Renat Fatkhullin]

fxsaber #:

Разве штатные сложные типы (MqlTradeRequest, string) неизвестны? Если в кастомной структуре нет операторов и конструктора с деструктором, то что-там может мешать?

Вроде, c PSO-структурами все отлично. Например, MqlTick.

Из Документации:

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

Вы невнимательно читаете мои объяснения. 

Компиляторы еще не научились(да это и бред) анализировать графы использования каждого поля в любом инстансе объекта, чтобы оптимизировать "копирование только нужного", "переупаковке(а этого вы тоже захотите)" и "вызову только нужного" у конкретного инстанса объекта.

По простой причине - это породит комбинаторный взрыв в миллионы раз бОльшие расходы. Компиляторы С++ даже сейчас задыхаются и самоограничиваются на глобальной оптимизации результирующего файла.

Поэтому остается одна схема "объект не меняет формы и методов", его конструируют/копируют полноценно(если разработчик не реализовал экономные методы конструкторов/копирования) и оптимизация в этом месте конструирования/копирования сильно ограничена.

[Renat Fatkhullin]

Грубо - все, что сложнее скалярного числа, является сложным объектом.

Любые встроенные структуры вне зависимости от их PODнутости - сложные и неизвестные объекты, не имеющие преимуществ. Разве что скопировать POD одной командой memcpy можно. Объяснение выше.

Datetime - это простой uint64, который отлично оптимизируется.

[fxsaber]

Renat Fatkhullin #:

Спасибо за подробности. Тогда точно надо искать слабые места. Просьба все же ускорить историю.