Errores, fallos, preguntas - página 816

[Renat Fatkhullin]

En mi opinión, esto es sólo una optimización del primer caso de acceso directo a un miembro del objeto.

En el segundo caso hay un acceso indirecto por referencia, que en un cuerpo de bucle microscópico naturalmente toma la mitad del tiempo, duplicándolo.

[Renat Fatkhullin]

La prueba es algo incorrecta, ya que esencialmente compara la diferencia entre una sola instrucción de ensamblador y dos instrucciones de ensamblador colocadas en cien millones de bucles.

[---]

Renat:
Creo que esto es sólo una optimización del primer caso de acceso directo a un miembro del objeto.

En el segundo caso, tenemos un acceso indirecto por referencia que, naturalmente, tarda la mitad de tiempo, con un cuerpo de bucle microscópico que lo multiplica por dos.

Renat, en realidad hay grandes matrices de datos que se procesan. Ya he simplificado la prueba, sólo para mostrar el área del problema. Inicialmente la creé usando mis propios arrays y clases. Luego lo reduje a un esquema.

es decir, no tenemos realmente un solo objeto arr, sino un array de objetos complejos (también con arrays).

a grandes rasgos esto se puede escribir en el esquema como

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

class B
{
   A m_a[1000];
}

B _b[1000];

Razoné que si obtengo una referencia a un elemento particular del array A

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

El trabajo con los parámetros A::prmX será más rápido.

Pero resulta que sacar una salchicha de los nombres de las matrices

_b[i]._a[j].prmX  

sería al menos el doble de rápido que referirse a un elemento concreto.

Me sorprendió un poco esto, y está claro que el núcleo está recibiendo algún tipo de pseudo-puntero.

¿Hay alguna forma de optimizar la velocidad, que al menos reduzca la diferencia de velocidad?

[mvk]

sergeev:

así será sin errores

No habrá errores en esta prueba. Pero este método no resuelve la cuestión principal: ¿por qué el compilador se salta la transformación de una referencia de objeto constante a una referencia no constante sin generar ningún error y/o advertencia? Si es una característica de este tipo, no hay preguntas, pero en este caso se pierde el significado del modificador const para el tipo devuelto en la firma de los métodos de la clase.

[---]

mvk:
No habrá ningún error en este sentido en esta prueba. Pero este método no resuelve la cuestión principal: ¿por qué el compilador omite la transformación de una referencia constante a un objeto en una referencia no-const y no genera ningún error y/o advertencia? Si es una característica así, no hay preguntas, pero en este caso se pierde el significado del modificador const para el tipo devuelto en la firma de los métodos de la clase.

todo tiene sentido para mí.

Las funciones constantes del objeto no deben cambiar el objeto en sí, por lo que también deben tener un modificador const

y sobre

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

bueno, sí, eso no funcionará en C++.

Escribe a servicedesk.

[Renat Fatkhullin]

sergeev:

Pero resulta que sacar una salchicha de los nombres de las matrices

será al menos el doble de rápido que acceder a un elemento específico.

¿Es realmente más rápido o es una construcción lógica de la salida basada en otros casos más simples?

En mi opinión, todavía no se ha presentado una prueba limpia basada en el acceso presentado a una matriz multidimensional. Sobre todo teniendo en cuenta la presencia de la francamente cara función adicional GetPointer.

Me sorprendió un poco, y quedó claro que hay algún tipo de pseudopuntero que entra en el núcleo.

Los punteros en el sentido convencional no existen en MQL5, son handles, con todas sus consecuencias.

¿Hay alguna forma de optimizar la velocidad, que al menos reduzca la diferencia de velocidad?

Trabajamos constantemente en la optimización, pero en el caso de las referencias/manipulaciones hay una sobrecarga del sistema en el acceso indirecto.

De todos modos, vamos a analizar más detenidamente la optimización de dicho acceso.

[---]

Renat:

¿Es realmente más rápido o es una construcción lógica de la conclusión basada en otros casos más simples?

Sí, es bastante realista. Lo probé al llenar mis matrices. siempre fue el doble de lento.

En mi opinión, todavía no se ha presentado una prueba limpia basada en el acceso a matrices multidimensionales presentado.

Bueno, he puesto el esquema y una imagen de las clases A, B y arrays.

Especialmente con la francamente cara función adicional GetPointer.

se llama una vez antes de entrar en un bucle. pero en principio, para una prueba más precisa, también se puede tomar fuera de GetTickCount

En cualquier caso, vamos a ver más de cerca la optimización de dicho acceso.

Bien. Gracias. Eso es exactamente lo que necesitamos.

[Renat Fatkhullin]

sergeev:

se llama una vez antes de entrar en el bucle. pero en principio, para una prueba más precisa, también se podría tomar fuera de GetTickCount

¿Qué tal fuera del bucle si el código es así?

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

[Maxim Khrolenko]

Una sugerencia. ¿Se puede incluir la función de zoom del texto en la ayuda, por ejemplo, + o - , o Ctrl+rueda del ratón.

[Rashid Umarov]

paladin800:
Una sugerencia. ¿Se puede incluir la función de zoom de texto en la ayuda, por ejemplo, + o - , o Ctrl+rueda del ratón?

Probablemente no sea posible. ¿No es adecuada la versión online?

Esto es lo que he encontrado en Internet sobre el tema - http://forum.ru-board.com/topic.cgi?forum=62&topic=20907

UPDate Más http://forum.ixbt.com/topic.cgi?id=23:39211