Caratteristiche del linguaggio mql5, sottigliezze e tecniche - pagina 118

Nuovo commento
 
No, però mi sbagliavo. FastLog2 funziona più velocemente quando Optimize=1. È un miracolo... Devo verificarlo in C++.
 
Alexey Navoykov:

A proposito di zero, FastLog2 non controlla lo zero, il che gli dà un vantaggio. Ma è ancora 1,5-2 volte più lento di log2 se testato correttamente).

E cosa c'è di sbagliato in questo?

Perché anche la tua versione del test produce:

2019.01.05 04:43:12.372 TestLog (EURUSD,H1)     Result log2:       sum=1400005128  time=297 ms
2019.01.05 04:43:12.635 TestLog (EURUSD,H1)     Result log2_:      sum=1400018381  time=262 ms
2019.01.05 04:43:12.809 TestLog (EURUSD,H1)     Result _FastLog2:  sum=1400004095  time=174 ms
 
Alexey Navoykov:

A proposito di zero, FastLog2 non controlla lo zero, il che gli dà un vantaggio. Ma è ancora 1,5-2 volte più lento di log2, se testato correttamente).

Naturalmente, dovremmo rimuovere il controllo zero da log2 o aggiungere lo stesso a FastLog2.

La domanda riguarda davvero la velocità della parte computazionale. In log2, tutto è calcolato puramente con spostamenti e aggiunte. FastLog2 usa i valori della tabella dopo conversioni intelligenti che coinvolgono la moltiplicazione. Questo codice è molto vecchio, è stato usato ai tempi dei coprocessori matematici, la situazione potrebbe essere cambiata da allora.

 
L'ho controllato in C++. Sì, FastLog2 è effettivamente il più veloce. Codice intelligente, però ) Forse la ragione è che le operazioni bitwise sono molto più veloci delle operazioni di confronto.
 
Ho testato tutti i codici in MT4. In MT4 il compilatore non esegue alcuna ottimizzazione (cioè la variante con somma mostra gli stessi risultati relativi della mia variante originale senza somma), e in MT4 log2 gira più velocemente di FastLog2. E in MT5 c'è già l'ottimizzazione senza somma (cioè il codice apparentemente non viene eseguito completamente), e la variante FastLog2 è più veloce di log2. Quali conclusioni si possono trarre da questo non lo so, perché non ci sono dettagli su come funziona l'ottimizzatore di codice lì per lì.
  
void f(){
  static int a[]; 
  Print("a[]=",ArraySize(a)); 
  ArrayResize(a, 100); 
  Print("a[]=",ArraySize(a));}


class A
 {
public: A(){ f(); }
 };
 
A _a;

void OnStart()
  {

  }


 
Ilya Malev:

Questo è il comportamento standard di MQL5: le variabili statiche vengono dopo le variabili globali.

Si può incasinare molto seriamente a causa di questo.
 
fxsaber:

Questo è il comportamento standard di MQL5: le variabili statiche iniziano dopo le variabili globali.

È per questo che ogni variabile statica di una classe/struttura deve essere dichiarata dopo la struttura stessa? E anche senza assegnargli alcun valore... Forse dovremmo suggerire che il compilatore faccia tutto questo automaticamente?

 

Questo è essenzialmente un bug, una sequenza errata di esecuzione del codice del programma. Il compilatore non dovrebbe permetterlo in linea di principio. Dovresti urlare più spesso agli sviluppatori per questo.

In C++ il codice viene processato dal compilatore rigorosamente dall'alto verso il basso, quindi tutto quello che viene dall'alto è già inizializzato e non si può accedere al codice sottostante. Ecco perché tutto è chiaro. E poiché gli sviluppatori hanno introdotto le loro regole qui, lasciamo che siano loro a fornire il corretto ordine di esecuzione del codice.

 
Alexey Navoykov:

In C++, il codice viene processato dal compilatore rigorosamente dall'alto verso il basso, quindi qualsiasi cosa in alto è già inizializzata, e non si può accedere a quella in basso. Ecco perché tutto è chiaro.

C'è meno flessibilità.

1...111112113114115116117118119120121122123124125...247
Nuovo commento