Errori, bug, domande - pagina 1573

[Alexey Navoykov]

Anton Zverev:

Un progetto sorgente di 100Kb si compila in meno di un secondo su 1325 build. OOP solida, molte funzioni virtuali e sovraccarichi, modelli, puntatori, modificatori const (dove possibile). Nessuna DLL e OpenCL.

Vorrei scoprire la ragione dei vostri ritardi. Forse è una costrizione che aiuta il compilatore a ottimizzare rapidamente. Non ho mai riscontrato lag. Vi prego di fornirmi il codice sorgente di kodobase che sta rallentando.

Beh, 100 Kb sono troppi, no? Io ho quasi 1 Mbyte. Tutta la stessa roba che hai tu è presente qui, più un sacco di macro. A parte il fatto che const non è impostato ovunque, ma questo non è un motivo per questi ritardi pazzeschi, soprattutto perché tutto è stato compilato quasi istantaneamente nella build 1159.

Non posso testare nella build 1325 perché il progetto non si compila affatto e appaiono un mucchio di bug, tutti di sera. Il compagno A100 ha riportato un mucchio di bug anche nella nuova build. Non ho voglia di perdere tempo a frugare in questi bug, aspetterò finché non rilasceranno la build funzionante.

Questo è il motivo per cui ti ho parlato dei lag riferiti alla build 1241. Se hai l'opportunità di testarlo, prova a confrontarlo con l'ultima build. Ma dubito che la nuova build possa accelerare significativamente. Al contrario, gli sviluppatori di MT non si preoccupano veramente della velocità di compilazione, vogliono solo spremere ulteriori nanosecondi dal runtime per poter fare affermazioni di marketing sulla velocità dei programmi MQL che sono paragonabili al C++ (anche se solo su alcuni esempi astratti).Per quanto ho capito, non si preoccupano dell'efficienza dell'ottimizzazione, cioè se il gioco vale il costo.

Proverò a cercare il codice sorgente nella base di codice, ma non è detto che riuscirò a trovarne uno simile. Deve essere un grande progetto, mentre lì sono disponibili per lo più piccoli progetti.

[Alexey Navoykov]

Renat Fatkhullin:

Molto probabilmente ha funzioni gigantesche sotto forma di bobine di testo.

L'ottimizzatore deve fare molti passaggi su tali frammenti di codice migliorando il codice più e più volte. È sufficiente ridurre la dimensione delle funzioni perché l'ottimizzatore aumenti drasticamente la velocità.

Beh, devi passare alle ultime build, dato che stiamo costantemente migliorando sia la qualità che la velocità in esse.

Nessuna funzione gigante. 150 linee al massimo (o è considerata gigantesca?). E se ci pensate in questo modo, perché la dimensione di una funzione ha a che fare con il compilatore che prova un mucchio di funzioni piccole? Supponiamo che passi attraverso la funzione grande 10 volte.Quindi la spezzo in 5 piccole funzioni e passa attraverso ognuna di esse 2 volte. Otteniamo lo stesso risultato. Quindi, l'intera quantità di codice è importante, giusto? Ma anche se il risultato accelera un po' quando si spezzano grandi funzioni, allora cosa? Stiamo parlando di una compilazione 10 (!) volte più lenta.

È chiaro che si vuole accelerare l'esecuzione del programma il più possibile, quindi si fanno molti passaggi cercando di migliorare qualcosa. E più si complica il linguaggio, più lunghi saranno questi passaggi, che consumeranno il tempo del programmatore. E c'è una domanda naturale sull'efficienza di tutto questo: quanto è più veloce il programma velocizzato dalla vostra ottimizzazione rispetto al tempo inattivo del programmatore che aspetta che l'ottimizzazione sia finita?

Naturalmente, si può provare a cercare qualche compromesso, ma è molto più efficiente fare diverse modalità di compilazione come ho scritto sopra. Il rilascio del programma con tutte le ottimizzazioni è necessario solo alla fine - il 99% del tempo dei programmatori è speso per scrivere e debuggare il codice quando non hanno affatto bisogno delle tue ottimizzazioni.

[Vasiliy Sokolov]

Alexey Navoykov:

Per quanto tempo andrà avanti che ogni volta che si aggiorna la build, il codice smette di compilare! E se compila, non funziona allo stesso modo di prima (il che è ancora peggio). Chi ha bisogno di un tale linguaggio di programmazione?

...

Non so cosa intendi. Ho diversi progetti molto complessi in MQL con più di 20 000 000 righe di codice. Le nuove build sono compilate in pochissimo tempo. Ci sono stati solo due problemi durante tutto il tempo. Una volta a causa del mio bug e l'altra volta a causa del bug dello sviluppatore.

[Vasiliy Sokolov]

Alexey Navoykov:

Un massimo di 150 linee

Questa è una funzione molto grande e scorretta.

[Alexey Navoykov]

Vasiliy Sokolov:
Non so cosa intendi. Ho diversi progetti molto complessi in MQL con codice di oltre 20 000 000 righe. Le nuove build sono compilate in pochissimo tempo. Ci sono stati solo due problemi durante tutto il tempo. Una volta a causa del mio bug e l'altra volta a causa del bug dello sviluppatore.

Beh, allora sei fortunato. Il tuo codice non ha nessuno dei costrutti del mio codice, cosa c'è di strano?

Sfogliate l'uomo qui sopra un paio di pagine e lì ha anche catturato un sacco di bug nella nuova build, alcuni dei quali sono difficili da catturare. Pensate che li stesse cercando di proposito?

[Renat Fatkhullin]

Alexey Navoykov:

Beh, allora sei fortunato. Il tuo codice non ha nessuno dei costrutti del mio codice, cosa c'è di strano?

Sfogliando un paio di pagine sopra, l'uomo lì ha anche catturato un mucchio di bug nella nuova build, alcuni dei quali sono difficili da catturare. Pensi che li stesse cercando di proposito?

Dimostrate un esempio di freno rigiocabile, per favore.

Sfortunatamente, finora state facendo affermazioni non comprovate, compresi gli attacchi diretti agli sviluppatori.

Ti sbagli sulla dimensione delle funzioni e sulla dimensione complessiva del programma. La dimensione delle funzioni individuali influenza direttamente e non linearmente l'ottimizzazione di ogni funzione particolare a causa sia dell'aumento dell'albero sintattico che dell'ottimizzazione multi-pass. Le funzioni più piccole sono ottimizzate al volo.

[Vasiliy Sokolov]

Alexey Navoykov:

Beh, allora sei fortunato. Il tuo codice non ha nessuno dei costrutti del mio codice, cosa c'è di strano?

Sfogliando le pagine qui sopra, l'uomo ha anche catturato un mucchio di bug nella nuova build, alcuni dei quali sono difficili da catturare. Pensi che li stesse cercando di proposito?

1) Mi chiedo quali costrutti hai usato che il mio codice non contiene. La dimensione del mio codice è di molte migliaia di linee e i tuoi costrutti non esistono? Sicuramente deve essere qualcosa di super unico?

2) In realtà, c'era un errore interno del compilatore nella build precedente che si verifica quando le classi si collegano tra loro. Era un bug degli sviluppatori ma l'hanno risolto. Non ricordo altri errori.

[A100]

Vasiliy Sokolov:

2) In effetti, la build precedente aveva un errore interno del compilatore che si verifica quando le classi si collegano tra loro. Questo è un bug del team di sviluppo, ma è stato risolto. Non ricordo altri errori.

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

E dov'è il collegamento reciproco tra le classi?

L'ho semplificato ancora di più qui per la vostra comodità nella ricerca di riferimenti reciproci e per capire quali costrutti non state usando

[Vasiliy Sokolov]

A100:

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

E dov'è qui il riferimento reciproco delle classi?

Semplificato ancora di più qui, per la vostra facilità di cercare i riferimenti reciproci e capire quali costrutti non state usando

State facendo reverse-engineering. Il lavoro è utile per migliorare il compilatore, ma in termini di programmazione pratica non è applicabile. Non conosco un solo programmatore che userebbe il codice che hai citato nella pratica:

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

Dimostrate un esempio di freno riproducibile, per favore.

Sfortunatamente, finora state facendo affermazioni non comprovate, compresi gli attacchi diretti agli sviluppatori...

Ti ho detto che questo è un grande progetto, la dimensione totale di tutto il codice sorgente è di circa 1 Mb. Come puoi dimostrare i freni? Invia tutto il codice o cosa? Capisci che questo è impossibile. E la compilazione dei singoli pezzi, naturalmente, va molto più veloce.

E cosa intendi per "affermazioni infondate"? Che il tuo compilatore di ottimizzazione è molto più lento? E che non te ne importa molto? Cosa c'è di infondato qui?

Ecco un link a una discussione dell'ottobre dell'anno scorso, quando hai appena introdotto questa ottimizzazione globale: https://www.mql5.com/ru/forum/1111/page1424#comment_1981722

L'uomo scrive:

Un altro codice - nota il tempo - deve essere aumentato di un fattore 20

E poi si risponde:

Questo è un nuovo compilatore ottimizzante per MQL5 (è assente in MQL4).

Dovete pagare per un codice di destinazione migliore con un tempo di compilazione più lungo.

E poi ci sono molte altre persone, incluso me, che si sono anche lamentate della lentezza della compilazione. Ma le tue risposte sembrano suggerire che ti interessa solo "una migliore qualità del codice target" e qualche mitico "aumento di velocità da 2 a 10 volte", anche se non ho visto tali aumenti di velocità in progetti di lavoro reali.

Come ho detto sopra, non sono stato in grado di testarlo sull'ultima build (22 aprile) perché ho avuto alcuni bug durante la compilazione. Ma presumo che la velocità di compilazione sia la stessa lenta lì, poiché non avete mai annunciato l'accelerazione del compilatore nella nuova build.