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
Si scopre che stavo guardando la frequenza di generazione del web, non la frequenza di uscita.
Sono numeri diversi, multipli l'uno dell'altro.
Ho scoperto che stavo calcolando la frequenza di generazione del web (senza uscita) e la frequenza di uscita (senza generazione) un po' male
Ecco una versione più corretta.
Risultati sul mio processore:
Se si prende il tempo puramente generando un fotogramma di 200 cerchi lisciati senza uscita, avviene a circa 500 fotogrammi al secondo.
formando un fotogramma di 200 cerchi non smussati senza uscita - circa 1000 fps.
La frequenza dell'uscita dell'immagine (tela) stessa (funzione Update) è di circa 650 fotogrammi al secondo.
Hai davvero lavorato sodo!
Attenzione alle conversioni di massa dei tipi (int)double o (double)int e al mischiare int+double nelle operazioni mat in generale.
Questo dà l'overhead più selvaggio al processore - proprio un comando assembler così costoso. Se contate in doppio, continuate a contare in doppio e non passate ai tipi interi.
Comandi come cvtsi2sd/cvttsd2si sono molto lunghi. Un piccolo suggerimento nell'articolo"L'istruzione x86 più lenta", villano numero 2.
Grazie per un articolo molto prezioso.
Ma ad essere onesti, non capisco perché allora in questo semplice script:
la somma di long con la conversione del tipo double in long è molto più veloce della somma di double dello stesso array senza conversione
In primo luogo, si dovrebbe guardare il codice assembly e il risultato delle ottimizzazioni di casi estremamente semplici (la supermicrosintesi è stata a lungo fuorviante). È facile imbattersi in un caso ideale di implementazione del trasportatore.
In secondo luogo, quasi nessuno può garantire come questo o quel codice verrà compilato e quanto tempo impiegherà per essere eseguito.
Basta aggiungere una riga/comando in più nel codice e la velocità cambia drasticamente. Il vero codice/dati potrebbe anche uscire dalla cache L1/L2 e basta.
Come ha funzionato per voi? In teoria/super-sintesi sembra che i comandi interi aiutino nella velocità, ma nel codice reale è un salasso. Perché c'è decine/centinaia di volte più codice, nessuna convezione, salti costanti da calcoli interi a reali e l'ottimizzazione è limitata.
Perché l'inizializzazione degli array di qualsiasi tipo in MQL4 è più di 10 volte più lenta che in MQL5?
Perché l'inizializzazione degli array di qualsiasi tipo in MQL4 è più di 10 volte più lenta che in MQL5?
Perché lì tutti gli array sono dinamici e il linguaggio è dieci volte più lento.
Un indicatore ultra-veloce di centinaia di medie mobili, implementato su Canvas.
100 linee MA (periodo passo 10) - tempo di calcolo e visualizzazione sullo schermo - 4-7 millisecondi
1000 linee MA (periodo passo 1) - tempo di calcolo e visualizzazione - 20-30 millisecondi.
Non ho testato troppo il codice. Ci possono essere dei bug. Implementato solo per le barre spesse un pixel (è forzato a questa scala). Anche la frequenza di aggiornamento dello schermo non è ottimizzata. Tutte le linee sono calcolate e completamente emesse ad ogni tick.
Un indicatore ultra-veloce di centinaia di medie mobili, implementato su Canvas.
100 linee MA (periodo passo 10) - tempo di calcolo e visualizzazione sullo schermo - 4-7 millisecondi
1000 linee MA (periodo passo 1) - tempo per il calcolo e la visualizzazione - 20-30 millisecondi
figo, con gli indicatori standard tutto sarebbe morto
fresco, gli indicatori standard avrebbero appeso tutto.
e poi ci sarebbe un miglio di codice...
forse anche questo può essere fatto solo con un modello. Non conosco la limitazione del numero di linee di indicatori nel corpo di un indicatore.
...
Non sono a conoscenza della limitazione del numero di linee di indicatori nel corpo di un indicatore.
C'è un limite. Si possono fare fino a 512 buffer di indicatori >>>https://www.mql5.com/ru/docs/indicators