Programación asíncrona y multihilo en MQL - página 23
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
Explícame qué tiene de malo opencl. El terminal implementa la capacidad de escribir código opencl, y éste es multihilo. Quiero entender por mí mismo cuáles son las diferencias de multithreading que está escrito aquí y esta característica.
No hay tarjetas de video en los servidores VPS, o es muy poco rentable si las hay ))
Incluso la mayoría de los usuarios en local, las tarjetas de vídeo no son compatibles con opencl))
Por no hablar de la complejidad de escribir un código adecuado para opencl.
Sí, hay una opción, pero para un círculo muy reducido de personas.
Las tarjetas de vídeo no están disponibles en los servidores VPS, o son muy poco rentables si están disponibles ))
Incluso la mayoría de los usuarios de un sitio local no soportan opencl))
Por no hablar de la complejidad de escribir un código adecuado para opencl.
Opción sí, la hay, pero para un círculo muy reducido de personas.
En un procesador opencl también funciona. Basta con seleccionar el dispositivo que ejecutará el código. No se trata sólo de la tecnología de las tarjetas de vídeo. En los servidores, sé que hay problemas con las tarjetas de vídeo.
Pero no sabía que opencl también funciona en CPUs. Todavía no puedo llegar al artículo de Renat para leer sobre opencl.
También leí un post sobre opencl aquí, pero no consigo que todos los programadores estén en opencl, los métodos estándar de tareas de la caja parecen más utilizables.
Entonces, ¿funciona opencl en cualquier procesador? ¿O también depende del modelo?
Pero no sabía que opencl también funciona con procesadores. Todavía no puedo llegar al artículo de Renat para leer sobre opencl.
También leí un post sobre opencl aquí, pero no puedes poner a todos los programadores en opencl, los métodos estándar de tareas fuera de la caja parecen más utilizables.
Entonces, ¿funciona opencl en cualquier procesador? ¿O también depende del modelo?
Parece que sí, que debería funcionar en Intel y amd, sólo hay que instalar los drivers. Lo he probado en amd y ha funcionado.
Resulta que, de todos modos, cierto grado de dependencia depende del modelo de procesador o de los controladores.
Esto puede no ser adecuado para todos, por ejemplo, los que distribuyen (venden) su trabajo.
Hay gente que se preocupa por la portabilidad del programa, en mi opinión también es un parámetro importante.
¿Puede opencl trabajar con dlls personalizados?
es decir, ¿llamar asíncronamente a funciones exportadas desde la dll?
Si tuviéramos una clase interna para trabajar con tareas, podríamos llamar a nuestras propias funciones desde la dll de forma asíncrona.
Es decir, la funcionalidad regular es mucho más utilizable, y más accesible en la escritura de código.
Lástima que no hayamos escuchado al jefe del departamento de transporte: ¿qué tarea específica quiere implementar el multihilo? Dibuja un diagrama de bloques sencillo de la solución propuesta.
Te empecinas en meter una tarea de MKL para la que no estaba pensada originalmente. En una palabra, en absoluto. Hay soluciones ya hechas - mira ZeroMQ que tiene API para casi todos los JDs. Además, el amable Ding Li desarrolló una biblioteca para ZeroMQ usando con MQL4/5 con un conjunto de ejemplos. Por favor, lea el hilo del foro sobre este tema con ejemplos prácticos de código.
¿Por qué estás (el iniciador del tema) empujando el agua en una sartén? ¿O también está atado al mercado?
Buena suerte
¿Sabe opencl trabajar con dlls personalizados?
Es decir, ¿llamar asíncronamente a funciones exportadas desde la dll?
Había una clase interna para trabajar con las tareas, podías llamar a tus funciones desde la dll de forma asíncrona también.
Es decir, la funcionalidad regular es mucho más utilizable, y más accesible a la hora de escribir código.
Llama a la función DLL. Creas un hilo en la DLL y le transfieres datos, desconectas el hilo y te olvidas de él: completa su tarea por sí mismo. Cuando se desconecta el hilo en la DLL, se libera el hilo del terminal. Todo el proceso dura, creo, menos de un milisegundo. A juzgar por el hecho de que incluso sin desconectar el hilo, el proceso de escritura en la base de datos es de 4-5 ms. Bueno, y 60 ticks/min es suficiente para no estar triste por la llamada asíncrona desde el terminal.
Lástima que no hayamos escuchado al jefe del departamento de transporte: ¿qué tarea específica quiere implementar el multihilo? Dibuja un diagrama de bloques sencillo de la solución propuesta.
Te obstinas en meter una tarea de MKL para la que no estaba pensada originalmente. En una palabra, en absoluto. Hay soluciones ya hechas - mira ZeroMQ que tiene API para casi todos los JDs. Además, el amable Ding Li desarrolló una biblioteca para ZeroMQ usando con MQL4/5 con un conjunto de ejemplos. Por favor, lea el hilo del foro sobre este tema con ejemplos prácticos de código.
¿Por qué estás (el iniciador del tema) empujando el agua en una sartén? ¿O también está atado al mercado?
Buena suerte
Intento no utilizar soluciones de terceros.
Ya he encontrado una solución para mi problema de red; sólo me queda estudiarla, aplicarla y no joderme el cerebro.
Pero aquí hay programadores que también necesitan llamadas no bloqueantes y asincronía.
Por eso sugerí implementar esta funcionalidad en la entrega de idiomas estándar. Y depende de los desarrolladores, lo principal es la idea, y es sensata.
¿Por qué crees que el terminal no está diseñado para implementar EventLoop? Especialmente desde el principio...
¿Qué algoritmo se utiliza para ejecutar los agentes locales? Probablemente en una piscina de hilos, ¿verdad? ¿Quién los gestiona y distribuye las tareas?
Así pues, el terminal ya dispone de un algoritmo de este tipo, ¿por qué no utilizarlo para ampliar su funcionalidad?
Dar a los programadores un modo asíncrono de escritura de código.
Estoy a favor de la idea, si nadie lo necesita de forma asíncrona, pues qué quieres que te diga, sólo lamento que muchos se queden en un solo hilo.
Llama a la función DLL. Creas un hilo en la DLL y le transfieres datos, desconectas el hilo y te olvidas de él - terminará por sí solo después de completar su tarea. Cuando se desconecta el hilo en la DLL, se libera el hilo del terminal. Todo el proceso dura, creo, menos de un milisegundo. A juzgar por el hecho de que incluso sin desconectar el hilo, el proceso de escritura en la base de datos es de 4-5 ms. Bueno, 60 ticks/s es suficiente para no estar triste por la llamada asíncrona desde el terminal.
Aquí, gracias por otra idea, puedo escribir dll según los artículos locales, pero desafortunadamente no describen el procedimiento de punto de entrada, inicialización,asignación de memoria, creación de hilos, etc.
No encuentro ninguna literatura sobre este tema, no encuentro cómo manejar el punto de entrada correctamente. Si hay alguna información sobre este tema, por favor hágamelo saber.
O si puedes enseñarme, estaré encantado de aceptar el conocimiento.
No he estudiado como programador, todo lo aprendo yo mismo, por lo tanto, no me patees el culo ))
Explícame qué tiene de malo opencl. El terminal implementa la capacidad de escribir código opencl, y éste es multihilo. Quiero entender por mí mismo cuáles son las diferencias de multithreading que está escrito aquí y esta característica.