Lo splendore e la povertà dell'OLP - pagina 6
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Ha dimostrato che la chiamata diretta o la chiamata virtuale non hanno alcun effetto nei progetti reali.
La maggior parte dei costi sono sostenuti nelle chiamate alle funzioni di sistema, dove i programmi MQL passano quasi tutto il loro tempo. I costi di organizzazione delle chiamate sono trascurabili rispetto al carico utile.
Dove ha mostrato? Una tabella con alcuni nomi di funzioni e misure è un argomento? Non siamo esperti telepatici qui. Bisogna vedere il codice delle funzioni, e poi si può dire qualcosa.
Dove l'ha mostrato? Una tabella con alcuni nomi di funzioni e misure - è un argomento? Non siamo esperti telepatici qui. Hai bisogno di vedere il codice delle funzioni, poi possiamo parlare d'altro.
Ha mostrato che nei progetti reali, la chiamata diretta o la chiamata virtuale non hanno alcun impatto.
La maggior parte dei costi sono sostenuti dalle chiamate di funzioni di sistema, dove i programmi MQL passano la maggior parte del loro tempo. Il costo dell'organizzazione delle chiamate è trascurabile rispetto al carico utile.
+100 Sì, lo fa!
Inoltre, ho notato che quando ho dovuto riscrivere le classi tentacolari in modo che alcune delle loro funzioni fossero eseguite da altre classi (inclusione/decomposizione), le prestazioni generali sono aumentate e il controllo sul codice è aumentato. In altre parole, in pratica, vediamo l'opposto di quello che Integer e i fan del C di vecchia scuola stanno cercando di dimostrarci: il numero di classi cresce, il numero di metodi cresce, e la performance, al contrario, cresce.
Dove l'ha mostrato? Una tabella con alcuni nomi di funzioni e misure - è un argomento? Non siamo esperti telepatici qui. Hai bisogno di vedere il codice delle funzioni, poi possiamo parlare d'altro.
+100 Sì, proprio così!
Inoltre, ho notato che quando ho dovuto riscrivere le classi sprawling in modo che alcune delle loro funzioni fossero eseguite da altre classi (inclusione/decomposizione), la performance complessiva è aumentata, e il controllo sul codice è aumentato. In altre parole, in pratica, vediamo l'opposto di quello che Integer e i fan del C di vecchia scuola stanno cercando di dimostrarci: il numero di classi cresce, il numero di metodi cresce, e la performance, al contrario, cresce.
Un nuovo modo di auto-indulgenza? Andiamo, andiamo.
Vasily, avresti dovuto leggere quello che cercavo di dimostrare qui, però (e qualunque cosa tu pensi, l'ho dimostrato).
Notate, tuttavia, che avere il codice sorgente non vi dirà nulla. La complessità cumulativa non è la stessa. Anche dopo aver analizzato le fonti si direbbe "beh, qualcosa lì si chiama, qualcosa si conta, qualcosa si prende da qualche parte, ma cosa esattamente non è chiaro, quindi di nuovo niente è provato.
In generale, sì, probabilmente hai ragione, le singole funzioni probabilmente non ti diranno molto. Che senso ha anche solo parlare del tuo software se è un pig in a poke per tutti gli altri.
Infatti, la cosa principale che ci interessa è il numero totale di passaggi attraverso i metodi virtuali, e il tempo totale speso su di esso. Qui nella tua tabella c'è qualche funzione ombreggiata eseguita 5 milioni di volte. Non so cosa sia, forse è solo un metodo virtuale con l'azione più semplice. Comunque, 5 milioni sono un'inezia. Suppongo che tu non abbia calcoli pesanti nel tuo programma, quindi non c'è molto da discutere. Supponiamo che tu stia calcolando un sistema di equazioni lineari 30000x300000 e accedendo agli elementi della matrice attraverso metodi virtuali, ci sarebbe qualcosa di cui parlare.
Un nuovo modo di auto-influenzare? Andiamo, andiamo.
Vasily, dovresti, dopo tutto, leggere quello che stavo cercando di dimostrare qui (e qualunque cosa tu pensi a riguardo, l'ha dimostrato).
Dmitry, non sono né a favore né contro di te. Per capirlo, è necessario conoscere il funzionamento interno del compilatore in linea, ma aprire queste informazioni per MQ equivale ad aiutare a scrivere un decompilatore.
L'unico che ha tali informazioni qui (tra quelli che discutono) è Renat, quindi dobbiamo fidarci della sua parola. Non vedo altro modo.
Se dice che non state impostando correttamente il test, probabilmente è così.
La questione è diversa, solo MQ può impostare correttamente il test in un caso simile, questo è ciò che deve essere fatto.
Come si dice prova per prova, la mia parola contro la tua. E tu stai cercando di provare l'indimostrabile. È impossibile provare o confutare le vostre affermazioni senza avere qualcosa con cui confrontarle.
Il decompilatore è fuori questione qui.
Bisogna solo capire e conoscere le tecniche di ottimizzazione dei compilatori per evitare di testare casi semplificati degenerati, che sono brutalmente ottimizzati e degenerano in codice lineare. Abbiamo rilasciato la quarta generazione di compilatori per un motivo.
Questo è esattamente ciò di cui stiamo parlando.
Per esempio, se stessimo calcolando un sistema di equazioni lineari 30000x300000 e l'accesso agli elementi della matrice fosse attraverso metodi virtuali, ci sarebbe già qualcosa di cui parlare.
In questi casi, il primo refactoring vi darebbe un guadagno di velocità di cento volte superiore. E la chiamata virtuale sarebbe al decimo posto in termini di costi.
Cioè, l'esempio non è realistico.
Allora scriviamo tutto in linguaggio assembly. Sarebbe comunque più veloce.
Non capisco il problema. Non ho mai visto un Expert Advisor o un indicatore con 1 MB di codice.
Anche la chiamata di qualsiasi funzione richiede del tempo. Rinunciamo anche alle funzioni!
Il controllo di grandi progetti è molto più conveniente con OOP.
Inoltre, la velocità di esecuzione del codice spesso non è così critica come il tempo di ping al broker e la risposta del broker su un ordine.
Controlla gli algoritmi HFT. Richiedono la massima velocità, ma non vi troverete calcoli complessi.
PS. Di solito non hai bisogno di una supercar o di una motoslitta per andare dal punto A al punto B. Un motorino è sufficiente! Un motorino è sufficiente!