MT5 e la velocità in azione - pagina 70

[fxsaber]

Si prega di aggiungere la funzionalità richiesta.

Forum sul trading, sistemi di trading automatico e test di strategie di trading

Nuova versione di MetaTrader 5 build 2650: Caricamento in background dei grafici e miglioramenti nel Profiler di codice MQL5

fxsaber, 2020.11.04 16:50

Sfortunatamente, non hanno aggiunto funzioni per minimizzare le finestre di Charts, Terminal, Market Watch, ecc. Prima è stato dimostrato che ridurre al minimo queste finestre riduce il carico della CPU.

E smettere di visualizzare i dati nella finestra Market Watch e altri, quando la finestra del Terminale non è visibile. Per esempio, quando l'applicazione corrente (per esempio il browser) è attiva e massimizzata.

Il bisogno barbuto è quello di determinare quale grafico è attualmente selezionato. La gente è costretta a usare soluzioni WinAPI crostose.

[Renat Fatkhullin]

Sì, MetaTrader VPS ha ordini di grandezza meno latenza (emissioni di latenza) e molte volte più tutte le risorse rispetto ai VPS regolari dei fornitori di hosting.

È stato spiegato molte volte perché.

La latenza zero garantita nei thread di esecuzione non può esistere nelle attuali (tutte) architetture del processore. I racconti sui" sistemioperativi in tempo reale" rimangono dei miti, non c'è bisogno di menzionarli.

[Renat Fatkhullin]

fxsaber:

Ho capito cosa sta succedendo con le singole espulsioni, grazie per le spiegazioni dettagliate. A questo punto, però, non stiamo discutendo di SymbolInfoTick, ma di ritardi di natura diversa, che corrono su quasi ogni tick.

Questo riguarda solo le vostre misure di emissioni singole - non sono più accettate o considerate. Tutta la tua analisi è stata costruita solo sulle emissioni.

Altre questioni possono essere considerate solo se lo scenario è chiaramente e completamente descritto in un commento, senza "in realtà significava altri commenti" e senza rotolare nella misurazione a comando singolo.

[fxsaber]

Renat Fatkhullin:

Altre questioni possono essere considerate solo se lo scenario è chiaramente e completamente descritto in un singolo commento, senza "in realtà significava altri commenti" e senza rotolare nella misurazione del singolo comando.

Qui ai link ci sono i dettagli, compresi i commenti al codice sorgente.

Forum sul trading, sistemi di trading automatico e test di strategie di trading

MT5 e la velocità in azione

fxsaber, 2020.11.05 07:42

Chi sta usando il VPS di MQ, per favore condivida i risultati dei seguenti programmi.

1. Expert Advisor che cattura i ritardi di OnTick/OnBook.
2. Expert Advisor che cattura le zecche con i vecchi tempi.
3. Unoscript che misura il tempo medio di esecuzione di Sleep(1).

[Maxim Dmitrievsky]

C'è una piattaforma chiamata deltix (non per fare pubblicità). Quando ho parlato con gli sviluppatori (volevo collegarlo per l'arbitraggio qualche tempo fa), mi hanno spiegato la stessa cosa sui singoli ritardi, che è normale e bisogna guardare la media

Questo è a proposito, senza pietre nella breccia di nessuno

[fxsaber]

Poiché i singoli outlier si verificano inevitabilmente, è logico avere funzioni regolari che restituiscono un array dell'intero Market Watch e un array di tutte le posizioni/ordini correnti. Simile a MarketBookGet.

In questo momento i cicli devono essere eseguiti. Questo è MOLTO costoso.

Forum sul trading, sistemi di trading automatico e test di strategie di trading

MT5 e la velocità in azione

fxsaber, 2020.10.07 12:41

La necessità pratica ti fa scrivere così.

// Возвращает время Обзора рынка в миллисекундах.
long TimeCurrentMsc()
{
  long Res = 0;
  
  MqlTick Tick;
  
  for (int i = SymbolsTotal(true); i >= 0; i--) 
  {
    const string Symb = SymbolName(i, true);
    
    if (SymbolInfoTick(Symb, Tick) && (Tick.time_msc > Res))
      Res = Tick.time_msc;
  }

  return(Res);
}

Non sono sicuro del perché ho cercato di inserire l'EA in MQL5, nonostante le ripetute richieste di farlo.

[Roman]

Slava:

Non ci sarà alcuna accelerazione. Presenta i tuoi calcoli, almeno in cifre approssimative, dimostrando l'accelerazione multipla.

Una corsa alle risorse? Creazione incontrollata di nuovi flussi? Conflitti per nulla?

Volete dei rallentamenti inspiegabili?

Nel modello basato sugli eventi, tutti gli eventi sono sempre andati in formazione, uno alla volta. Chewed up - masticato.

Nessuna accelerazione dell'elaborazione degli eventi, in un'architettura asincrona? Dici sul serio?
Elaborazione accelerata dei programmi utente, in particolare dei loro gestori. Ecco di cosa sto parlando.
Capisco che state cercando di ridurre al minimo l'uso dei fili. Ma una delle alternative è quella di eseguire ogni gestore in un thread separato.
Nessuna creazione incontrollata di thread. In un programma utente ci sono solo pochi gestori, ognuno dei quali dovrebbe essere avviato nel proprio thread all'inizio del programma.
E si sincronizzano gli eventi tra i gestori con mutex o altro.

Ma se i thread sono un dolore per te, come hai detto, c'è un modello di eventi che ti permette di lavorare in un singolo thread.Gestione degli eventi, in un ciclo di eventi con task trigger.
Il ciclo di eventi, anche se viene eseguito in modo sequenziale, i compiti in quel ciclo sono gestiti in parallelo!
Questo è ciò che intendo, tutti i gestori del programma vengono eseguiti in questo ciclo di eventi, quindi tutti gli eventi saranno asincroni e arriveranno simultaneamente in tempo reale.
Cioè, gli stessi eventi in OnTrade eOnBookcorrisponderanno.
Chiedete come funziona un ciclo di eventi in altre lingue.
Se il ciclo di eventi esiste già nel terminale, basta applicarlo ai gestori nei programmi. Questo è tutto.

[fxsaber]

Roman:
Ogni gestore dovrebbe essere eseguito in un thread separato.

Il problema non è risolto in alcun modo. I programmi MQL diventano molto più complicati se diversi thread leggono l'accesso alle variabili interne, per esempio.

[Roman]

fxsaber:

Il problema non è risolto in alcun modo. I programmi MQL diventeranno più complicati di un ordine di grandezza, se si legge l'accesso alle variabili interne da diversi thread, per esempio.

I programmi MQL non diventeranno più complicati, è solo un mal di testa di sincronizzazione per gli sviluppatori. Che non sono disposti a risolvere, ovviamente.
O un'architettura iniziale bloccata del progetto non pensata per questo modello.
E nessuno riscriverà il progetto per un nuovo modello, ovviamente.
Il modello di loop dieventi è più adatto ai gestori. Questo è quello che stavo cercando di dire.
E questo modello molto probabilmente esiste già da tempo nel terminale, solo che non è stato applicato ai gestori.

[fxsaber]

Roman:

I programmi MQL non diventeranno più complicati...

Suggerisco che questa sia la fine della teorizzazione, che qui non si intersecherà mai con la pratica.