MT5 y la velocidad en acción - página 71
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Sugiero que este es el fin de la teorización, que nunca se cruzará con la práctica aquí.
Entonces te sugiero que también dejes las pruebas sincrónicas de un solo hilo sin sentido.
Esperando obtener resultados paralelos.
El problema no se resuelve de ninguna manera. Los programas MQL se complicarán en un orden de magnitud, si las variables internas, por ejemplo, se leen desde diferentes hilos.
Es que MQL6 debería ser similar a Erlang, no a C++ )
Entonces te sugiero que dejes también las pruebas sincrónicas de un solo hilo sin sentido.
Esperando obtener resultados paralelos.
Me preocupa que se produzcan rezagos de gran magnitud en casi todos los ticks. No tiene nada que ver con los hilos. Los desarrolladores se están dando cuenta.
Es que MQL6 debería ser similar a Erlang, no a C++ )
entonces Scala es mejor.
.... pero no importa cómo se mire, detrás de las envolturas de estos lenguajes funcionales fuertes con tipado dinámico... seguirá siendo máquina C++, Python es una prueba de ello, el discutido java con bucles de eventos es de otra galaxia donde se necesita tener un sistema multiprocesador distribuido para conseguir algún tipo de expansión y escalabilidad del sistema informático
En la escuela.
- Vovochka, ¿cómo se utiliza la pelusa de pollo?
- No lo sé.
- Bueno, ¿con qué duermes?
- En el suelo.
- ¿Y en qué pones la cabeza?
- En una bota de fieltro.
- ¿Y en qué duermen tus padres?
- En el suelo.
- ¿Y en qué ponen la cabeza?
- En el valenki.
- ¿Y en qué duerme la abuela?
- En la estufa.
- ¿Y en qué pone la cabeza?
- En una almohada.
- Y en la almohada, ¿qué es la pelusa?
- Y en la almohada hay un valenki.
Scala es mejor entonces
.... pero no importa cómo se mire, detrás de las envolturas de estos lenguajes funcionales fuertes con tipado dinámico... Python es una prueba de ello, el discutido java con los bucles de eventos es de otra galaxia donde hay que tener un sistema multiprocesador distribuido para conseguir algún tipo de extensibilidad y escalabilidad del sistema computacional.
Esa es la cuestión, Python está escrito en C y Python tiene una biblioteca asyncio que se basa en el modelo de bucle de eventos.
Hasta aquí la anécdota de la hilera ))
entonces Scala es mejor.
Lo principal es compilar en VHDL y hacer tu propio servidor)
La discusión se ha desviado hacia algún lado - la velocidad de integración con Python es, por supuesto, una cuestión importante, pero hay muchos problemas básicos que afectan a la velocidad de ejecución de los EAs.
Sugiero centrarse en el problema de que en la función OnTradeTransaction en la llamada final de TRADE_TRANSACTION_HISTORY_ADD los campos de las estructuras MqlTradeTransaction y MqlTradeResult están prácticamente vacíos, es decir, no se rellenan por analogía con cómo se refleja luego la orden en la pestaña de Historial y cómo se archivan en Ayuda/Documentación. La corrección de este defecto ya supondría una aceleración real en la ejecución del combate, ya que no sería necesario llamar innecesariamente a HistoryOrderSelect para obtener valores exhaustivos sobre la orden ejecutada.
Y en general, a nivel de la comunidad Mql, la eliminación de esta brecha supondrá una reducción masiva del esfuerzo necesario para crear diferentes muletas en los Asesores Expertos para sortear las deficiencias de la actual implementación de OnTradeTransactio.
La pregunta es ¿cómo influir en el equipo de MQ? ¿Quizás un post aparte con votación y recogida de firmas para la eliminación de esta deficiencia de esta función?
La cuestión es cómo influir en el equipo de desarrollo de MQ.
Mi receta parece funcionar: reproducir el problema con un código conciso.
La discusión se ha desviado hacia algún lado - la velocidad de integración con Python es, por supuesto, una cuestión importante, pero hay muchos problemas básicos que afectan a la velocidad de ejecución de los EAs.
Sugiero centrarse en el problema de que en la función OnTradeTransaction en la llamada final de TRADE_TRANSACTION_HISTORY_ADD los campos de las estructuras MqlTradeTransaction y MqlTradeResult están casi vacíos, es decir, no se rellenan por analogía con cómo se refleja luego la orden en la pestaña Historial y cómo se archivan en Ayuda/Documentación. La corrección de este defecto ya supondría una aceleración real en la ejecución del combate, ya que no sería necesario llamar innecesariamente a HistoryOrderSelect para obtener valores completos sobre la orden ejecutada.
Y en general, a nivel de la comunidad Mql, la eliminación de esta brecha supondrá una reducción masiva del esfuerzo necesario para crear diferentes muletas en los Asesores Expertos para sortear las deficiencias de la actual implementación de OnTradeTransactio.
La pregunta es ¿cómo influir en el equipo de MQ? ¿Quizás un post aparte con votación y recogida de firmas para la eliminación de esta deficiencia de esta función?
Python es un buen ejemplo de modelo basado en eventos. Y la anécdota de Igor da exactamente en el clavo.
Y si el promotor ha captado el significado del ejemplo, entonces sabe dónde cavar.
Cualquier expectativa de resultado oportuno antes o después se basa en un modelo de ejecución sincrónica.
En mql ha llegado. Las posibilidades del lenguaje son muy ricas, pero están limitadas artificialmente a la ejecución sincrónica.
Roman:
Не понимание примера с Python, говорит о не понимании обсуждения асинхронности в целом.
Tú eres el que no entiende, no desordenes el hilo.