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

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

Во втором случае присутствует косвенный доступ через ссылку, что при микроскопическом теле цикла закономерно занимает половину времени, увеличивая его вдвое.
Документация по MQL5: Основы языка / Типы данных / Структуры и классы
Документация по MQL5: Основы языка / Типы данных / Структуры и классы
  • www.mql5.com
Основы языка / Типы данных / Структуры и классы - Документация по MQL5
 
Тест несколько некорректный, по сути сравнивающий разницу между одной ассемблерной инструкцией и двумя ассемблерными инструкциями, помещенными в стомиллионный цикл.
 
Renat:
По моему, тут как раз налицо оптимизация первого случая прямого доступа к члену объекта.

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

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

то есть на самом деле имеем не просто один arr объект, а массив сложных объектов (тоже с массивами).

примерно это можно записать в схему как

class A
{
  double prm1;
  int prm2;
  string prm3;
  char prm4;
}

class B
{
   A m_a[1000];
}

B _b[1000];



Я рассуждал, что если получить ссылку на конкретный элемент массива А

А *item=GetPointer(_b[i]._a[j]);

то работа с параметрами A::prmX  будет происходить бустрее.


Но получилось, что тягание колбасы из имён массивов

_b[i]._a[j].prmX  

будет работать быстрее минимум в два раза, нежели обращение к конкретному item.

Меня это немного удивило, и стало понятно, что в ядре происходит получения некоего псевдоуказателя.

Можно ли как то оптимизировать скорость, что хотя бы уменьшить разницу в скорости?

 
sergeev:

вот так будет без ошибок

В данном тесте так не будет ошибок. Но этот способ не решает основой вопрос: почему компилятор пропускает преобразование константной ссылки объект в не константную ссылку ни выдавая ни каких ошибок и/или предупрежедений. Если это такая фича, то вопросов нет, но при этом теряется смысл модификатора const для возвращаемого типа в сигнатуре методов класса.
 
mvk:
В данном тесте так не будет ошибок. Но этот способ не решает основой вопрос: почему компилятор пропускает преобразование константной ссылки объект в не константную ссылку ни выдавая ни каких ошибки и/или предупрежедений. Если это такая фича, то вопросов нет, но при этом теряется смысл модификатора const для возвращаемого типа в сигнатуре методов класса.

по моему все логично.

функции константного объекта не должны менять сам объект, следовательно они тоже должны иметь модификатор const

а по поводу 

   //Ошибки нет. Это НЕ правильно(CONST A* B::getA())!
   A* a2 = b.getA();

таки да, в С++  такое не допустится. будет ошибка.

отпишите в сервисдеск.

 
sergeev:

Но получилось, что тягание колбасы из имён массивов

будет работать быстрее минимум в два раза, нежели обращение к конкретному item.

Реально получилось быстрее или это логическое построение вывода на основе других более простых случаев?

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


Меня это немного удивило, и стало понятно, что в ядре происходит получения некоего псевдоуказателя.

Указателей в обычном понимании в MQL5 нет, это хендлы со всеми вытекающими последствиями.


Можно ли как то оптимизировать скорость, что хотя бы уменьшить разницу в скорости?

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

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

Документация по MQL5: Основы языка / Переменные
Документация по MQL5: Основы языка / Переменные
  • www.mql5.com
Основы языка / Переменные - Документация по MQL5
 
Renat:

Реально получилось быстрее или это логическое построение вывода на основе других более простых случаев?

да, все вполне реально. тестировал на заполнении своих массивов. всегда получалось медленнее в два раза.

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

ну, схему его проведения и образ класса А, В и массивы выложил. 


Особенно с учетом наличия откровенно дорогой дополнительной функции GetPointer.

она вызывается один раз перед входом в цикл. но в принципе для более точного теста можно её также вынести за пределы GetTickCount

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

ок. спасибо. это и нужно.

 
sergeev:

она вызывается один раз перед входом в цикл. но в принципе для более точного теста можно её также вынести за пределы GetTickCount

А как вне цикла, если код такой?
А *item=GetPointer(_b[i]._a[j]);
 
Пожелание. Можно ли в справку включить возможность увеличения масштаба текста. напр. + или - , или Ctrl+колёсико мышки.
 
paladin800:
Пожелание. Можно ли в справку включить возможность увеличения масштаба текста. напр. + или - , или Ctrl+колёсико мышки.

Скорей всего это невозможно. А онлайн версия не подходит?

Вот что нашел в интернете на эту тему - http://forum.ru-board.com/topic.cgi?forum=62&topic=20907

UPDate Еще http://forum.ixbt.com/topic.cgi?id=23:39211

Невозможно изменить размер шрифта при просмотре .CHM файлов. :: Microsoft Windows :: Компьютерный форум Ru.Board
  • forum.ru-board.com
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Причина обращения: