Il mio approccio. Il nucleo è il motore. - pagina 123
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
...
ZS. È possibile, però, che il processore sia sovraccaricato dal ridisegno. Cioè, disegnare all'interno di un array di pixel. In altre parole, l'inizializzazione costante dell'array con valori, che si verifica ad alta (16ms) frequenza del timer.
No, ridisegnare non carica il processore in alcun modo; ci vogliono alcuni nano o al massimo microsecondi per inviare un comando al driver grafico. Il processore della scheda video esegue la pittura stessa, pixel per pixel, mentre di solito ce ne sono centinaia e lavorano simultaneamente con il processore in parallelo. Cioè, il processore emette il comando al driver grafico: visualizza un cerchio con il centro nelle coordinate dello schermo Xc, Yc e raggio R in modalità CopyPut. Per il processore questa è solo una chiamata di funzione con parametri passati. Non va oltre questo. Tali chiamate non fanno più spesso di, per esempio, 2 volte al secondo, altrimenti l'utente semplicemente non può capire nulla sullo schermo, non può essere tirato così spesso. Per una lista di compravendite aperte, si può immaginare che possa richiedere un'ora o un giorno o più.
E l'algoritmo (cercate su Google "Bresenham Algorithm", per esempio) della colorazione pixel per pixel è eseguito dalla scheda grafica, e il processore non vi si sofferma. Si esegue anche molto rapidamente. E... una volta per chiamata. Nessuna reinizializzazione a 16ms è richiesta, l'immagine dello schermo è mantenuta costante nella memoria video fino a quando un nuovo cambiamento è fatto al comando del processore. Non solo, per accelerare la risposta dello schermo visibile, la memoria video è anche tenuta in due istanze, le modifiche sono fatte su quella invisibile, e poi la pagina video viene commutata immediatamente.
Se il tuo approccio all'output dello schermo ha ancora la "costante inizializzazione dell'array" di pixel che descrivi - dovresti liberartene, non è il caso.
Clicca per vedere.
C'è qualcosa che non va nei dati della colonna Opening Time nell'immagine.
No, ridisegnare non carica il processore in alcun modo; ci vogliono alcuni nano o microsecondi al massimo per inviare un comando al driver grafico. I processori della scheda video eseguono la pittura stessa, pixel per pixel, mentre di solito ce ne sono centinaia e lavorano contemporaneamente al processore, in parallelo. Cioè, il processore emette il comando al driver grafico: visualizza un cerchio con il centro nelle coordinate dello schermo Xc, Yc e raggio R in modalità CopyPut. Per il processore questa è solo una chiamata di funzione con parametri passati. Non va oltre questo. Tali chiamate non fanno più spesso di, per esempio, 2 volte al secondo, altrimenti l'utente semplicemente non può capire nulla sullo schermo, non può essere tirato così spesso. Per una lista di compravendite aperte, si può immaginare che possa richiedere un'ora o un giorno o più.
E l'algoritmo (cercate su Google "Bresenham Algorithm", per esempio) della colorazione pixel per pixel è eseguito dalla scheda grafica, e il processore non vi si sofferma. Si esegue anche molto rapidamente. E... una volta per chiamata. Nessuna reinizializzazione a 16ms è richiesta, l'immagine dello schermo è mantenuta costante nella memoria video fino a quando un nuovo cambiamento è fatto al comando del processore. Non solo, per accelerare la risposta dello schermo visibile, la memoria video è anche tenuta in due istanze, le modifiche sono fatte su quella invisibile e poi la pagina video viene commutata immediatamente.
Se il tuo approccio all'output dello schermo ha ancora l'" inizializzazione permanente dell'array" di pixel che descrivi - dovresti liberartene, non è il caso.
Che pasticcio...
È un'accozzaglia di conoscenze frammentarie...
Alla fine, non è così che funziona.
No, ridisegnare non carica il processore in alcun modo; ci vogliono alcuni nano o microsecondi al massimo per inviare un comando al driver grafico. I processori della scheda video eseguono la pittura stessa, pixel per pixel, mentre di solito ce ne sono centinaia e lavorano contemporaneamente al processore, in parallelo. Cioè, il processore emette il comando al driver grafico: visualizza un cerchio con il centro nelle coordinate dello schermo Xc, Yc e raggio R in modalità CopyPut. Per il processore questa è solo una chiamata di funzione con parametri passati. Non va oltre questo. Tali chiamate non fanno più spesso di, per esempio, 2 volte al secondo, altrimenti l'utente semplicemente non può capire nulla sullo schermo, non può essere tirato così spesso. Per una lista di compravendite aperte, si può immaginare che possa richiedere un'ora o un giorno o più.
E l'algoritmo (cercate su Google "Bresenham Algorithm", per esempio) della colorazione pixel per pixel è eseguito dalla scheda grafica, e il processore non vi si sofferma. Si esegue anche molto rapidamente. E... una volta per chiamata. Nessuna reinizializzazione a 16ms è richiesta, l'immagine dello schermo è mantenuta costante nella memoria video fino a quando un nuovo cambiamento è fatto al comando del processore. Non solo, per accelerare la risposta dello schermo visibile, la memoria video è anche tenuta in due istanze, le modifiche sono fatte su quella invisibile, e poi la pagina video viene commutata immediatamente.
Se il tuo approccio all'output ha ancora la " inizializzazione costante dell'array" di pixel - devi sbarazzartene.
Hai una teoria interessante, anche se non si adatta del tutto ai risultati dei miei esperimenti, che ora posterò qui sotto.
Come mostra il test, è l'inizializzazione dell'array di pixel che carica maggiormente la CPU.
Controlla il test EA qui sotto.
Devo ammettere che sono stato un po' sorpreso dai risultati del test.
E così, stiamo parlando di chiamate di funzioni costanti ad una frequenza di 16 ms.
Si scopre che è l'inizializzazione dell'array di pixel durante il disegno che carica maggiormente il processore.
Ma la cosa più strana era che la chiamata di funzione ripetuta
caricherebbe il processore dal 10 al 15%.
Inoltre, le chiamate
caricare il processore dello stesso 10-15%.
Allo stesso tempo, le chiamate simultanee di tutte e tre le funzioni
Non provoca l'impilamento del carico. Il carico è ancora del 10-15%.
Tuttavia, se si aggiunge a queste chiamate un ciclo di reinizializzazione costante dell'array di un milione di celle
allora il carico della CPU sale al 50%.
//-----------------------------------------------------------------------------------------------------------------------------------------------------
La funzione stessa
non carica il processore.
La funzione
caricherà dallo 0 al 5% a seconda della dimensione dell'array Arr[].
Ecco un consigliere di prova. Devi commentare le linee e controllare il carico della CPU nel task manager.
Ecco il suo codice:
C'è qualcosa che non va con i dati nella colonna del tempo di apertura nell'immagine.
Sì, ho usato TimeToStr(OrderOpenPrice(),TIME_MINUTES|TIME_SECONDS);
Non so perché sia così.
Devo ammettere che sono stato un po' sorpreso dai risultati del test.
E così, stiamo parlando di chiamate di funzioni costanti ad una frequenza di 16 ms.
Si scopre che è l'inizializzazione dell'array di pixel durante il disegno che carica maggiormente il processore.
Ma la cosa più strana era che la chiamata di funzione ripetuta
caricherebbe il processore dal 10 al 15%.
Inoltre, le chiamate
caricare il processore dello stesso 10-15%.
Allo stesso tempo, le chiamate simultanee di tutte e tre le funzioni
Non provoca l'impilamento del carico. Il carico è ancora del 10-15%.
Tuttavia, se si aggiunge a queste chiamate un ciclo di reinizializzazione costante dell'array di un milione di celle
allora il carico della CPU sale al 50%.
//-----------------------------------------------------------------------------------------------------------------------------------------------------
La funzione stessa
non carica il processore.
La funzione
carica dallo 0 al 5%, a seconda della dimensione dell'array Arr[].
Devo ammettere che sono stato un po' sorpreso dai risultati del test.
Quindi, stiamo parlando di chiamate di funzioni costanti a 16 msec.
Si scopre che è l'inizializzazione di un array di pixel durante il disegno che carica il processore più di tutto.
Ma la cosa più strana era che la chiamata di funzione ripetuta
caricherebbe il processore dal 10 al 15%.
Inoltre, le chiamate
caricare il processore dello stesso 10-15%.
Allo stesso tempo, le chiamate simultanee di tutte e tre le funzioni
Non provoca l'impilamento del carico. Il carico è ancora del 10-15%.
Tuttavia, se si aggiunge a queste chiamate un ciclo di reinizializzazione costante dell'array di un milione di celle
allora il carico della CPU sale al 50%.
//-----------------------------------------------------------------------------------------------------------------------------------------------------
La funzione stessa
non carica il processore.
La funzione
caricherà dallo 0 al 5% a seconda della dimensione dell'array Arr[].
Peter, c'è la forte sensazione che tu non ascolti nulla di quello che ti è stato detto per centinaia di pagine.
Rileggete il thread - ci sono delle risposte alla domanda "perché"
Sì, ho usato TimeToStr(OrderOpenPrice(),TIME_MINUTES|TIME_SECONDS);
Non so perché.
Perché invece di OrderOpenPrice metti OrderOpenTime()