Fare un progetto in crowdsourcing su Canvas - pagina 33

 
Реter Konow:

In questo esempio, la frequenza di aggiornamento è normale. Ecco perché non rallenta.

In Task Manager vedo Metatrader (32 bit)
Forse la ragione dei vostri ritardi ha a che fare con la dimensione del bit?
Perché Metatrader è ora progettato solo per x64.
E secondo gli sviluppatori, le versioni a 32 bit non saranno più rilasciate.

È stato risolto il problema dell'elaborazione asincrona dei dati?
 
Roman:

Vedo Metatrader (32 bit) in Task Manager
Forse, la ragione della lentezza è legata alla capacità digitale del tuo sistema?
Bene, Metatrader è ora inteso solo per x64.
E secondo gli sviluppatori, le versioni a 32 bit non saranno più rilasciate.

Ed è stato risolto il problema dell'elaborazione asincrona dei dati?

Confermo che l'esempio di Nikolai che ho menzionato carica la CPU quando si sposta uno qualsiasi degli oggetti nell'esempio, specialmente se fatto velocemente. Il carico aumenta del 35-40%. Il test è stato condotto su un processore a 64 bit, Windows 7 a 64 bit e MT5 a 64 bit.

Cosa si intende per elaborazione asincrona nella nostra discussione?

 
Roman:

Posso vedere Metatrader (32 bit) in Task Manager.
Forse la ragione dei vostri ritardi risiede nella capacità di bit digit del sistema?
Infatti, Metatrader è ora personalizzato solo per x64.
E secondo gli sviluppatori, le versioni a 32 bit non saranno più rilasciate.

Ed è stato risolto il problema dell'elaborazione asincrona dei dati?

Tutti questi esempi sono su MT4.

MT5 tira molto di più, ma in caso di ridisegno errato (per esempio una tazza) carica anche il processore (ho controllato). Il problema è nella frequenza e nell'area di ridisegno, che dovrebbe essere ridotta con tutti i mezzi. Se dovete ridisegnare una cella, allora è l'unica cella. Altrimenti è uno spreco di risorse, (se per esempio una cella deve essere ridisegnata 10 volte al secondo, allora ridisegnare l'intera tela "ucciderà" il processore e non sarà realistico). Tuttavia, è già chiaro.

Lasciatemi spiegare. Una cella di tabella ha tre oggetti - base, testo e icona. Se il contenuto di una cella cambia, dobbiamo fare tre cicli della tela. Nel primo ciclo ridisegniamo la base, nel secondo ciclo - il testo, nel terzo - l'icona. È come se avessimo triplicato l'area della cella. Se continuate a ridisegnare l'intero kanvas in questo modo, otterrete un serio rallentamento. È quindi necessario prendere in considerazione il numero di cicli sull'area della tela da ridisegnare. Si può non vederlo in primitivi semplici, ma diventa evidente in elementi complessi. Alcuni elementi comprendono 10 oggetti(una casella di input con pulsanti o una lista di output o una piattaforma di finestre) ed è possibile calcolare quanti cicli su un array di kanvas devono essere fatti quando li si ridipinge. Fortunatamente, questo ridisegno non richiede un alto tasso di ripetizione.

Il problema dell'elaborazione asincrona non è stato risolto. Ci sono state alcune idee, ma nessuna soluzione è stata ancora trovata.

In generale, se vogliamo creare una GUI su tela, dovremmo crearla con elementi ridisegnabili separatamente. Altrimenti, il programma raggiungerà rapidamente il limite e dopo si noteranno i ritardi sulle operazioni semplici.

 
Алексей Барбашин:

Cosa si intende per elaborazione asincrona dei dati nella nostra discussione?

Beh, come ho capito in parole semplici, asincrono (a caccia di risorse) o multi-threaded (risorsa dedicata).
Non ho guardato il codice degli esempi di Nikolay, ma a causa dell'assenza di asincronia e multithreading inMetatrader il codice di ridisegno dei pixel viene eseguito in modo sincrono.
E anche l'elaborazione dei dati in uscita di Petera è molto probabilmente eseguita in modo sincrono. E in entrambi i casi è probabile che tutto questo sia ancora elaborato in cicli.
Questo aumenta il carico sul processore. Per una risposta veloce con meno carico alla volta, l'elaborazione e il ridisegno dei dati dovrebbero essere messi in parallelo.

 
Roman:

Bene, come lo capisco in parole semplici, asincrono (corsa alle risorse) o multithreading (risorsa dedicata).
Non ho guardato il codice degli esempi di Nikolay, ma a causa dell'assenza di asincronia e multithreading inMetatrader il codice di ridisegno dei pixel viene eseguito in modo sincrono.
E anche l'elaborazione dei dati in uscita di Petera è molto probabilmente eseguita in modo sincrono. E in entrambi i casi, è probabile che tutto questo venga elaborato in loop.
Questo aumenta il carico sul processore. Per una risposta veloce con meno carico alla volta, l'elaborazione e il ridisegno dei dati dovrebbero essere messi in parallelo.

Non proprio)) Mi spiego meglio: ho il motore che si collega all'applicazione utente tramite una risorsa. Cioè, - l'applicazione utente fa i suoi calcoli nel suo thread, e passa i dati al motore (che porta la GUI), che può essere su un altro grafico. Questo gestisce gli eventi dei parametri e li invia alla GUI. In altre parole, l'elaborazione è divisa in due thread. Tuttavia, questo non sarà il caso nel costruttore che posterò. L'applicazione includerà il motore al suo interno e tutto sarà in un unico thread. Ma il carico sul processore sarà lo stesso. La dipendenza della velocità dalla sequenza di funzioni diventerà semplicemente più alta.

 
Реter Konow:

Non proprio)) Mi spiego meglio: ho il motore che si collega all'applicazione utente tramite una risorsa. Cioè, - l'applicazione utente fa i suoi calcoli nel suo thread, e passa i dati al motore (che porta la GUI), che può essere su un altro grafico. Questo gestisce gli eventi dei parametri e li invia alla GUI. In altre parole, l'elaborazione è divisa in due thread. Tuttavia, questo non sarà il caso nel costruttore che posterò. L'applicazione includerà il motore al suo interno e tutto sarà in un unico thread. Ma il carico sul processore sarà lo stesso. La dipendenza della velocità dalla sequenza di esecuzione delle funzioni diventerà semplicemente più alta.

Ci risiamo... promesse, annunci, chiacchiere.

anche già dimenticato - "kernel-engine" è stato pubblicato come un software decente? o come merda in forma di allegati ai commenti

 
Roman:

Bene, come ho capito in termini semplici, asincrono (corsa alle risorse) o multithreading (risorsa dedicata).
Non ho guardato il codice degli esempi di Nikolai, ma a causa dell'assenza di asincronia e multithreading inMetatrader, il codice di ridisegno dei pixel viene eseguito in modo sincrono.
E anche l'elaborazione dei dati in uscita di Petera è molto probabilmente eseguita in modo sincrono. E in entrambi i casi, è probabile che tutto questo venga elaborato in loop.
Questo aumenta il carico sul processore. Per una risposta veloce con meno carico alla volta, l'elaborazione e il ridisegno dei dati dovrebbero essere messi in parallelo.

Tutte le operazioni in MT sono strettamente sincrone e questo non può essere realmente cambiato a meno che gli sviluppatori non aggiungano dei thread all'applicazione.

È abbastanza sorprendente che gli sviluppatori stiano cercando di espandere le funzionalità di MT in termini di lavoro con i database, con python, con sharpe... ma si offrono di fare tutto nello stesso thread... È semplicemente incredibile.

 
Maxim Kuznetsov:

ci risiamo... promesse, annunci, chiacchiere

Ho anche dimenticato - il "kernel-engine" è stato pubblicato come un software decente? o come merda, come allegati ai commenti

Buon per te. L'ispirazione mi viene dalle lotte con persone come te, che perdono sempre)). Mi dai energia e non te ne rendi conto.

 
Maxim Kuznetsov:

ci risiamo... promesse, annunci, chiacchiere

Ho anche dimenticato - il "kernel-engine" è stato pubblicato come un software decente? o come merda in forma di allegati ai commenti

Max, sii discreto.

 
Реter Konow:

Non proprio)) Mi spiego meglio: ho il motore che si collega all'applicazione utente tramite una risorsa. Cioè, - l'applicazione utente fa i suoi calcoli nel suo thread, e passa i dati al motore (che porta la GUI), che può essere su un altro grafico. Questo gestisce gli eventi dei parametri e li invia alla GUI. In altre parole, l'elaborazione è divisa in due thread. Tuttavia, questo non sarà il caso nel costruttore che posterò. L'applicazione includerà il motore al suo interno e tutto sarà in un unico thread. Ma il carico sul processore sarà lo stesso. È solo che la dipendenza della velocità dalla sequenza di funzioni sarà maggiore.

Ho capito il punto, applicazione separata, GUI separata.
Ma l'elaborazione dei dati in uscita nella GUI viene eseguita comunque in modo sincrono.
Così, per esempio, l'applicazione invia 10000 elementi a GUI e GUI elabora tutti questi elementi in modo sequenziale.
Questo è il problema. È necessario parallelizzare l'elaborazione degli elementi in entrata e il loro output nella GUI. Base, testo, icona.
Inoltre, ci sono tre cicli per cella.