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
¿Ayudaría de alguna manera un núcleo en tiempo real?
Poner más núcleos y no llevar la situación al 100% de carga de un solo núcleo.
No creas en cuentos de hadas, los procesadores y el programador de hilos no funcionan como te imaginas.
En las últimas versiones, la recepción del flujo de garrapatas no tiene ningún efecto, ni siquiera en teoría. Prácticamente SymbolInfoTick ya funciona con caché, pero los ciudadanos individuales siguen buscando un gato negro.
Y ni siquiera es el 80% en la prueba. Tiene 6 agentes funcionando en 4 núcleos, es decir, 100% garantizado.
La única cuestión es cómo maneja la situación el programador de tareas de su sistema. Al mismo tiempo, los autores afirman que la culpa es de la aplicación del terminal.
Es decir, se crea artificialmente una situación en la que un ordenador se sobrecarga, en la que literalmente todo en él se ralentiza, y entonces se hacen algunas reclamaciones en forma de "Oh, mira, por qué el terminal se retrasa a veces".
Cerremos los ojos al hecho de que incluso en tales condiciones es "alrededor del 0,01%" - ¡al diablo con los detalles! Basta con decir que "a nadie le importa la temperatura media del hospital", "los desfases causan problemas al operar" y "queremos HFT".
Además, por supuesto que queremos HFT en 20 expertos en un viejo escritorio de oficina o una máquina virtual muerta.
PS PositionSelectByTicket() en su implementación ciertamente tiene acceso a un recurso compartido con sincronización de acceso. Y si no seleccionas la posición en cada llamada, estás leyendo el precio antiguo. Era más fácil hacer una "instantánea" a través de SymbolInfoDouble.
gracias
Mi pregunta se debe a que hace seis meses, estaba optimizando mi código y probando la velocidad de las funciones del sistema, y hace seis meses, SymbolInfoDouble era más lento que SymbolInfoTick
Tal vez sea cierto lo que dices. Hoy he estado buscando en Google algunos artículos sobre la caché multinúcleo (hace tiempo que no me interesaba por esta información),
aquí hay un breve artículohttps://i2hard.ru/publications/25666/
la cuestión es que los datos llegan a la ALU sólo desde la caché L1 que es muy pequeña y si se carga el procesador a toda velocidad, entonces realmente - la prueba se convertirá en una prueba del sistema operativo + prueba de la velocidad de la caché del procesador (carga, predicción de datos L1+L3) pero no en la prueba del rendimiento del código (aplicación)
fxsaber, ¿que tal si pones una prioridad baja para los agentes en el administrador de tareas y una alta para MT5?
No puedo encontrar una utilidad que bloquee todos los programas/hilos del SO para que no sean asignados a un hilo específico de la CPU, de lo contrario sería posible reservar un hilo para MT5 y bloquearlo automáticamente para que no sea utilizado por otros programas, lo que en teoría podría reducir los lags.
En las últimas versiones, la recepción del flujo de garrapatas no tiene ningún efecto, ni siquiera en teoría. Prácticamente, SymbolInfoTick ya funciona con caché, pero ciertos ciudadanos siguen buscando un gato negro.
Un ciudadano particular ha conseguidoduplicar el código MQL de sus pantalones anchos que demostró que la muleta funciona más rápido que la función regular en las mismas condiciones.
Pero usted sostiene que su función es buena, sólo que tiene limitaciones en las condiciones de uso.
Y ni siquiera es el 80% en la prueba. Hay 6 agentes funcionando en 4 núcleos, es decir, 100% garantizado.
La única cuestión es cómo maneja la situación el programador de tareas de su sistema. Al mismo tiempo, se está afirmando que la culpa es de la implementación del terminal.
Es decir, se crea artificialmente una situación en la que un ordenador se sobrecarga hasta sus límites y todo se ralentiza en él, y entonces se hacen algunas reclamaciones en forma de "Oh, mira, por qué el terminal se retrasa a veces".
6/8 - nada se retrasa. Los navegadores, la compilación, la depuración, etc. se ejecutan en paralelo sin ningún tipo de retraso.
Pero ahora he apagado todo a propósito, dejando sólo 4/8 de agente. La situación no ha cambiado con su función de frenado.
Esmás, por supuesto, queremos HFT en 20 expertos en un viejo escritorio de oficina o una máquina virtual muerta.
Se utilizó una máquina rápida. Y sólo 6 gráficos ya estaban dando los frenos.
PS PositionSelectByTicket() en su implementación ciertamente tiene acceso a un recurso compartido con sincronización de acceso. Y si no se selecciona la posición en cada llamada, se lee el precio antiguo. Era más fácil hacer un "snapshot" a través de SymbolInfoDouble.
Yo también uso esto.
De qué tipo de velocidad en el rendimiento del combate podemos hablar cuando hay problemas en el terminal.
El Asesor Experto escanea todos los instrumentos financieros y busca un patrón determinado.
Se tropieza con un símbolo y ¡¡¡se agarra fuerte!!!
Código de la ayuda, pongo sólo pasos, instrumento financiero con problema y temporizador:
Resultado del trabajo:
Nunca esperé a que el guión terminara de ejecutarse.
Mientras el terminal tenga esos fallos, ¡¡¡no hay ejecución de batalla que valga!!!
Se esperaba que cuando un valor entrara en la revisión del mercado, se sacaran al menos todas sus propiedades y la fecha de inicio del historial. Si no hay historial en el servidor, entonces
SeriesInfoInteger(symbol,period,SERIES_FIRSTDATE,first_date)
Debería devolver NULL al instante, ¿por qué el tiempo de ejecución 18446744073475877138 ?
¡¡¡Tal vez no sé algo, la función CopyXXX también se cuelga durante 16-29 segundos!!!
No es normal que un corredor tenga entre 3000 y 6000 instrumentos financieros.
¡¡¡Igual no sé qué, las funciones de CopyXXX también se cuelgan entre 16 y 29 segundos!!!
No es normal que un corredor tenga entre 3000 y 6000 instrumentos financieros.
Los bares son malos. Así que, por favor, publica sobre ellos en otro hilo.
Los bares son malos. Así que, por favor, publica sobre ellos en otro hilo.
¿Quizá sepa cómo seleccionar programáticamente un instrumento financiero y no quedarse colgado durante mucho tiempo?
¿Quizá sepa cómo seleccionar programáticamente un instrumento financiero y no quedarse colgado durante mucho tiempo?
No me he encontrado con una tarea así.
fxsaber, ¿que tal si pones una prioridad baja para los agentes en el administrador de tareas y una alta para MT5?
No encuentro una utilidad que bloquee la asignación de un hilo específico de la CPU a todos los programas/hilos del SO, de lo contrario sería posible reservar un hilo para MT5 y bloquear automáticamente su ocupación por otros programas, lo que en teoría podría reducir los lags.
Poner todos los Agentes en la prioridad más baja.
No funciona.
ZZZ El número de EAs en funcionamiento afecta al resultado.
Estimados desarrolladores, ¿podrían informarme de cómo se calcula MQL_MEMORY_USED?
Hice un cálculo de la memoria que ocupan todas las variables de EA.
Es menos del 10%. Si he entendido bien, MQL_MEMORY_USED incluye la caché del historial y la caché de CopyTicks. Pero sigue siendo mucho menos.
Al mismo tiempo, el Asesor Experto paralelo consume varias veces menos. Pero el principio es el mismo.
En general, ¿qué se incluye a este valor?
He guardado una plantilla con Expert Advisor y la he aplicado al mismo gráfico provocando la recarga. Lo he visto así.
El uso de la memoria ha cambiado en casi un orden de magnitud. Es difícil explicar lo que esto significa en este momento.