Errores, fallos, preguntas - página 1573

[Alexey Navoykov]

Anton Zverev:

Un proyecto de 100Kb de código fuente se compila en menos de un segundo en la compilación 1325. POO sólida, muchas funciones virtuales y sobrecargas, plantillas, punteros, modificador const (siempre que sea posible). Sin DLL y OpenCL.

Me gustaría averiguar la razón de sus retrasos. Tal vez sea la const que ayuda al compilador a optimizar rápidamente. Nunca he encontrado retrasos. Por favor, facilítame el código fuente de kodobase que se está ralentizando.

Bueno, 100 Kb es demasiado, ¿no? Yo tengo casi 1 Mbyte. Todo lo mismo que tú está presente aquí más un montón de macros. Excepto que la const no se establece en todas partes. Pero eso no es razón para tales retrasos locos, sobre todo porque todo compilado casi al instante en la construcción 1159.

No puedo hacer pruebas en la build 1325 porque el proyecto no compila en absoluto y aparecen un montón de bugs, todos por la noche. El compañero A100 también ha informado de un montón de bugs en la nueva build. No tengo ganas de perder el tiempo hurgando en estos bugs, esperaré a que lancen la build funcional.

Por eso te comenté lo de los lags refiriéndome a la build 1241. Si tienes la oportunidad de probarla, intenta compararla con la última build. Pero dudo que la nueva build pueda acelerar significativamente. Al contrario, los desarrolladores de MT no se preocupan realmente por la velocidad de compilación, sólo quieren exprimir nanosegundos adicionales del tiempo de ejecución para poder hacer afirmaciones de marketing sobre la velocidad de los programas MQL que son comparables con C++ (aunque sólo en algunos ejemplos abstractos).Por lo que tengo entendido, no les importa la eficiencia de la optimización, es decir, si el juego merece la pena.

Intentaré buscar el código fuente en la base de código, pero no necesariamente conseguiré encontrar uno similar. Debe ser un proyecto grande, mientras que allí la mayoría de los proyectos pequeños están disponibles abiertamente.

[Alexey Navoykov]

Renat Fatkhullin:

Lo más probable es que tenga funciones gigantes en forma de carretes de texto.

El optimizador tiene que hacer muchas pasadas a esos fragmentos de código mejorando el código una y otra vez. Basta con reducir el tamaño de las funciones para que el optimizador aumente drásticamente la velocidad.

Pues bien, debes cambiar a las últimas builds ya que estamos mejorando constantemente tanto la calidad como la velocidad en ellas.

No hay funciones gigantescas. 150 líneas como máximo (¿o se considera gigantesco?). Y si lo piensas así, ¿por qué el tamaño de una función tiene que ver con que el compilador pruebe un montón de funciones pequeñas? Supongamos que pasa por la función grande 10 veces.Así que la divido en 5 pequeñas y pasa por cada una de ellas 2 veces. Obtenemos el mismo resultado. Así que, la cantidad total de código es importante, ¿no? Pero aunque el resultado se acelere un poco al dividir las funciones grandes, ¿y qué? Estamos hablando de una compilación 10 (!) veces más lenta.

Está claro que se quiere acelerar al máximo la ejecución del programa, por lo que se hacen muchas pasadas intentando mejorar algo. Y cuanto más se complique el lenguaje, más largas serán estas pasadas, lo que consumirá el tiempo del programador. Y hay una pregunta natural sobre la eficiencia de todo esto: ¿cuánto más rápido se acelera el programa con su optimización en comparación con el tiempo de inactividad del programador esperando a que se complete la optimización?

Por supuesto, puedes intentar buscar algunos compromisos pero es mucho más eficiente hacer diferentes modos de compilación como escribí arriba. La liberación del programa con todas las optimizaciones es necesaria sólo al final - el 99% del tiempo de los programadores se gasta en escribir y depurar el código cuando no necesitan sus optimizaciones en absoluto.

[Vasiliy Sokolov]

Alexey Navoykov:

Hasta cuándo va a durar que después de cada actualización de compilación los códigos dejan de compilar! Y si compilan, no funcionan igual que antes (lo que es aún peor) ¿Quién necesita un lenguaje de programación así?

...

No sé a qué te refieres. Tengo varios proyectos muy complejos en MQL con más de 20 000 000 líneas de código. Las nuevas construcciones pueden ser compiladas en poco tiempo. Sólo ha habido dos problemas en todo este tiempo. Una vez por un error mío y la otra por un error del desarrollador.

[Vasiliy Sokolov]

Alexey Navoykov:

Un máximo de 150 líneas

Esta es una función muy grande e incorrecta.

[Alexey Navoykov]

Vasiliy Sokolov:
No sé a qué te refieres. Tengo varios proyectos muy complejos en MQL con un tamaño de código de más de 20 000 000 líneas. Las nuevas construcciones se compilan en un abrir y cerrar de ojos. Sólo ha habido dos problemas en todo este tiempo. Una vez por un error mío y la otra por un error del desarrollador.

Bueno, entonces tienes suerte. Tu código no tiene ninguna de las construcciones de mi código. ¿Qué tiene de extraño?

Si el hombre de arriba hojea un par de páginas, también ha detectado un montón de fallos en la nueva versión, algunos de los cuales son difíciles de detectar. ¿Crees que los buscaba a propósito?

[Renat Fatkhullin]

Alexey Navoykov:

Bueno, entonces tienes suerte. Tu código no tiene ninguna de las construcciones de mi código. ¿Qué tiene de extraño?

Si se hojea un par de páginas más arriba, el hombre que está allí también captó un montón de errores en la nueva construcción, algunos de los cuales son difíciles de captar. ¿Crees que los buscaba a propósito?

Demuestra un ejemplo de freno rejugable, por favor.

Desgraciadamente, hasta ahora está haciendo afirmaciones sin fundamento, incluyendo ataques directos a los desarrolladores.

Te equivocas en cuanto al tamaño de las funciones y el tamaño total del programa. El tamaño de las funciones individuales influye directamente y de forma no lineal en la optimización de cada función en particular debido tanto al aumento del árbol sintáctico como a la optimización de varias pasadas. Las funciones más pequeñas se optimizan sobre la marcha.

[Vasiliy Sokolov]

Alexey Navoykov:

Bueno, entonces tienes suerte. Tu código no tiene ninguna de las construcciones de mi código. ¿Qué tiene de extraño?

El hombre también ha detectado un montón de errores en la nueva construcción, algunos de los cuales son difíciles de detectar. ¿Crees que los buscaba a propósito?

1) Me pregunto qué construcciones has utilizado que mi código no las contiene. ¿El tamaño de mi código es de muchos miles de líneas y sus construcciones no existen? Seguramente debe ser algo súper único.

2) En realidad, había un error interno del compilador en la compilación anterior que se produce cuando las clases se enlazan entre sí. Era un error de los desarrolladores pero lo han arreglado. No recuerdo ningún otro error.

[A100]

Vasiliy Sokolov:

2) De hecho, la compilación anterior tenía un error interno del compilador que se produce cuando las clases se enlazan entre sí. Se trata de un error del equipo de desarrollo, pero se ha solucionado. No recuerdo ningún otro error.

https://www.mql5.com/ru/forum/1111/page1591#comment_2463820

¿Y dónde está la vinculación mutua de las clases entre sí?

Lo he simplificado aún más aquí para que te resulte más cómodo buscar referencias mutuas y entender qué construcciones no estás utilizando

[Vasiliy Sokolov]

A100:

https://www.mql5.com/ru/forum/1111/page1591#comment_2463820

¿Y dónde está aquí la referencia mutua de las clases entre sí?

Aquí lo he simplificado aún más, para facilitarte la búsqueda de referencias recíprocas y entender qué construcciones no estás utilizando

Estás haciendo ingeniería inversa. El trabajo es útil para mejorar el compilador, pero en términos de programación práctica no es aplicable. No conozco a ningún programador que utilice el código que has citado en la práctica:

//+------------------------------------------------------------------+
//|                                                      Test116.mq5 |
//|                                                                  |
//+------------------------------------------------------------------+
bool is( const string type, bool )
{
        return ( type == "1" || type == "2" || type == "3" || type == NULL );
}
bool _is( string type ) { return is( type, false ); }
//+------------------------------------------------------------------+
template<typename T>
bool __is( T ) { return _is( typename( T )); }
//+------------------------------------------------------------------+
#define  IS( T )         __is( T(0))
//+------------------------------------------------------------------+
template<typename T>
int sh( T t )
{
        T tt = 0x1;
        for ( int i = 0; i < 4; i++, tt <<= 1 )
                if ( (t & tt) == tt )
                        return i;
        return -1;
}
//+------------------------------------------------------------------+
class D { public:
template<typename T1, typename T2>                                     
                        T2                              g( T1 t1, T2, int sh = -1 ); 
};                                                                     
template<typename T1, typename T2>                                     
T2 D::g( T1 t1, T2, int sh )
{                                                                      
        sh = sh( t1 );                                   
        T2 t2 = T2(t1) >> 1;
        return (sh( t1 ) & sh) == sh( t1 ) && IS( T2 ) ? 1 : 0;
}                                                                      
//+------------------------------------------------------------------+
class M : public D {
        virtual void f1() { g( 0, 0 ); }
};
//+------------------------------------------------------------------+
class A {};
void g( A* ) export {}
class B { public:
        void h() { A a; g( &a ); }
};
class C { public:
        void f() {}
};
void OnStart()
{
        C c;
        c.f();
}
//+------------------------------------------------------------------+

[Alexey Navoykov]

Renat Fatkhullin:

Demuestre un ejemplo de freno reproducible, por favor.

Lamentablemente, hasta ahora está haciendo declaraciones sin fundamento, incluyendo ataques directos a los desarrolladores...

Te dije que este es un proyecto grande, el tamaño total de todo el código fuente es de aproximadamente 1 Mb. ¿Cómo se puede demostrar los frenos? Enviar todo el código o qué? Usted entiende que esto es imposible. Y la compilación de piezas individuales, por supuesto, va mucho más rápido.

¿Y a qué te refieres con "afirmaciones sin fundamento"? ¿Que tu compilador optimizador es mucho más lento? ¿Y que no te importa mucho? ¿Qué es lo que no tiene fundamento aquí?

Aquí hay un enlace a una discusión de octubre del año pasado cuando acaba de introducir esta optimización global: https://www.mql5.com/ru/forum/1111/page1424#comment_1981722

El hombre escribe:

Otro código - nota el tiempo - debe haber subido por un factor de 20

Y luego respondes:

Este es un nuevo compilador de optimización para MQL5 (está ausente en MQL4).

Hay que pagar por un mejor código de destino con mayor tiempo de compilación.

Pero tus respuestas parecen sugerir que sólo te importa la "mejor calidad del código de destino" y un mítico "aumento de la velocidad de 2 a 10 veces", aunque no he visto tales aumentos de velocidad en proyectos reales de trabajo.

Como dije arriba, no pude probarlo en la última build (22 de abril) porque tuve algunos errores durante la compilación, pero supongo que la velocidad de compilación es igual de lenta allí, ya que nunca han anunciado la aceleración del compilador en la nueva build.