Il mio approccio. Il nucleo è il motore. - pagina 125

Nuovo commento
 
Реter Konow:

Quindi sono ridisegnati esattamente come hai detto tu.

E il carico sul processore viene dall'animazione:

C'è una costante reinizializzazione dei valori nell'array di pixel. Ogni 16 millisecondi. Questo carica il processore fino al 40%.

Stavo cercando di capire quale sia esattamente il carico. Ho pensato che si trattasse di salvare una risorsa o di leggerla. Si è scoperto che era la reinizializzazione dell'array nel ciclo di disegno.


Si è anche scoperto che una chiamata costante di ObjectSetInteger(0, "MT object",OBJPROP_SELECTED,1); (ogni 16 ms) carica anche il processore. Di circa il 10%.

Uso questa chiamata per dire a un altro EA di leggere la risorsa con i dati dell'animazione.

In totale, ottiene +~50% di carico della CPU durante l'animazione.

Scusa, non avevo notato che non si tratta più della lista delle compravendite aperte. Sparite, credo, le 2-3 pagine del thread.
 
Vladimir:
Scusa, non avevo notato che non si tratta più della lista delle compravendite aperte. Sparite, credo, 2-3 pagine del thread.

No, va bene. Ho appena portato il carico della CPU perché ho intenzione di rifare la comunicazione tra l'EA e il motore, il che significa che anche la tabella dei trade aperti prenderà i dati in modo diverso.

 
Perché avete bisogno di 64 fotogrammi al secondo (16ms), 32 fotogrammi al secondo sono sufficienti per l'occhio.
 
Nikolai Semko:
Perché fare il periris 64 fotogrammi al secondo (16 ms), per l'occhio è sufficiente 32 fotogrammi al secondo.

Bella domanda. In effetti, il timer non funziona bene. Ci sono dei salti. 16,32,16,16...

Se usate 32, i salti sono di 64 ms. E questo si nota. Inoltre, varie altre cose gravano e rallentano il disegno. Per esempio, la coda di eventi OnChartEvent().

Penso che influisca sulla qualità dell'animazione. Ho provato a usare 25 ms. Poi 16, e sono arrivato alla conclusione che 16 trasmette meglio un movimento fluido.

Più tardi skolnuyu motore con animazione 16 ms e 32 ms e vedrete voi stessi. Anche se forse sarà ok....

 
Реter Konow:

Bella domanda. In effetti, il timer non funziona bene. Ci sono dei salti. 16,32,16,16...

Se usate 32, i salti sono di 64 ms. E questo si nota. Inoltre, varie altre cose gravano e rallentano il disegno. Per esempio, la coda di eventi OnChartEvent().

Penso che influisca sulla qualità dell'animazione. Ho provato a usare 25 ms. Poi 16, e sono arrivato alla conclusione che 16 trasmette meglio un movimento fluido.

Più tardi skolnuyu motore con animazione 16 ms e 32 ms e vedrete voi stessi. Anche se forse sarà ok....

È solo che non è veramente 16ms, ma 1000/64=15.625ms. Ecco perché è meglio impostare 30 ms invece di 32 ms, allora ci saranno meno salti. cioè se si mette una pausa tra i fotogrammi di 33 ms, allora la pausa reale sarà 15,625×3=46,875 ms.
E devi ricordare che MT ha il suo gestore interno di aggiornamento dei grafici, quindi ChartRedraw lavorerà in modo asincrono e non c'è garanzia che MT li gestisca tutti.

 
Nikolai Semko:
È solo che non è veramente 16ms, ma 1000/64=15.625ms. Ecco perché è meglio impostare 30 ms invece di 32 ms, allora ci saranno meno salti. cioè se si mette una pausa tra i fotogrammi di 33 ms, allora la pausa reale sarà 15,625×3=46,875 ms.
E dobbiamo ricordare che MT ha il suo gestore interno di aggiornamento dei grafici, quindi ChartRedraw lavorerà in modo asincrono e non c'è garanzia che MT li gestisca tutti.

Perché? Semplice, interessante.

 
Алексей Тарабанов:

Perché? Semplice, mi chiedo.

Sono solo arrivato a queste conclusioni dopo molti esperimenti e il metodo del poking scientifico. Se qualcuno ha qualche esperimento che possa smentire le mie affermazioni, gliene sarei molto grato.
 
Nikolai Semko:
È solo che non è veramente 16ms, ma 1000/64=15.625ms. Ecco perché è meglio impostare 30 ms invece di 32 ms, allora ci saranno meno salti. cioè se si mette una pausa tra i fotogrammi di 33 ms, allora la pausa reale sarà 15,625×3=46,875 ms.
E non dobbiamo dimenticare che MT ha il suo gestore interno di aggiornamento dei grafici, quindi ChartRedraw lavorerà in modo asincrono e non c'è garanzia che MT li gestisca tutti.

Ok, ne terrò conto.

Ridurre la frequenza del timer ridurrà certamente il carico sul processore. Se non degrada la qualità dell'animazione, ottimo. Il carico della CPU può essere ridotto fino al 30%, ma lo sarà comunque.

Dovrete sopportarlo.

Certo, se il disegno fosse distribuito tra diversi thread, (ad esempio, parte dell'animazione disegna l'Expert Advisor, e parte il motore), allora il carico sarebbe quasi eliminato. Dobbiamo pensare...

 

Ahimè, la mia ipotesi non è stata confermata.

Ora ho fatto un esperimento - ho messo un EA su due grafici. L'Expert Advisor carica il processore del 50%.

Ho scoperto che anche quando si lavora con diversi grafici, il carico della CPU si somma e il carico totale della CPU dalla parte di MT è superiore al 90%.

Quindi, anche dividere i grafici tra diversi Expert Advisors non aiuterà. Il carico si sta accumulando!

 
Реter Konow:

Ahimè, la mia ipotesi non è stata confermata.

Ora ho fatto un esperimento - ho messo un EA su due grafici. L'Expert Advisor carica il processore del 50%.

Ho scoperto che anche quando si lavora con diversi grafici, il carico della CPU si somma e il carico totale della CPU dalla parte di MT è superiore al 90%.

Quindi, anche dividere i grafici tra diversi Expert Advisors non aiuterà. Il carico si sta accumulando!

Se è MT4, allora sì.
Da quanto ho capito MT5 supporta pienamente il multi-core e il multi-threading al contrario di MT4.
1...118119120121122123124125126127128129130131132...184
Nuovo commento