Informazioni sul profilatore di codice MT5 - pagina 7

 

Cos'è questo?!


 
fxsaber #:

Il profiler mostra chiamate di funzioni che non sono realmente avvenute. Mi sono anche imbattuto in qualcosa del genere:

Una specie di ArrayCopy, che non è nel sorgente mqh-file! Ho anche disegnato una linea rossa nella dichiarazione di un array statico.

Non posso ancora usare il profiler, purtroppo.

E pensate a come e cosa si muovono gli array quando costruite, assegnate e spostate gli oggetti (e avete un oggetto).

Pensate davvero che il programma consista solo nelle vostre corde?

Gli esempi non sono completi.

 
Renat Fatkhullin #:

E pensate a come e da cosa vengono spostati gli array quando si costruiscono, assegnano e spostano gli oggetti (e voi avete un oggetto).

Pensate davvero che il programma consista solo nelle vostre corde?

Gli esempi non sono completi.

Dare istruzioni chiare su cosa fare da parte mia per farvi affrontare questo argomento senza rimandarlo.

 
fxsaber #:

Datemi un'indicazione chiara su cosa fare da parte mia per farvi affrontare questo argomento senza rimandare.

State facendo affermazioni su un argomento (i compilatori e le loro viscere) che non capite.

L'istruzione non aiuta - non stai facendo un corso per sviluppatori di compilatori per capire il vasto mondo del codice generato implicitamente nei linguaggi a oggetti. I linguaggi di alto livello usano molte librerie e codice in linea. Costruite un progetto medio in WinAPI e guardate il file *.map - ci sono migliaia di funzioni ausiliarie e ognuna di esse può apparire nel profiling.

Le parole che ho ripetuto decine di volte su "il codice risultante non ha nulla a che fare con il tuo codice, è ottimizzato, incorporato e mischiato dal compilatore ottimizzatore" non catturano nemmeno il mio orecchio. Il compito principale del compilatore è quello di rendere il codice il più veloce possibile, non leggibile. Il compito del profiler è di mostrare i colli di bottiglia reali nel codice ottimizzato (reale), non di imbrogliare facendo corrispondere le linee.

Come paragone, profilare il codice C++ al momento è spesso un compito molto difficile, dato che l'ottimizzatore è un grande fissatore di partite. E sì, Microsoft Visual Studio C++ non è un punto di riferimento, il codice che genera è molto debole/cattivo. È del 20-30% peggiore dei suoi concorrenti LLVM/Clang.


Ancora una volta abbiamo un profiler che non cambia il codice in esame. Il tempo di controllo aumenta, ma il codice non è veramente rovinato dall'incorporazione di contatori, che ucciderebbe l'ottimizzazione del codice.

Il metodo utilizzato per il profiling è il "Sampling". Il profiler mette in pausa il programma MQL (~1000 volte al secondo) e raccoglie statistiche su quante volte viene fatta una pausa in un particolare frammento di codice. Questo include l'analisi delle pile di chiamate per determinare il "contributo" di ogni funzione al tempo totale di esecuzione del codice. Alla fine del profiling si ottiene quante volte ogni funzione è stata messa in pausa e quante volte ogni funzione è stata nello stack delle chiamate:

  • Attività totale della CPU [unità, %] - il numero totale di volte che una funzione è "apparsa" nello stack delle chiamate.
  • Own CPU activity [unit, %] - il numero di "pause" che si sono verificate direttamente all'interno della funzione specificata. Questo contatore è il più importante per identificare i colli di bottiglia perché, statisticamente, l'arresto avviene più spesso in quelle parti del programma che richiedono più tempo di CPU.



Senza esempi riproducibili in un solo passo non consideriamo i problemi. I sintetici semplificati di un paio di chiamate su microtask non possono nemmeno essere considerati in termini di percentuale di tempo impiegato o di contributo al tempo totale.

 
Renat Fatkhullin #:

State facendo affermazioni su un argomento (i compilatori e le loro interiora) che non capite.

Totalmente ignorante sull'argomento che avete identificato. Il profiler mostra alcuni dati che non possono essere interpretati in alcun modo.

Ancora una volta abbiamo un profiler che quasi non introduce ritardi nel codice che stiamo studiando. Il tempo di controllo aumenta ma il codice non è veramente rovinato dall'incorporazione di contatori - questo ucciderebbe l'ottimizzazione del codice.

Sto cercando di vedere i colli di bottiglia con il nuovo profiler. Nessuna fortuna, anche se ci sto provando con tutte le mie forze.

Senza esempi riproducibili in un solo passo non guardiamo i problemi. I sintetici semplificati di un paio di chiamate su microcompiti non possono nemmeno essere considerati in termini di percentuale di tempo impiegato o di contributo al tempo totale.

A chi invio i dati per il replay? I dati di LS mostrano che i messaggi LS possono non essere letti per molto tempo.

Due spunte verdi indicano che il messaggio è stato letto, una indica che non è stato letto.

 
fxsaber #:

Completamente ignorante sull'argomento che avete delineato. Il profiler mostra alcuni dati che non possono essere interpretati in alcun modo.

Sto cercando di vedere i colli di bottiglia con il nuovo profiler. Nessuna fortuna, anche se ci sto provando.

A chi invio i dati per il replay? I dati del PM mostrano che i messaggi PM possono non essere letti per molto tempo.

Due tick verdi - messaggio letto, uno - non letto.

Allo stesso modo, più spesso il martello viene colpito, in un posto o in un altro, più costosa è la funzione

qual è la probabilità che un contatore colpisca le variabili economiche? quasi 0

ci sono funzioni immediatamente comprensibili che il contatore colpirà, sono saltate, guardate i seguenti personalizzati

 
Fast235 #:

semplicemente, più spesso il martello viene colpito, in un posto o in un altro, più la funzione è costosa

qual è la probabilità che un contatore colpisca le variabili economiche? quasi 0

ci sono funzioni immediatamente comprensibili che il contatore colpirà, sono saltate, guardate i seguenti personalizzati

Sto parlando dell'applicazione pratica, non della bella teoria che è chiara a prima vista.

 
fxsaber #:

Sto parlando di applicazione pratica, non di una bella teoria facile da capire la prima volta.

pratico è quello che era, quante volte viene invocato?

è puramente un interesse perfezionista,

Sono d'accordo che le chiamate extra devono essere viste, anche se saranno economiche.

 
Fast235 #:

La pratica è come prima, quante volte si chiama?

Il profiler precedente era in grado di trovare i colli di bottiglia, ma qui stiamo parlando di un nuovo profiler i cui dati non ci permettono di capire cosa sta succedendo, anche se in teoria è stato studiato più volte.

 
fxsaber #:

Il profiler precedente permetteva di trovare i colli di bottiglia, ma qui stiamo parlando di uno nuovo, i cui dati non permettono di capire cosa sta succedendo, anche se in teoria tutto è stato studiato più volte.

Renat non dovrebbe mostrare il nuovo profiler in frasi generiche, ma renderlo chiaro anche ai convinti come il sub) (non sto sminuendo).