Programmazione asincrona e multithread in MQL - pagina 23
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
Spiegatemi cosa c'è di sbagliato in opencl. Il terminale implementa la capacità di scrivere codice opencl, e questo è multithreading. Voglio capire da solo quali sono le differenze del multithreading che è scritto qui e questa caratteristica.
Non ci sono schede video sui server VPS, o è molto poco redditizio se lo sono ))
Anche la maggior parte degli utenti in locale, le schede video non supportano opencl))
Per non parlare della complessità di scrivere codice adeguato per opencl.
Sì, c'è un'opzione, ma per una cerchia molto ristretta di persone.
Le schede video non sono disponibili sui server VPS, o molto poco redditizie se sono disponibili ))
Anche la maggior parte degli utenti di un sito locale non supporta opencl))
Per non parlare della complessità di scrivere codice adeguato per opencl.
Opzione sì, c'è, ma per una cerchia molto ristretta di persone.
Su un processore opencl, funziona anche. Dovete semplicemente selezionare il dispositivo che eseguirà il codice. Non è solo la tecnologia della scheda video. Sui server, so che ci sono problemi con le schede video.
Ma non sapevo che opencl funziona anche sulle CPU. Non riesco ancora a raggiungere l'articolo di Renat per leggere di opencl.
Ho letto un post su opencl anche qui, ma non posso avere tutti i programmatori su opencl, i metodi standard dei compiti dalla scatola sembrano più utilizzabili.
Allora, opencl funziona su qualsiasi processore? O dipende anche dal modello?
Ma non sapevo che opencl funziona anche sui processori. Non riesco ancora a raggiungere l'articolo di Renat per leggere di opencl.
Ho letto un post su opencl anche qui, ma non si possono mettere tutti i programmatori su opencl, i metodi standard dei compiti fuori dalla scatola sembrano più utilizzabili.
Quindi, opencl funziona su qualsiasi processore? O dipende anche dal modello?
Sembra che sì, dovrebbe funzionare su Intel e amd, devi solo installare i driver. L'ho provato su Amd e ha funzionato.
Si scopre che, in ogni caso, un certo grado di dipendenza dipende dal modello di processore o dai driver.
Questo potrebbe non essere adatto a tutti, per esempio a coloro che distribuiscono (vendono) il loro lavoro.
Ci sono persone che si preoccupano della portabilità del programma, secondo me è anche un parametro importante.
opencl può funzionare con dll personalizzate?
cioè chiamare asincronicamente le funzioni esportate dalla dll?
Se avessimo una classe interna per lavorare con i compiti, potremmo chiamare le nostre funzioni dalla dll in modo asincrono.
Cioè, la funzionalità regolare è molto più utilizzabile, e più accessibile nella scrittura del codice.
Peccato che non abbiamo sentito il capo del dipartimento dei trasporti - quale compito specifico vuole implementare il multi-threading? Disegna un semplice diagramma a blocchi della soluzione proposta.
State ostinatamente cercando di infilare un compito MKL per il quale non era originariamente previsto. In una parola, per niente. Ci sono soluzioni già pronte - guardate ZeroMQ che ha API per quasi tutti i JD. Inoltre il gentile Ding Li ha sviluppato una libreria per ZeroMQ usando MQL4/5 con una serie di esempi. Si prega di leggere il thread del forum su questo argomento con esempi pratici di codice.
Perché tu (l'iniziatore dell'argomento) spingi l'acqua in una pentola? O siete anche voi legati al mercato?
Buona fortuna
Opencl sa come lavorare con le dll personalizzate?
Cioè chiamare asincronicamente le funzioni esportate dalla dll?
C'era una classe interna per lavorare con i compiti, si potevano chiamare le funzioni dalla dll anche in modo asincrono.
Cioè, la funzionalità regolare è molto più utilizzabile, e più accessibile nella scrittura del codice.
Chiama la funzione DLL. Si crea un thread nella DLL e si trasferiscono dati ad esso, si disconnette il thread e ci si dimentica di esso - terminerà da solo dopo aver completato il suo compito. Quando si disconnette il thread nella DLL, il thread del terminale viene rilasciato. L'intero processo richiede, credo, meno di un millisecondo. A giudicare dal fatto che anche senza disconnettere il thread, il processo di scrittura nel database è di 4-5 ms. Bene, e 60 ticks/min è sufficiente per non essere triste per la chiamata asincrona dal terminale.
Peccato che non abbiamo sentito il capo del dipartimento dei trasporti - quale compito specifico vuole implementare il multi-threading? Disegna un semplice diagramma a blocchi della soluzione proposta.
State ostinatamente cercando di infilare un compito MKL per il quale non era originariamente previsto. In una parola, per niente. Ci sono soluzioni già pronte - guardate ZeroMQ che ha API per quasi tutti i JD. Inoltre il gentile Ding Li ha sviluppato una libreria per ZeroMQ usando MQL4/5 con una serie di esempi. Si prega di leggere il thread del forum su questo argomento con esempi pratici di codice.
Perché tu (l'iniziatore dell'argomento) spingi l'acqua in una pentola? O siete anche voi legati al mercato?
Buona fortuna
Cerco di non usare soluzioni di terzi.
Ho già trovato una soluzione per il mio problema di rete; tutto quello che resta da fare è studiarla, applicarla e non fottermi il cervello.
Ma ci sono anche programmatori che hanno bisogno di chiamate non bloccanti e di asincronia.
Ecco perché ho suggerito di implementare questa funzionalità nella consegna standard della lingua. E sta agli sviluppatori, la cosa principale è l'idea, ed è sensata.
Perché pensate che il terminale non sia progettato per implementare EventLoop? Soprattutto fin dall'inizio...
Quale algoritmo viene usato per eseguire gli agenti locali? Probabilmente in un pool di thread, giusto? Chi li gestisce, distribuisce i compiti?
Quindi, il terminale ha già un tale algoritmo, perché non usarlo per estendere la sua funzionalità?
Dare ai programmatori una modalità asincrona di scrittura del codice.
Io sono per l'idea, se nessuno ne ha bisogno in modo asincrono, beh cosa posso dire, mi dispiace solo che molti sono bloccati in un thread.
Chiamare la funzione DLL. Si crea un thread nella DLL e si trasferiscono i dati ad esso, si disconnette il thread e ci si dimentica di esso - esso completa il suo compito da solo. Quando si disconnette il thread nella DLL, il thread del terminale viene rilasciato. L'intero processo richiede, credo, meno di un millisecondo. A giudicare dal fatto che anche senza disconnettere il thread, il processo di scrittura nel database è di 4-5 ms. Beh, 60 ticks/s sono sufficienti per non essere triste per la chiamata asincrona dal terminale.
Ecco, grazie per un'altra idea, posso scrivere dll secondo gli articoli locali, ma purtroppo non descrivono la procedura del punto d'entrata, l'inizializzazione, l'allocazione della memoria, la creazione di thread, ecc.
Non riesco a trovare nessuna letteratura su questo argomento, non riesco a trovare come gestire correttamente il punto di ingresso. Se c'è qualche informazione su questo argomento, per favore fatemelo sapere.
O se potete insegnarmi, sarò felice di accettare la conoscenza.
Non ho studiato come programmatore, tutto quello che imparo da solo, quindi, non cacciatemi noia ))
Spiegatemi cosa c'è di sbagliato in opencl. Il terminale implementa la capacità di scrivere codice opencl, e questo è multithreading. Voglio capire da solo quali sono le differenze del multithreading che è scritto qui e questa caratteristica.