Ancora una volta, riguardo al multithreading
Cari sviluppatori, ho fatto una ricerca sul tema del multithreading e ho trovato una frase in cui si diceva che non avevate intenzione di aggiungere funzioni che creano e gestiscono i thread in MQL5. È stato detto più di un anno e mezzo fa. Mi chiedo se le sue opinioni sono cambiate da allora?
Se ancora non volete preoccuparvene, perché non lasciare che gli utenti lo implementino da soli? Per questo abbiamo bisogno di un puntatore di funzione. Che ne dite di aggiungere una tale funzione? Cioè GetPointer(myfunc)
Inoltre, se volete spiegare perché non avete implementato il multi-threading in MQL5, perché avete riscontrato particolari difficoltà? O forse era solo una questione di principio?
Posso ricordarvi che non siamo più nell'anno 2000 e che i processori multicore sono diventati da tempo la norma per tutti, il numero di core non potrà che aumentare ogni anno. Ora sono 4, tra un paio d'anni saranno 6-8, ecc. E non permettete agli utenti di usare correttamente il processore con il programma che stanno eseguendo.
Che senso ha allora il tuo costante confronto di velocità tra MQL e C++, se stai confrontando solo il lavoro in un thread? Dopo tutto, nessun programmatore C++ ragionevole appenderebbe un compito ad alta intensità di risorse da un thread quando ci sono diversi processori che possono aumentare le prestazioni molte volte. Ecco perché tutti i vostri test hanno poca relazione con la vita reale. Tra qualche anno il core del processore crescerà fino a 10 core e voi sarete ancora orgogliosi dei vostri test MQL a thread singolo?
Per quanto riguarda l'uso di OpenCL, questo è sciamanesimo, specialmente nel modo in cui è implementato qui - attraverso la linea di testo. Cioè, si esegue il debug del codice da qualche altra parte, e poi lo si copia in MQL5... Che circo! Sarebbe quindi più facile implementare tutto questo in una DLL e importarla. Inoltre, poche persone vorrebbero scrivere un programma in diverse lingue.
Il multithreading in MQL5 è ancora disponibile, ma a differenza del C++, è implementato come un ambiente di esecuzione virtuale chiamato grafico.
Ogni grafico viene eseguito in un thread separato. Questo viene fatto per evitare una fastidiosa sincronizzazione dei thread, l'accesso ai dati e altri problemi che sorgono durante la comunicazione tra i thread.
Abbastanza brutto? Sì, ma per l'utente di massa (che già si lamenta della complessità del linguaggio) è proprio la cosa giusta.
Per quanto riguarda OpenCL, è una questione separata. Non era nemmeno nei piani di sviluppo della piattaforma. All'inizio, gli utenti del forum avanzato hanno attirato l'interesse degli sviluppatori su questo argomento, ma la risposta ufficiale è stata "no e non sarà". Ma poi la leadership del MQ ha cambiato la sua rabbia per la misericordia(grazie Ilyaz).
Riguardo alle Dll: MQ le considera potenzialmente pericolose, quindi ovunque si possa farne a meno si cerca di implementarle, specialmente per i servizi pubblici. Ma non li proibisce in generale, perché i programmatori scrivono non solo per il pubblico, ma anche per gli interlocutori.
Tutto sommato, sembrano pure affermazioni teoriche.
Non c'è niente di male nel multithreading e nell'uso completo dei processori nel terminale. Guarda quanti thread sono in esecuzione nel terminale e come il numero di thread cambia nel tempo. I principi del multi-threading sono stati spiegati e dimostrati molte volte. Per esempio, come funzionano i thread indipendenti di ricalcolo degli indicatori, ricalcolo dei simboli, paginazione dei dati del grafico e funzionamento indipendente di tutti gli Expert Advisors e degli script.
Per parallelizzare i calcoli di qualsiasi cosa, bisogna prima rendersi conto che solo una piccola parte della matematica può essere parallelizzata.
Guarda il tester multi-core, MQL5 Cloud Network e OpenCL. Abbiamo anticipato la curva per molto tempo, specialmente nel cloud computing. In questo momento, attivate la rete MQL5 Cloud Network nel vostro tester e ottenete fino a 14.000 CPU per aiutarvi:
Sembra che tu non sappia nulla nemmeno di OpenCL. Presentare il codice del programma in forma di sorgente da inviare al compilatore OpenCL è il modo usuale e standard di lavorare. Tenete a mente che i diversi gestori di OpenCL (Ndivia, AMD, Intel, ecc.) devono ottenere il codice e rielaborarlo per loro stessi.
- cloud.mql5.com
Cos'è il multithreading in MetaTrader 5:
Ho appena cliccato sul test, ha immediatamente ottenuto 5.743 agenti/CPU per lavorare ed eseguito 381.468 passaggi nell'ottimizzatore in 6 minuti. Ogni passaggio richiedeva tra 1 e 2 secondi per essere eseguito. Se avessi eseguito il test sul mio computer con 8 core, avrei impiegato da 800 a 1600 minuti invece di 6 minuti (381468 / 8 = 47683 secondi = 794 minuti).
E a parte premere il pulsante di avvio, non ho dovuto fare nient'altro. Qualche skynet si è alzato, ha sincronizzato da solo tutta la storia dei grafici necessaria, ha distribuito il compito a migliaia di computer in tutto il mondo e li ha fatti lavorare in massa.
Benvenuto nella realtà...
Renat,
domanda sulla creazione di thread all'interno di MQL5 Expert Advisor.
Renate,
La domanda sulla creazione di thread all'interno di MQL5 Expert Advisor.
Ne sono consapevole.
Non ho scritto che è meglio non parlare di multithreading a una persona che non capisce perché non esiste il multithreading in un linguaggio di calcolo applicato. Abbiamo implementato l'intera infrastruttura multi-threading del terminale in modo completo ed efficace.
Il vero multithreading è necessario in luoghi dove si possono effettivamente parallelizzare i compiti. Questo è un tester. E questo è il luogo in cui l'abbiamo implementato in modo tale che molte persone sono lontane dal capire la qualità, il controllo e il volume del lavoro svolto.
Il mio esempio con Claude è una semplice prova della qualità e del livello di elaborazione del compito.
Sì, Renat, non hai letto attentamente il mio post. Non stiamo parlando di multithreading di MT5, ma di multithreading di MQL5. Non possiamo creare questi thread in un programma in esecuzione da soli. L'apertura programmata di un nuovo grafico con un indicatore è una danza del tamburello, non una soluzione.
È incredibile, avete fatto un sacco di cose inutili in MQL5, considerando un utente di massa. E per quanto mi riguarda, siete concentrati principalmente sui manichini, non sui programmatori alfabetizzati. Da qui il cumulo di restrizioni, l'impossibilità di lavorare direttamente con la memoria, ecc. Quindi la domanda è: perché i manichini hanno bisogno, ad esempio, di classi?
Se posizionate il vostro prodotto non solo per dummies, perché non potete dare ai programmatori esperti l'opportunità di usare efficacemente le risorse del sistema?
La mancanza di multithreading non sarà compensata da nessuna classe. Per quanto intelligente possa sembrare un programma, ma se usa le risorse del sistema in modo inefficiente, è un peccato per tutti. Forse nella ricerca dell'innovazione avete dimenticato che il linguaggio MQL è destinato principalmente alla scrittura di programmi di trading e di analisi, e non alla programmazione per il gusto di programmare. Pertanto, la velocità e l'efficacia del programma, piuttosto che la velocità di scrittura del codice, dovrebbe essere la prima priorità. Perché il lavoro con grandi dimensioni di dati è previsto a priori.
Penso che le capacità di MQL4 saranno sufficienti per la maggior parte degli utenti. Le uniche cose che mancavano erano il supporto di strutture, puntatori a variabili e puntatori a funzioni (o il supporto integrato di funzioni di callback). E questo è tutto. Avendo questo arsenale, è possibile creare qualsiasi programma che funzioni in modo molto efficace, creare il numero richiesto di thread, callback, ecc.
carne, senza offesa, ma con questo livello di comprensione dei problemi all'asilo.
Ho letto tutto con attenzione, ma non ho la possibilità di dare un'istruzione completa. Ho 11 anni di esperienza nei linguaggi MQL/MQL2/MQL4/MQL5.
Non si tratta affatto di MT5 multithreading, ma di MQL5 multithreading. Non possiamo creare questi thread nel programma in esecuzione da soli. E il software che apre un nuovo grafico con un indicatore è, sarete d'accordo, una danza del tamburello, non una soluzione.
La cosa più sorprendente è che avete fatto così tante cose inutili in MQL5, se prendiamo in considerazione un utente di massa.
Se si prende un singolo utente, ci possono essere molte cose inutili. E quando si comincia ad allargare i propri orizzonti e sono richieste funzioni aggiuntive, si scopre che, al contrario, qualcosa c'è già, mentre qualcosa manca.
MQL5 è ancora in fase di sviluppo. Qualcosa di nuovo viene aggiunto poco a poco. Anche se, naturalmente, ci sono anche degli svantaggi, per esempio, non si possono creare i propri eventi, non ci sono gestori di eccezioni e il multithreading. Spero che tutto questo venga fuori un giorno? Ma dubito che sarà tutto implementato domani.
Se uno vuole davvero, il multi-threading è disponibile anche per testare gli agenti in OpenCL. Non è del tutto conveniente, ma è comunque presente e si possono parallelizzare i compiti.
carne, senza offesa, ma con questo livello di comprensione dei problemi all' asilo.
E tu dici che non è lo standard aziendale))
Se si fanno domande, significa che le risposte non sono in superficie...
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Accetti la politica del sito e le condizioni d’uso
Se ancora non volete preoccuparvene, perché non lasciare che gli utenti lo implementino da soli? Per questo abbiamo bisogno di un puntatore di funzione. Che ne dite di aggiungere una tale funzione? Cioè GetPointer(myfunc)
Inoltre, se volete spiegare perché non avete implementato il multi-threading in MQL5, perché avete riscontrato particolari difficoltà? O forse era solo una questione di principio?
Posso ricordarvi che non siamo più nell'anno 2000 e che i processori multicore sono diventati da tempo la norma per tutti, il numero di core non potrà che aumentare ogni anno. Ora sono 4, tra un paio d'anni saranno 6-8, ecc. E non permettete agli utenti di usare correttamente il processore con il programma che stanno eseguendo.
Che senso ha allora il tuo costante confronto di velocità tra MQL e C++, se stai confrontando solo il lavoro in un thread? Dopo tutto, nessun programmatore C++ ragionevole appenderebbe un compito ad alta intensità di risorse da un thread quando ci sono diversi processori che possono aumentare le prestazioni molte volte. Ecco perché tutti i vostri test hanno poca relazione con la vita reale. Tra qualche anno il core del processore crescerà fino a 10 core e voi sarete ancora orgogliosi dei vostri test MQL a thread singolo?
Per quanto riguarda l'uso di OpenCL, questo è sciamanesimo, specialmente nel modo in cui è implementato qui - attraverso la linea di testo. Quindi fai il debug del tuo codice da qualche altra parte, e poi lo copi in MQL5... Che circo! Sarebbe quindi più facile implementare tutto questo in una DLL e importarla. Inoltre, poche persone vorrebbero scrivere un programma in diverse lingue.