MT5 e la velocità in azione - pagina 71
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
Suggerisco che questa è la fine della teorizzazione, che qui non si intersecherà mai con la pratica.
Allora vi suggerisco di fermare anche gli inutili test sincroni a thread singolo.
Aspettandosi di ottenere risultati paralleli.
Il problema non è risolto in alcun modo. I programmi MQL diventeranno più complicati di un ordine di grandezza, se le variabili interne, per esempio, vengono lette da diversi thread.
È solo che MQL6 dovrebbe essere simile a Erlang, non a C++ )
Allora vi suggerisco di fermare anche gli inutili test sincroni a thread singolo.
Aspettandosi di ottenere risultati paralleli.
Sono preoccupato per i lag di grande entità che si verificano quasi ad ogni tick. Non ha niente a che fare con i fili. Gli sviluppatori lo stanno capendo.
È solo che MQL6 dovrebbe essere simile a Erlang, non a C++ )
allora Scala è meglio.
.... ma non importa come la si guardi, dietro gli involucri di questi forti linguaggi funzionali con tipizzazione dinamica... sarà ancora la macchina C++, Python è una prova di questo, il discusso java con cicli di eventi è da un'altra galassia dove è necessario avere un sistema multiprocessore distribuito per ottenere una sorta di espansione e scalabilità del sistema di calcolo
A scuola.
- Vovochka, come si usa la polvere di pollo?
- Non lo so.
- Beh, su cosa dormi?
- Sul pavimento.
- E su cosa si mette la testa?
- Su uno stivale di feltro.
- E i tuoi genitori su cosa dormono?
- Sul pavimento.
- E su cosa mettono la testa?
- Sul valenki.
- E su cosa dorme la nonna?
- Sui fornelli.
- E su cosa mette la testa?
- Su un cuscino.
- E nel cuscino, cos'è la peluria?
- E nel cuscino c'è un valenki.
Scala è meglio allora
.... ma non importa come la si guardi, dietro gli involucri di questi forti linguaggi funzionali con tipizzazione dinamica... Python è una prova di questo, il discusso java con i cicli di eventi è di un'altra galassia dove si deve avere un sistema multiprocessore distribuito per ottenere un certo tipo di estensibilità e scalabilità del sistema computazionale.
Questo è il punto, Python è scritto in C e Python ha una libreria asyncio che è basata sul modello di ciclo di eventi.
Alla faccia dell'aneddoto dell'andana ))
allora Scala è meglio.
La cosa principale è compilare in VHDL e fare il proprio server)
La discussione è andata da qualche parte di traverso - la velocità di integrazione con Python è ovviamente una questione importante, ma ci sono molti problemi di base che influenzano la velocità di esecuzione degli EA.
Suggerisco di concentrarsi sul problema che nella funzione OnTradeTransaction nella chiamata finale di TRADE_TRANSACTION_HISTORY_ADD i campi delle strutture MqlTradeTransaction e MqlTradeResult sono quasi vuoti, cioè non sono riempiti per analogia con come l'ordine si riflette in seguito nella scheda History e come sono archiviati nella Guida/Documentazione. La correzione di questo difetto darebbe già una reale accelerazione nell'esecuzione del combattimento, poiché non ci sarebbe bisogno di chiamare inutilmente HistoryOrderSelect per ottenere valori esaustivi sull'ordine eseguito.
E nel complesso, a livello di comunità Mql, l'eliminazione di questa lacuna porterà a una massiccia riduzione dello sforzo richiesto per creare diverse stampelle in Expert Advisors per aggirare le carenze dell'attuale implementazione di OnTradeTransactio.
La domanda è come influenzare il team di MQ? Forse un post separato con la votazione e la raccolta di firme per l'eliminazione di questo difetto di questa funzione?
La domanda è come influenzare il team di sviluppo di MQ?
La mia ricetta sembra funzionare: riprodurre il problema con un codice conciso.
La discussione è andata da qualche parte di traverso - la velocità di integrazione con Python è ovviamente una questione importante, ma ci sono molti problemi di base che influenzano la velocità di esecuzione degli EA.
Suggerisco di concentrarsi sul problema che nella funzione OnTradeTransaction nella chiamata finale di TRADE_TRANSACTION_HISTORY_ADD i campi delle strutture MqlTradeTransaction e MqlTradeResult sono quasi vuoti, cioè non sono riempiti per analogia con come l'ordine si riflette poi nella scheda History e come sono archiviati nella Guida/Documentazione. La correzione di questo difetto darebbe già una reale accelerazione nell'esecuzione del combattimento, poiché non ci sarebbe bisogno di chiamare HistoryOrderSelect inutilmente per ottenere valori completi sull'ordine eseguito.
E nel complesso, a livello di comunità Mql, l'eliminazione di questa lacuna porterà a una massiccia riduzione dello sforzo richiesto per creare diverse stampelle in Expert Advisors per aggirare le carenze dell'attuale implementazione di OnTradeTransactio.
La domanda è come influenzare il team di MQ? Forse un post separato con il voto e la raccolta di firme per l'eliminazione di questo difetto di questa funzione?
Python è un buon esempio di un modello event-driven. E l'aneddoto di Igor è esattamente sul punto.
E se lo sviluppatore ha afferrato il significato dell'esempio, allora sa dove scavare.
Qualsiasi aspettativa di un risultato tempestivo prima o poi si basa su un modello di esecuzione sincrono.
In mql è arrivato. Le possibilità del linguaggio sono molto ricche, ma artificialmente limitate all'esecuzione sincrona.
Roman:
Не понимание примера с Python, говорит о не понимании обсуждения асинхронности в целом.
Sei tu che non capisci, non ingombrare il thread.