Errores, fallos, preguntas - página 1952

Nuevo comentario
 
Stanislav Korotky:

El compilador no ayuda aquí - probado - el objeto local por el retorno es duplicado y luego clavado. No hay un movimiento óptimo en este caso.


¿Has realizado pruebas de velocidad? ¿O sólo el diagnóstico de la creación de objetos? Si es lo segundo, por supuesto que no se eliminará nada del código, porque tú mismo lo impides con tus comprobaciones.

 
Alexey Navoykov:


¿Has realizado pruebas de velocidad? ¿O sólo está diagnosticando el hecho de la creación de objetos? Si es esto último, por supuesto que no se cortará nada del código ya que tú mismo lo impides con tus comprobaciones.

¿Cómo es eso? Todas mis comprobaciones consisten únicamente en las trazas establecidas en los constructores y destructores. Si se crean y eliminan copias adicionales, eso es prueba suficiente para mí de que no hay optimización.

 
Alexey Navoykov:


¿Ha realizado pruebas de medición de la velocidad? ¿O simplemente diagnosticar el hecho de la creación de objetos? Si es lo segundo, por supuesto que no se cortará nada del código, porque tú mismo lo impides con tus comprobaciones.

Si no puedes mover líneas, no puedes mover objetos más complejos.

 
Stanislav Korotky:

¿Cómo es eso? Todas mis comprobaciones consisten únicamente en las trazas establecidas en los constructores y destructores. Si se crean y eliminan copias adicionales, para mí eso es prueba suficiente de la falta de optimización.

El optimizador no puede arrancar un fragmento que contenga su rastro). Sólo se pueden recortar las cosas que no afectan a su lógica.
 

Ahora en OnTesterInit puede establecer rangos de optimización para cada parámetro de entrada. El probador genera entonces una tabla de pases por sí mismo, la divide en el número de Agentes/Paquetes y la envía a los Agentes. Esta tabla no es editable de ninguna manera ahora.

Pero durante la optimización es realmente muy común preocuparse primero por los pases en los que cambia algún parámetro importante, luego en los que cambia otro, etc. Si fuera posible editar una tabla de pases generada (para cambiar los lugares de los elementos (conjuntos de parámetros de entrada)) o generarla uno mismo, sería posible establecer la prioridad necesaria, cuando los pases más interesantes irían a Agentes primero, y luego - los pases menos interesantes.


Por ello propongo añadir a OnTesterInit la posibilidad de cambiar la tabla de pases por defecto:

long PassesTotal(); // количество проходов в таблице для Оптимизации

// Получает список входных параметров соответствующего прохода
int PassesGet( const int Index,  MqlParam& Parameters[] );


// Прописывает список входных параметров для соответствующего прохода,
// если индекс не меньше размера таблицы, то идет дозапись в конец таблицы и размер ее увеличивается на единицу
int PassesSet( const int Index, const MqlParam& Parameters[] );
 
Alexey Navoykov:
El optimizador no podrá cortar la sección con su rastro en ella ) Lo único que se puede recortar es lo que no interfiere con su lógica.

Bueno, el tema ha terminado ;-). Creo que la optimización en este caso podría ocurrir sólo en ese lugar del código donde se produce el valor de retorno, y de ninguna manera depende de lo que está escrito en el constructor.

Norma C++11: Cuando se cumplen ciertos criterios, se permite a una implementación omitir la construcción de copia/movimiento de un objeto de clase, incluso si el constructor de copia/movimiento y/o el destructor del objeto tienen efectos secundarios. En estos casos, la implementación trata el origen y el destino de la operación de copia/movimiento omitida simplemente como dos formas diferentes de referirse al mismo objeto, y la destrucción de ese objeto se produce en el momento posterior en el que los dos objetos se habrían destruido sin la optimización.

 
Stanislav Korotky:

Bueno, el tema ha terminado ;-). En mi opinión, la optimización en este caso sólo podría tener lugar en el lugar del código donde se produce la devolución del valor, y no depende en absoluto de lo que se escriba en el constructor.

De todos modos, debo admitir con pesar que el compilador MQL está lejos de ser tan inteligente como yo pensaba ) Incluso diría que no es nada inteligente. ) Intenté hacer algunos ejemplos sencillos y resultó que incluso si creo un objeto ficticio, que no se usa en ninguna parte y no hace nada, el compilador no se preocupa por él. No está optimizado en absoluto. Estoy juzgando sólo por la velocidad. Y por alguna razón funciona más lentamente en las nuevas construcciones que en las antiguas.

Aquí hay un código trivial:

class A { };

void OnStart()
  {
    uint starttick= GetTickCount();
    for (int i=0; i<1 e8; i++)
    { 
      A a;
    }
    Print(GetTickCount()-starttick," ms");
  }
 
Alexey Navoykov:

Bueno, lamentablemente tengo que admitir, que el compilador MQL no es tan inteligente, como yo pensaba que era ) Incluso diría que no es nada inteligente).


¿Has pensado alguna vez que se podría ajustar para optimizar las cosas reales que utiliza la mayoría de la gente, en lugar de las tonterías que te acabas de inventar de la nada?

 
Stanislav Korotky:

Bueno, el tema ha terminado ;-). En mi opinión, la optimización en este caso sólo podría tener lugar en el lugar del código donde se produce la devolución del valor, y en ningún caso depende de lo que se escriba en el constructor.


Sólo en 2 años se introdujeron los constructores de copias.
Los siguientes son RVO (optimización del valor de retorno) y NRVO (optimización del valor de retorno con nombre)...

 
Sergey Dzyublik:

¿Ha considerado que podría afinarse para optimizar las cosas reales que la mayoría de la gente utiliza, en lugar de las chorradas que se inventan de la nada?

¿qué es "el verdadero material que usa la mayoría de la gente"?
1...194519461947194819491950195119521953195419551956195719581959...3187
Nuevo comentario