Erreurs, bugs, questions - page 816

[Renat Fatkhullin]

A mon avis, il s'agit juste d'une optimisation du premier cas d'accès direct à un membre de l' objet.

Dans le second cas, il y a un accès indirect par référence, qui dans un corps de boucle microscopique prend naturellement la moitié du temps, le doublant.

[Renat Fatkhullin]

Le test est quelque peu incorrect, comparant essentiellement la différence entre une seule instruction assembleur et deux instructions assembleur placées dans une centaine de millions de boucles.

[---]

Renat:
Je pense qu'il s'agit simplement d'une optimisation du premier cas d'accès direct à un membre de l' objet.

Dans le second cas, nous avons un accès indirect par référence qui prend naturellement la moitié du temps avec un corps de boucle microscopique qui le multiplie par deux.

Renat, en réalité il y a le traitement de grands tableaux de données. J'ai déjà simplifié le test, juste pour montrer la zone problématique. Au départ, je l'ai créé en utilisant mes propres tableaux et classes. Puis je l'ai réduit à un schéma.

c'est-à-dire que nous n'avons pas réellement un seul objet arr, mais un tableau d'objets complexes (également avec des tableaux).

En gros, cela peut s'écrire dans le schéma comme suit

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

class B
{
   A m_a[1000];
}

B _b[1000];

Je me suis dit que si j'obtiens une référence à un élément particulier du tableau A

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

Le travail avec les paramètres A::prmX sera plus rapide.

Mais il s'avère que tirer une saucisse à partir de noms de tableaux

_b[i]._a[j].prmX  

serait au moins deux fois plus rapide que de se référer à un élément particulier.

J'ai été un peu surpris par cela, et il est clair que le noyau reçoit une sorte de pseudo-pointeur.

Existe-t-il un moyen d'optimiser la vitesse, qui permette au moins de réduire la différence de vitesse ?

[mvk]

sergeev:

c'est ainsi qu'il sera sans erreurs

Il n'y aura pas d'erreurs dans ce test. Mais cette méthode ne résout pas la question principale : pourquoi le compilateur saute-t-il la transformation d'une référence d'objet constante en une référence non constante sans générer d'erreurs et/ou d'avertissements ? S'il s'agit d'une telle fonctionnalité, aucune question, mais dans ce cas, la signification du modificateur const pour le type retourné dans la signature des méthodes de classe est perdue.

[---]

mvk:
Il n'y aura pas d'erreur de cette manière dans ce test. Mais cette méthode ne résout pas la question principale : pourquoi le compilateur saute-t-il la transformation d'une référence objet constante en une référence non constante et ne génère-t-il aucune erreur et/ou avertissement ? Si c'est une telle fonctionnalité, pas de questions, mais dans ce cas, la signification du modificateur const pour le type retourné dans la signature des méthodes de la classe est perdue.

tout a un sens pour moi.

Les fonctions constantes de l'objet ne doivent pas modifier l'objet lui-même, elles doivent donc avoir un modificateur const.

et sur

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

Eh bien, oui, cela ne fonctionnera pas en C++.

Écrivez à Servicedesk.

[Renat Fatkhullin]

sergeev:

Mais il s'avère que tirer une saucisse à partir de noms de tableaux

sera au moins deux fois plus rapide que l'accès à un élément spécifique.

Est-ce vraiment plus rapide ou est-ce une construction logique de la sortie basée sur d'autres cas plus simples ?

A mon avis, une preuve propre basée sur l'accès présenté à un tableau multidimensionnel n'a pas encore été présentée. Surtout compte tenu de la présence de la fonction supplémentaire GetPointer, franchement coûteuse.

Cela m'a un peu surpris, et il est devenu clair qu'il y a une sorte de pseudo-indexation dans le noyau.

Les pointeurs au sens conventionnel n'existent pas dans MQL5, ce sont des handles, avec toutes leurs conséquences.

Existe-t-il un moyen d'optimiser la vitesse, qui permettrait au moins de réduire la différence de vitesse ?

Nous travaillons constamment à l'optimisation, mais dans le cas des références/manches, il y a une surcharge du système sur l'accès indirect.

Quoi qu'il en soit, examinons de plus près l'optimisation de cet accès.

[---]

Renat:

Est-ce vraiment plus rapide ou est-ce une construction logique de la conclusion basée sur d'autres cas plus simples ?

oui, c'est assez réaliste. je l'ai testé en remplissant mes tableaux. c'était toujours deux fois plus lent.

A mon avis, une preuve propre basée sur l'accès au tableau multidimensionnel présenté n'a pas encore été présentée.

Bien, j'ai exposé le schéma et une image des classes A, B et des tableaux.

Surtout avec la fonction supplémentaire GetPointer, franchement coûteuse.

elle est appelée une fois avant d'entrer dans une boucle. mais en principe, pour un test plus précis, vous pouvez aussi la prendre en dehors de GetTickCount

Quoi qu'il en soit, nous allons examiner de plus près l'optimisation de ces accès.

OK. Merci. C'est exactement ce dont nous avons besoin.

[Renat Fatkhullin]

sergeev:

elle est appelée une fois avant d'entrer dans la boucle. mais en principe, pour un test plus précis, vous pourriez aussi la prendre en dehors de GetTickCount

Et en dehors de la boucle si le code est comme ceci ?

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

[Maxim Khrolenko]

Une suggestion. La fonction de zoom du texte peut-elle être incluse dans l'aide, par exemple + ou - , ou Ctrl+molette de la souris.

[Rashid Umarov]

paladin800:
Une suggestion. La fonction de zoom du texte peut-elle être incluse dans l'aide ? Par exemple, + ou - , ou Ctrl+molette de la souris.

Ce n'est probablement pas possible. La version en ligne ne convient-elle pas ?

Voici ce que j'ai trouvé sur Internet à ce sujet - http://forum.ru-board.com/topic.cgi?forum=62&topic=20907.

UPDate Plus http://forum.ixbt.com/topic.cgi?id=23:39211