Erros, bugs, perguntas - página 1573

[Alexey Navoykov]

Anton Zverev:

Um projecto de fonte de 100Kb compila em menos de um segundo em 1325 construídos. OOP sólido, muitas funções e sobrecargas virtuais, modelos, apontadores, modificador constante (sempre que possível). Sem DLL e OpenCL.

Gostaria de descobrir a razão dos vossos atrasos. Talvez seja constante que ajude o compilador a optimizar rapidamente. Nunca encontrei desfasamentos. Por favor, forneça-me o código fonte da kodobase que está a abrandar.

Bem, 100 Kb é demasiado, não é? Tenho quase 1 Mb. Todas as mesmas coisas que tem estão aqui presentes mais muitas macros. Mas isso não é razão para tais atrasos loucos, especialmente porque tudo compilado quase instantaneamente na construção 1159.

Não posso testar na construção 1325 porque o projecto não compila nada e um monte de insectos aparece, tudo à noite. O camarada A100 relatou um monte de insectos na nova construção também. Não tenho qualquer desejo de perder o meu tempo a mexer nestes insectos, vou esperar até que eles libertem a construção em funcionamento.

É por isso que vos falei dos atrasos referentes à construção 1241. Se tiverem a oportunidade de a testar, tentem compará-la com a última construção. Mas duvido que a nova construção possa acelerar significativamente. Muito pelo contrário, os programadores da MT não se preocupam realmente com a velocidade de compilação, apenas querem espremer nanossegundos adicionais no tempo de execução para depois fazer alegações de marketing sobre a velocidade dos programas MQL serem comparáveis com C++ (embora apenas nos exemplos abstractos).Tanto quanto sei, eles não se preocupam com a eficiência da optimização, ou seja, se o jogo vale o custo.

Vou tentar procurar o código fonte na base de códigos, mas não necessariamente que consiga encontrar um semelhante. Deve ser um grande projecto, enquanto que a maior parte dos pequenos projectos estão disponíveis abertamente.

[Alexey Navoykov]

Renat Fatkhullin:

Ele tem provavelmente funções gigantescas sob a forma de bobinas de texto.

O optimizador tem de fazer muitos passes em tais fragmentos de código melhorando o código vezes sem conta. É suficiente reduzir o tamanho das funções para que o optimizador aumente drasticamente a velocidade.

Bem, deve mudar para as construções mais recentes, uma vez que estamos constantemente a melhorar tanto a qualidade como a velocidade nelas.

Nenhuma função gigante. 150 linhas no máximo (ou é considerada gigantesca?) E se pensarmos desta forma, porque é que o tamanho de uma função tem a ver com o compilador tentar um monte de pequenas funções? Vamos supor que ela passa pela função grande 10 vezes.Por isso, parto-o em 5 pequenos e passa por cada um deles 2 vezes. Obtemos o mesmo resultado. Portanto, toda a quantidade de código é importante, certo? Mas mesmo que o resultado acelere um pouco ao partir grandes funções, e depois? Estamos a falar de uma compilação 10 (!) vezes mais lenta.

É evidente que se quer acelerar a execução do programa tanto quanto possível, pelo que se fazem muitos passes a tentar melhorar alguma coisa. E quanto mais complicar a linguagem, mais tempo esses passes serão, o que consumirá o tempo do programador. E há uma questão natural sobre a eficiência de tudo isto. Quanto mais rápido é o programa acelerado pela sua optimização em comparação com o tempo ocioso do programador à espera que a optimização esteja concluída?

Claro que pode tentar procurar alguns compromissos, mas é muito mais eficiente fazer diferentes modos de compilação como escrevi acima. O lançamento do programa com todas as optimizações é necessário apenas no final - 99% do tempo dos programadores é gasto na escrita e depuração do código quando não precisam das suas optimizações.

[Vasiliy Sokolov]

Alexey Navoykov:

Quanto tempo vai durar que depois de cada compilação os códigos parem de compilar! E se compilarem, não funcionam da mesma forma que antes (o que é ainda pior). Quem precisa de uma linguagem de programação deste tipo?

...

Não sei a que se refere. Tenho vários projectos muito complexos em MQL com mais de 20 000 000 de linhas de código. As novas construções podem ser compiladas em qualquer altura. Houve apenas duas questões durante todo este tempo. Uma vez por causa do meu bug e a outra vez devido ao bug do programador.

[Vasiliy Sokolov]

Alexey Navoykov:

Um máximo de 150 linhas

Esta é uma função muito grande e incorrecta.

[Alexey Navoykov]

Vasiliy Sokolov:
Não sei a que se refere. Tenho vários projectos muito complexos em MQL com tamanho de código de mais de 20 000 000 de linhas. As novas construções são compiladas em pouco tempo. Houve apenas duas questões durante todo este tempo. Uma vez por causa do meu bug e a outra vez devido ao bug do programador.

Bem, então tem sorte. O seu código não tem nenhuma das construções do meu código. O que há de tão estranho nisso?

Vire o homem acima de algumas páginas e lá ele também apanhou muitos insectos na nova construção, alguns dos quais são difíceis de apanhar. Acha que ele os procurava de propósito?

[Renat Fatkhullin]

Alexey Navoykov:

Bem, então tem sorte. O seu código não tem nenhuma das construções do meu código. O que há de tão estranho nisso?

Percorrendo algumas páginas acima, o homem lá também apanhou um monte de insectos na nova construção, alguns dos quais são difíceis de apanhar. Acha que ele os procurava de propósito?

Demonstrar um exemplo de um travão reprodutível, por favor.

Infelizmente, até agora tem feito declarações não fundamentadas, incluindo ataques directos aos criadores.

Está enganado acerca do tamanho das funções e do tamanho geral do programa. O tamanho das funções individuais influencia directamente e não linearmente a optimização de cada função em particular devido tanto ao aumento da árvore de sintaxe como à optimização multi-pass. As funções mais pequenas são optimizadas em tempo real.

[Vasiliy Sokolov]

Alexey Navoykov:

Bem, então tem sorte. O seu código não tem nenhuma das construções do meu código. O que há de tão estranho nisso?

folheando as páginas acima, o homem lá também apanhou um monte de insectos na nova construção, alguns dos quais são difíceis de apanhar. Acha que ele estava à procura deles de propósito?

1) Pergunto-me o que constrói que usou que o meu código não os contém. O tamanho do meu código é de muitos milhares de linhas e as vossas construções não existem? Certamente deve ser algo super único...

2) Na verdade, houve um erro interno de commpiler na construção anterior que ocorre quando as classes se ligam umas às outras. Era um bug dos criadores, mas eles corrigiram-no. Não me consigo lembrar de quaisquer outros erros.

[A100]

Vasiliy Sokolov:

2) De facto, a construção anterior teve de facto um erro interno de commpiler que ocorre quando as classes se ligam umas às outras. Isto é um bug na equipa de desenvolvimento, mas foi corrigido. Não me consigo lembrar de quaisquer outros erros.

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

E onde está a ligação mútua de classes entre si?

Simplifiquei-o ainda mais aqui para sua conveniência na procura de referências mútuas e na compreensão do que o constrói que não está a usar

[Vasiliy Sokolov]

A100:

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

E onde está a referência mútua de classes umas às outras aqui?

Simplificou-o ainda mais aqui, para a sua facilidade de procura de referências e compreensão recíprocas que o constrói não está a utilizar

Está a fazer engenharia inversa. O trabalho é útil para melhorar o compilador, mas em termos de programação prática não é aplicável. Não conheço um único programador que utilize o código que citou na prática:

//+------------------------------------------------------------------+
//|                                                      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:

Demonstrar um exemplo de um travão reprodutível, por favor.

Infelizmente, até agora está a fazer afirmações sem fundamento, incluindo ataques directos aos criadores...

Eu disse-lhe que este é um grande projecto, o tamanho total de todo o código fonte é cerca de 1 Mb. Como pode demonstrar os travões? Enviar todo o código ou quê? Compreende que isto é impossível. E a compilação de peças individuais, é claro, vai muito mais rápido.

E o que quer dizer com "alegações não substanciadas"? Que o seu compilador de optimização é muito mais lento? E que não se preocupa muito com isso? O que é que não está substanciado aqui?

Aqui está um link para uma discussão de Outubro do ano passado, quando acabou de introduzir esta optimização global: https://www.mql5.com/ru/forum/1111/page1424#comment_1981722

O homem escreve:

Outro código - note o tempo - deve ter subido por um factor de 20

E depois responde:

Este é um novo compilador de optimização para MQL5 (está ausente em MQL4).

Tem de pagar por um melhor código alvo com um tempo de compilação mais longo.

E depois há várias outras pessoas, incluindo eu próprio, que também se queixaram de uma compilação lenta. Mas as vossas respostas parecem sugerir que se preocupam apenas com "código alvo de melhor qualidade" e algum mítico "aumento de velocidade de 2 a 10 vezes", embora eu não tenha visto tais aumentos de velocidade em projectos de trabalho reais.

Como disse acima, não consegui testá-lo na última compilação (datada de 22 de Abril) porque tive alguns bugs durante a compilação. Mas presumo que a velocidade de compilação seja a mesma lenta, pois nunca se anunciou a aceleração do compilador na nova compilação.