MT5 e la velocità in azione - pagina 17
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 noti che HistorySelect fa un'istantanea fisica della cronologia selezionata nella cache locale dell'EA, in modo da poterla esaminare senza paura. Senza questo si possono ottenere effetti molto spiacevoli, poiché la storia dell'account viene aggiornata/sincronizzata in modo asincrono. Per non parlare del fatto che l'utente stesso può cambiare manualmente la profondità della storia dall'interfaccia.
Da qui tali costi di copiatura. Tanto più se si cerca deliberatamente di forzare la copia di questa storia nella cache simultaneamente da più thread.
Abbiamo già ottimizzato molto nelle operazioni di campionamento e ora stiamo pensando all'aggiornamento ottimale della cache, quando in realtà il 99% dei campioni sarà completamente inutile e verrà saltato al volo.
Cioè, a meno che non randomizziate specificamente i limiti di campionamento, la cache mostrerà hit vicini al 100%.
Molto probabilmente la prossima settimana ci sarà già una soluzione efficace.
Si noti che HistorySelect fa un'istantanea fisica della cronologia selezionata nella cache locale dell'EA, in modo da poterla esaminare senza paura. Senza questo si possono ottenere effetti molto spiacevoli, poiché la storia dell'account viene aggiornata/sincronizzata in modo asincrono. Per non parlare del fatto che l'utente può cambiare manualmente la profondità della storia dall'interfaccia.
C'è una tabella di ordini e una tabella di accordi. Perché avremmo bisogno di fare degli snap fisici, quando conosciamo i quattro indici al momento della chiamata a HistorySelect?
Ecco perché i costi di copia sono così alti. Soprattutto se ci occupiamo specificamente della copia obbligatoria simultanea di questa storia nella cache da più thread.
Abbiamo già ottimizzato molto nelle operazioni di campionamento e ora stiamo pensando all'aggiornamento ottimale della cache, quando in realtà il 99% dei campioni sarà completamente inutile e verrà saltato al volo.
Cioè, a meno che non randomizziate specificamente i limiti di campionamento, la cache mostrerà hit vicini al 100%.
Molto probabilmente la prossima settimana ci sarà già una soluzione efficace.
HistoryDealSelect e HistoryOrderSelect ora distruggono i relativi campioni. Perché non c'è, come in MT4, l'accesso a entrambe le tabelle tramite indici? Introdurre nuove funzionalità.
Forum sul trading, sistemi di trading automatico e test di strategie di trading
Bug, bug, domande
fxsaber, 2020.08.20 11:28
Nuove funzioni interne.Gli indici lo chiedono. Non capisco perché dovrei conoscere il numero di scambi nel mio conto attraverso un posto.
E queste tabelle possono cambiare in qualsiasi momento. Così come possono esserlo i singoli dischi al loro interno.
Nessuno può garantire la loro immutabilità a causa di operazioni asincrone, processi di sincronizzazione e modalità di profondità manuali impostate dagli utenti.
Come ho scritto sopra, applicheremo tecniche di caching intelligente, che ridurranno a zero il costo delle funzioni Select. A meno che, ovviamente, non si randomizzino specificamente i limiti di campionamento. L'ultima data può essere cambiata e non invaliderà la cache se è sempre nel futuro/ultima volta. Le transazioni recenti saranno aggiunte con parsimonia alla cache.
In MT4 funziona allo stesso modo, solo la creazione della cache è nascosta. Ad ogni OnTick/OnStart di MT4, il terminale crea automaticamente e con parsimonia un'istantanea dell'ambiente di mercato per ogni EA.
Pertanto, non è possibile valutare la vera latenza della preparazione dei dati dal codice MQL4. Fortunatamente, in MT4 i dati sono piccoli e semplici.
In MT5 abbiamo rinunciato ai costi di creazione automatica dell'ambiente di mercato per ridurre i ritardi e non fare lavoro inutile. Invece abbiamo dato il pieno controllo dei costi agli sviluppatori di robot che possono richiedere esattamente ciò di cui hanno bisogno.
Si noti che la dimensione dell'ambiente di mercato in MT5 è enorme rispetto a MT4 - semplicemente non può essere replicato.
Con i vostri test avete approfittato di uno di questi costosi campioni.
Lo sistemeremo - è nel nostro interesse.
E queste tabelle possono cambiare in qualsiasi momento. Così come possono esserlo i singoli dischi al loro interno.
Nessuno può garantire la loro immutabilità a causa di operazioni asincrone, processi di sincronizzazione e modalità di profondità manuali impostate dagli utenti.
Sta dicendo che prima dell'ultimo scambio, un altro scambio può apparire nella storia del trading? Se un commercio è cambiato, un altro. Ma per incastrarsi in una lista già esistente - non l'ho notato.
OrderExist e PositionExist sono funzioni speciali ottimizzate che evitano uno stupido looping attraverso tutti gli ordini o posizioni alla ricerca di voci per simbolo, tipo di transazione e medzhik.
Il risultato è una serie di biglietti.
I programmi possono risparmiare molto denaro usando queste funzioni. Soprattutto quando si chiamano posizioni aperte e ordini in massa, costantemente e ripetutamente in loop di overshoot.
In futuro implementeremo funzioni più efficaci per accedere ai dati commerciali di massa.
Il linguaggio sarà anche drammaticamente rafforzato e semplificato con funzionalità più potenti.
Sta dicendo che ci può essere un altro scambio nella storia del trading prima dell'ultimo scambio? Se un accordo è cambiato, un altro. Ma per incastrarsi in una lista già esistente - non l'ho notato.
Teoricamente, sì.
Non dimenticare i processi di sincronizzazione. Un gran numero di processi nella piattaforma sono asincroni.
Per esempio, un'integrazione gateway con uno scambio o un fornitore di liquidità può inviare rapporti sulle transazioni con ritardi di secondi o addirittura minuti. Spesso l'api non fornisce affatto l'accesso alla storia per la riconciliazione, ma fornisce generatori di rapporti lenti e non ritmici.
All'apertura del mercato, o a causa di una riconnessione inaspettata del gateway, i rapporti possono essere ritardati. Sono replicati nella cronologia sul server e immediatamente inviati in modo asincrono ai terminali. Grazie all'ordinamento per data, vengono inseriti nei posti giusti, e nel frattempo si possono aprire nuovi trade.
La maggior parte delle API di integrazione sono così analfabete e disfunzionali che rendono quasi impossibile fare dei gateway garantiti. Anche se c'è un'opinione che questo sia il prodotto di un sabotaggio deliberato da parte dei loro sviluppatori.
OrderExist e PositionExist sono funzioni speciali ottimizzate che evitano uno stupido looping attraverso tutti gli ordini o posizioni alla ricerca di voci per simbolo, tipo di transazione e medzhik.
Il risultato è una serie di biglietti.
I programmi possono risparmiare molto denaro usando queste funzioni. Soprattutto quando si chiamano posizioni aperte e ordini in massa, costantemente e ripetutamente in loop di overshoot.
In futuro implementeremo funzioni più efficaci per accedere ai dati commerciali di massa.
Il linguaggio sarà anche drammaticamente rafforzato e semplificato con funzionalità più potenti.
Renat, una grande richiesta per avere accesso alle quotazioni al di fuori di TERMINAL_MAXBARS quando si usano le funzioni Copy.... Almeno solo il minuto di tempo. Potete anche fare una funzione separata per questo.
Ma per avere accesso a questi dati dovete sempre impostare TERMINAL_MAXBARS su unlimited (inoltre, sovraccarica il terminale), il che è molto scomodo perché non avete bisogno di unlimited per tutti i simboli.
Per quanto ho capito, se si copiano tutte le piccole barre del periodo MN1, tutte le barre M1 saranno ancora scaricate, ma non c'è accesso ad esse.
Naturalmente, è possibile scaricare tutti i tick, perché non sono soggetti a questa restrizione, ma è più dispendioso in termini di tempo e purtroppo i tick non coincidono sempre con l'intero storico dei minuti.
Renat, una grande richiesta per avere accesso alle quotazioni al di fuori di TERMINAL_MAXBARS quando si usano le funzioni Copy.... Almeno solo il minuto di tempo. Potete anche fare una funzione separata per questo.
Ma per avere accesso a questi dati dovete sempre impostare TERMINAL_MAXBARS su unlimited (inoltre, sovraccarica il terminale), il che è molto scomodo perché non avete bisogno di unlimited per tutti i simboli.
In effetti, per quanto ho capito, se si copiano tutte le piccole barre del periodo MN1, tutte le barre M1 saranno comunque scaricate, ma non c'è accesso ad esse.
Naturalmente, è possibile scaricare tutti i tick in quanto non sono soggetti a questa restrizione, ma è più dispendioso in termini di tempo e purtroppo i tick non sempre coincidono con l'intero minuto storico.
No, la storia al di fuori di questi limiti non viene rilevata e controllata per la sincronizzazione. Inoltre, non c'è posto per immagazzinarli (non costruiremo ulteriori cache invisibili), non scaleremo il disco in modi non economici e non costruiremo stampelle.
In generale, questa è un'idea dannosa perché gli sviluppatori inizieranno immediatamente a scrivere algoritmi assolutamente inefficienti e consiglieranno ai trader di "impostare 5000, o meglio 1000 barre" e ci accuseranno di lentezza e inefficacia.
Abbiamo volutamente permesso di controllare la quantità di risorse assegnate ai grafici. È a 64 bit e la memoria è economica ora - usa le impostazioni appropriate all'interno delle regole e dell'architettura.
Non cambieremo questo comportamento.
No, la storia al di fuori di questi limiti non viene sollevata e controllata per la sincronizzazione. Inoltre, non c'è posto per immagazzinarli (non costruiremo ulteriori cache invisibili) e non ci arrampicheremo sul disco in modi antieconomici.
In effetti, è un'idea dannosa, poiché gli sviluppatori inizieranno immediatamente a scrivere algoritmi assolutamente inefficienti e consiglieranno ai trader di "impostare 5000 o meglio 1000 barre" e ci accuseranno di lentezza e inefficacia.
Abbiamo volutamente permesso di controllare la quantità di risorse assegnate ai grafici. È a 64 bit e la memoria è economica ora - usa le impostazioni appropriate all'interno delle regole e dell'architettura.
Non cambieremo questo comportamento.
Ok. Capito. Grazie. Cancellato.
Anche se, naturalmente, mi piacerebbe discutere di antieconomia. Dovrò lasciare illimitato e di conseguenza tutti aperti (per esempio ho 14 grafici al momento) manterranno tutta la storia, anche se ho bisogno solo di 5000 per la maggior parte di loro. Che al contrario sarà più antieconomico.
Inoltre non ho bisogno che questi dati vengano memorizzati. Mi occuperò del deposito. Ho avviato il caricamento di tutte le barre dei minuti, le ho messe in un array e non ne ho più bisogno e tutte le cache possono essere eliminate se la loro dimensione supera TERMINAL_MAXBARS. Quindi forse è a questo che serve una funzione separata che non memorizza le cache.
Anche se, naturalmente, sono d'accordo che le mani cattive possono sospendere il sistema con tali carichi periodici.
Avete solo due stati 5000 e unlim?
Tu sei la mente della tua felicità.