MT5 e la velocità in azione - pagina 75

Nuovo commento
 
Valeriy Yastremskiy:

Non sono un esperto di grafici. L'importanza è determinata dalla dipendenza dell'inizio di altri compiti dalla fine di quello corrente. altri criteri sono secondari. ma c'è anche il tempo di esecuzione del compito. In generale è difficile e più triste, è impossibile cambiare un algoritmo prioritario al volo. Per quanto riguarda il lato positivo, vorrei qualche chiarimento da parte degli sviluppatori prima che sorgano delle domande. È complicato, ma è l'obiettivo giusto nello sviluppo dell'ambiente.

Estratto da una descrizione di come funziona nei sistemi in tempo reale.

Di solito le priorità sono dinamiche, il che significa che possono essere cambiate in fase di esecuzione dai processi stessi e dal sistema operativo.
La risposta agli interrupt è separata dai calcoli intensivi della CPU.
Non appena si verifica un evento o un interrupt, il suo gestore viene immediatamente incluso nella coda dei processi pronti.
I programmi di gestione dell'interruzione sono di solito compatti perché devono fornire una risposta veloce,
per esempio l'ingresso di nuovi dati, e trasferire il controllo a processi più complessi ad alta intensità di CPU che vengono eseguiti con una priorità inferiore.

 
Roman:

Ciao Nikolai. Questo è vero.
Ma non ci sarà lo stesso problema della sincronizzazione, di cui parla Slava, cioè freni irragionevoli.
O forse non c'è nessun problema? )) Forse, è più facile non usare il modello asincrono che sincronizzarlo con le priorità? ))

Ciao.
Non sono un esperto in asincronia e interruzioni, anche se ho qualche conoscenza ed esperienza.
Non dovrebbe esserci alcun problema con il problema del timer. Poiché la sequenza non è importante, è la periodicità che conta. Non ha molta importanza come viene gestito dal capo, che è responsabile dell'allocazione delle risorse.
Inoltre, da quanto ho capito, il timer è basato su interrupt hardware di sistema. Penso che l'intero sistema di controllo dell'asincronia sia implementato usando interrupt hardware, inclusi quelli dal timer.
Mi chiedo ancora quanto siano intensivi di risorse gli interrupt.
Per esempio, un interrupt di sistema viene dal timer della CPU per eseguire un incremento di una variabile globale. Questo incremento richiede al sistema circa 1 nanosecondo. Ma:

  • Quanto tempo ci vuole per salvare tutti i parametri dei processi in corso e/o dei thread necessari per riprendere il lavoro?
  • Questo risparmio è fatto dall'hardware o dal software?
  • Quanto tempo ci vuole per ripristinare il processo?
  • Possiamo misurare questa intensità di risorse? Probabilmente no, perché come si fa a cogliere il momento dell'interruzione?
  • Qual è l'ordine di questi costi di risorse - decine, centinaia di nanosecondi, microsecondi o decine e centinaia di microsecondi? Sarebbe interessante ottenere tali informazioni.

In generale, mi rendo conto che mi mancano conoscenza ed esperienza. Ecco perché cerco di non chiedere agli sviluppatori le priorità dell'asincronia. Capisco che ci sono un sacco di sfumature, insidie e ostacoli quando si cerca di creare un sistema perfetto, soprattutto quando si tratta di ordini di compravendita e ottenere informazioni commerciali.
Anche se devo ammettere che ancora non capisco perché hanno reso alcune funzioni asincrone nella 5, il che è un grande inconveniente. Intendo ChartGet..., ChartTimePriceToXY, ChartXYToTimePrice.
Dopo tutto, è logico supporre che il riempimento della tabella di stato della tabella dovrebbe essere asincrono, e i comandi dovrebbero leggere solo i dati da questa tabella. E se i dati al momento della lettura non sono aggiornati di qualche millisecondo, non è un problema.
Ilproblema è che nella ricerca della rilevanza immaginaria dei dati, si verificano ritardi di decine di millisecondi, durante i quali la rilevanza estratta diventa irrilevante in misura maggiore, se questi comandi non erano originariamente asincroni, ma semplicemente leggevano gli ultimi dati conosciuti dalla tabella di stato del grafico.
E a giudicare dal tempo di esecuzione, queste funzioni non erano asincrone in 4.

 
Roman:

Estratto da una descrizione di come funziona nei sistemi in tempo reale.

Normalmente le priorità sono dinamiche, il che significa che in fase di esecuzione possono essere cambiate dai processi stessi così come dal sistema operativo.
La risposta agli interrupt è separata dai calcoli intensivi della CPU.
Non appena si verifica un evento o un interrupt, il suo gestore viene immediatamente incluso nella coda dei processi pronti.
I programmi di gestione dell'interruzione sono di solito compatti perché devono fornire una risposta veloce,
ad esempio inserire nuovi dati, e passare il controllo a processi più complessi ad alta intensità di processore che vengono eseguiti con una priorità inferiore.

È proprio come ho descritto)))) Naturalmente la logica delle priorità è dinamica. E questa è la difficoltà nell'impostare il livello. impostando il livello di priorità non possiamo determinare il suo tempo di esecuzione nella logica di priorità dinamica nell'ambiente sottostante. il terminale è sempre sopra l'ambiente wine o linux e non può influenzare la logica di priorità dell'ambiente sottostante.

 
Nikolai Semko:


Non si presume che tutte le domande poste abbiano una risposta.

Quanto è intensivo in termini di risorse l'interrupt stesso.
Molto probabilmente dipende dalla frequenza del processore.

Quanto tempo ci vuole per salvare il processo, per un'ulteriore ripresa.
Secondo gli algoritmi basati sulla quantizzazione, il processo attivo viene cambiato se:

  • il processo è terminato e ha lasciato il sistema
  • si è verificato un errore
  • il processo è passato allo stato STANDBY
  • ha esaurito un quantum di tempo del processore, e

Come catturare le interruzioni.
Unpre-divisore è un divisore di frequenza di clock che agisce come uno o più T-trigger collegati in serie.

 
Roman:

Non tutte le domande poste devono avere una risposta.

Vai a studiare la materia (per almeno 10 anni) e non sporcare questo thread, per favore.

Le domande sono discusse qui con una formazione diversa e una classe diversa.

 
Nikolai Semko:
  • Quanto tempo ci vuole per salvare tutti i parametri dei processi in corso e/o dei thread necessari per riprendere il funzionamento?
  • Questo risparmio è fatto dall'hardware o dal software?

Non succede niente dal processore 286? Non ricordo e non l'ho mai capito, ma dal Pentium-1 (ho letto un libro su questo, ma molto tempo fa)

Il processore lavora in modalità protetta. Ogni processore ha una memoria virtuale allocata; gli indirizzi fisici dei banchi di memoria (celle RAM) sono tradotti in indirizzi virtuali (o piuttosto viceversa?) dal processore stesso (non ricordo, ma sembra essere un registro speciale e un puntatore virtuale alla tabella di traduzione degli indirizzi). È l'hardware tutto ciò che accade, non è misurabile, è il cosiddetto core del processore che distingue ogni linea di processori Intel, non è la cache!

Nikolai Semko:
  • Quanto tempo ci vuole per recuperare il processo?

qualsiasi programma su Win dovrebbe registrarsi come processo e creare almeno un thread

allora il task scheduler di Win assegnerà risorse al processo e gli metterà in coda i messaggi, come funziona lo scheduler non mi interessa, è sufficiente che la priorità del processo possa essere alzata e si può vedere che con qualche sforzo il PC inizia a pianificare, cioè Microsoft dà risorse alla mia applicazione, questo è sufficiente per mantenere il sistema operativo in esecuzione

Nikolai Semko:
  • È possibile misurare questa intensità di risorse? Probabilmente no, perché come faccio a cogliere il momento dell'interruzione?
  • Qual è l'ordine di questi costi di risorse - decine, centinaia di nanosecondi, microsecondi o decine e centinaia di microsecondi? Sarebbe interessante ottenere tali informazioni.

Ehz, misurando cosa? Gli interruttori sono hardware, sono gestiti dal sistema operativo, naturalmente con l'aiuto di driver.

timer? - se non mi sbaglio, il timer non può colpire la coda dei messaggi a meno che il processo non lo stia elaborando, qualcosa che riguarda l'OS foolproofing, cercate WM_TIMER - dovrebbe essere dettagliato

l'ordine dei numeri? solo il clock del processore può essere misurato e poi moltiplicato per il fattore di calcolo del processore, è stato discusso quihttps://www.mql5.com/ru/forum/352454#comment_18588098 , google tonnellate di informazioni sulla misurazione delle prestazioni

 
Renat Fatkhullin:

Andate a studiare l'argomento (per almeno 10 anni) e non gettate rifiuti in questo thread, per favore.

Qui discutiamo di questioni con una formazione diversa e una classe diversa.

Tutti dovrebbero essere mandati qui, non selettivamente )) Ma come sempre si fa prendere a calci nel cappello da chi fa domande adeguate.
Dopo aver imparato che i gestori vengono eseguiti in modalità bloccante, non ho tirato fuori questo argomento per niente.
Ho toccato il vero nocciolo del problema, e non vi piace. OK, lascerò cadere l'argomento.
Ma non vedo l'utilità di ottenere eventi tempestivi nell'elaborazione sincrona.
Slava, Nikolay, Valery grazie per il dialogo costruttivo.

 
Igor Makanu:

non succede niente dal processore 286? hhz, non mi ricordo e non me ne sono mai occupato, ma sicuramente dal Pentium-1 (ho letto un libro su questo, molto tempo fa però)
È l'hardware tutto fatto, non è misurabile, è il cosiddetto core del processore che distingue ogni linea di processori Intel, non è la cache!

Bene se lo è.
Penso che lo sia. Quasi tutto è a livello di hardware. Altrimenti il multithreading non sarebbe così efficiente.

 
Nikolai Semko:

Bene se è così.
Penso che lo sia. Quasi tutto è a livello di hardware. Altrimenti il multithreading non sarebbe così efficace.

solo come questo

google: modalità protetta dal processore

Se non mi sbaglio, la modalità protetta dà al kernel del sistema operativo un livello di privilegio separato e a causa della memoria virtuale per ogni processo - è impossibile ottenere i dati RAM per il programma in esecuzione...beh, a meno che non lo si esegua sotto debugger come un processo separato.... che è un'altra area di competenza ))))

ma, inequivocabilmente, tutto funziona a livello di hardware, è impossibile misurarlo, solo gli strumenti del sistema operativo - e lo scambio di memoria virtuale per i processi è istantaneo, e il processore stesso funziona sulla frequenza interna - moltiplicatore della CPU... e se si comincia a pensare alla cache... Perché? - c'è un problema, cerca una soluzione! vuoi scrivere un driver? )))

SZZ: si può scrivere un driver, mi ricordo quando ho usato TCP-logger, era installato come un driver e registrava tutto il traffico e poi per processi nella tabella mostrava tutto il traffico.... solo una cosa per pensare come la scrittura di driver aiuterà a sviluppare TCP redditizio ))))



UPD: Hubr "Cos'è la modalità protetta e cosa fa"https://habr.com/ru/post/118881/

UPD: privilegio a livello hardware (CPU) per l'esecuzione di codice - WikiAnelli Protetti

 
Renat Fatkhullin:

Si garantisce sempre di avere dei fallimenti su singoli campioni casuali di qualsiasi istruzione, compreso il più semplice tipo di assembler inc eax. Questo è architettonicamente e a causa delle limitazioni fisiche di "assegnare onestamente i quanti di tempo di migliaia di thread a un piccolo numero di core".

Smettete di essere stupidi e continuate a catturare singoli outlier per milione di richieste.

Ho notato che CopyTicks ritarda raramente. Ho scritto uno script di prova

#include <fxsaber\Benchmark\Benchmark.mqh> // https://www.mql5.com/ru/code/31279

void OnTick()
{
  Sleep(1000);
  
  MqlTick Tick[1];
  
  _B(CopyTicks(_Symbol, Tick, COPY_TICKS_ALL, 0, 1), 100);
  _B(SymbolInfoTick(_Symbol, Tick[0]), 100);
}

e l'ha eseguito in modalità stress. SymbolInfoTick ha notevolmente più avvisi di CopyTicks.


Nessuna lamentela. Solo vorrei capire, cosa influisce sulla diversa percezione del carico di stress nelle implementazioni di queste funzioni?

1...686970717273747576777879808182...94
Nuovo commento