MT5 y la velocidad en acción - página 75

Nuevo comentario
 
Valeriy Yastremskiy:

No soy un experto en gráficos. La importancia viene determinada por la dependencia del inicio de otras tareas respecto al final de la actual. otros criterios son secundarios. pero también está el tiempo de ejecución de la tarea. y también es el más importante entre los compañeros. En general es difícil y lo más triste es que el algoritmo de priorización no puede cambiarse sobre la marcha. Por el lado bueno, me gustaría que los desarrolladores me aclararan algo antes de que surjan dudas. Es complicado, pero es el objetivo correcto en el desarrollo del medio ambiente.

Extracto de una descripción de cómo funciona esto en los sistemas en tiempo real.

Normalmente las prioridades son dinámicas, lo que significa que pueden ser cambiadas en tiempo de ejecución por los propios procesos así como por el SO.
La respuesta a las interrupciones está separada de los cálculos intensivos de la CPU.
En cuanto se produce un evento o una interrupción, su manejador se incluye inmediatamente en la cola de procesos listos.
Los programas manejadores de interrupciones suelen ser compactos porque deben proporcionar una respuesta rápida,
por ejemplo, la entrada de nuevos datos, y transferir el control a procesos más complejos que consumen mucha CPU y que se ejecutan con una prioridad menor.

 
Roman:

Hola Nikolai. Es cierto.
Pero, ¿no habrá el mismo problema que con la sincronización, del que habla Slava, es decir, frenos desmedidos.
¿O tal vez no hay ningún problema? )) ¿Tal vez sea más fácil no utilizar el modelo asíncrono que sincronizarlo con las prioridades? ))

Hola.
No soy un experto en asincronía e interrupciones, aunque tengo algunos conocimientos y experiencia.
No debería haber ningún problema con el tema del temporizador. Como la secuencia no es importante, lo que importa es la periodicidad. Además, según tengo entendido, el temporizador se basa en las interrupciones de hardware del sistema.
Creo que todo el sistema de control de la asincronía se implementa utilizando interrupciones de hardware, incluyendo las del temporizador.
Todavía me pregunto cuán intensivas en recursos son las interrupciones.
Por ejemplo, una interrupción del sistema viene del temporizador de la CPU para realizar un incremento de una variable global. Este incremento en sí mismo llevará al sistema alrededor de 1 nanosegundo. Pero:

  • ¿Cuánto tiempo se tarda en guardar todos los parámetros de los procesos y/o hilos en ejecución necesarios para reanudar el trabajo?
  • ¿Este ahorro se realiza por hardware o por software?
  • ¿Cuánto tiempo se tarda en restaurar el proceso?
  • ¿Podemos medir esta intensidad de recursos? Probablemente no, porque ¿cómo captar el momento de la interrupción?
  • ¿Cuál es el orden de estos costes de recursos: decenas, cientos de nanosegundos, microsegundos o decenas y cientos de microsegundos? Sería interesante obtener esa información.

En general, me doy cuenta de que me faltan conocimientos y experiencia. Por eso intento no preguntar a los desarrolladores sobre las prioridades de la asincronía. Entiendo que hay muchos matices, escollos y obstáculos cuando se trata de crear un sistema perfecto, especialmente cuando se trata de órdenes comerciales y de obtener información comercial.
Aunque tengo que admitir que todavía no entiendo por qué hicieron algunas funciones asíncronas en el 5, lo que es un gran inconveniente. Me refiero a ChartGet..., ChartTimePriceToXY, ChartXYToTimePrice.
Después de todo, es lógico suponer que el llenado de la tabla de estado del gráfico debe ser asíncrono, y los comandos sólo deben leer datos de esta tabla. Y si los datos en el momento de la lectura están desfasados unos milisegundos, no hay problema.
El problema es que, en la búsqueda de la relevancia imaginaria de los datos, se producen desfases de decenas de milisegundos, durante los cuales la relevancia extraída se vuelve irrelevante en mayor medida, si inicialmente estos comandos no fueran asíncronos, sino que simplemente leyeran los últimos datos conocidos de la tabla de estado del gráfico.
Y a juzgar por el tiempo de ejecución, estas funciones no eran asíncronas en 4.

 
Roman:

Extracto de una descripción de cómo funciona esto en los sistemas en tiempo real.

Normalmente las prioridades son dinámicas, lo que significa que en tiempo de ejecución pueden ser cambiadas por los propios procesos así como por el SO.
La respuesta a las interrupciones está separada de los cálculos intensivos de la CPU.
En cuanto se produce un evento o una interrupción, su manejador se incluye inmediatamente en la cola de procesos listos.
Los programas gestores de interrupciones suelen ser compactos porque necesitan dar una respuesta rápida,
por ejemplo, introducir nuevos datos, y pasar el control a procesos más complejos que requieren un uso intensivo del procesador y que se ejecutan con una prioridad menor.

Es tal como lo describí)))) Por supuesto, la lógica de la prioridad es dinámica. Y esta es la dificultad de establecer el nivel. al establecer el nivel de prioridad no podemos determinar su tiempo de ejecución en la lógica de priorización dinámica en el entorno de abajo. el terminal está siempre por encima del entorno wine o linux y no puede afectar a la lógica de priorización del entorno de abajo.

 
Nikolai Semko:


No se supone que todas las preguntas planteadas tengan respuesta.

La intensidad de recursos de la propia interrupción.
Lo más probable es que dependa de la frecuencia del procesador.

El tiempo que tarda el proceso en guardarse, para su posterior reanudación.
Según los algoritmos basados en la cuantificación, el proceso activo se cambia si:

  • el proceso ha terminado y ha abandonado el sistema
  • se ha producido un error
  • el proceso ha pasado al estado de ESPERA
  • proceso ha agotado una cantidad de tiempo del procesador, y

Cómo captar las interrupciones.
Unpredivisor es un divisor de frecuencia de reloj que actúa como uno o varios activadores T conectados en serie.

 
Roman:

No se supone que todas las preguntas planteadas tengan respuesta.

Vete a estudiar el tema (por lo menos 10 años) y no ensucies este hilo, por favor.

Las preguntas se discuten aquí con una formación diferente y una clase diferente.

 
Nikolai Semko:
  • ¿Cuánto tiempo se tarda en guardar todos los parámetros de los procesos y/o hilos en ejecución necesarios para reanudar el funcionamiento?
  • ¿Este ahorro se realiza por hardware o por software?

¿No pasa nada desde el procesador 286? No lo recuerdo y nunca lo entendí, pero desde el Pentium-1 (leí un libro sobre ello, hace mucho tiempo)

El procesador funciona en modo protegido. Cada procesador tiene asignada una memoria virtual; las direcciones físicas de los bancos de memoria (celdas de RAM) son traducidas a direcciones virtuales (¿o más bien viceversa?) por el propio procesador (no lo recuerdo, pero parece que se trata de un registro especial y un puntero virtual a la tabla de traducción de direcciones). Es el hardware lo que ocurre, no es medible, es el llamado núcleo del procesador que distingue a cada línea de procesadores Intel, ¡no es la caché!

Nikolai Semko:
  • ¿Cuánto tiempo se tarda en recuperar el proceso?

cualquier programa en Win debe registrarse como un proceso y crear al menos un hilo

entonces el programador de tareas de Win asignará recursos al proceso y le pondrá en cola los mensajes, cómo funciona el programador no me interesa, basta con que se pueda subir la prioridad del proceso y se vea que con un poco de esfuerzo el PC empieza a planificar, es decir, Microsoft le da recursos a mi aplicación, esto es suficiente para que el SO siga funcionando

Nikolai Semko:
  • ¿Es posible medir esta intensidad de recursos? Probablemente no, porque ¿cómo captar el momento de la interrupción?
  • ¿Cuál es el orden de estos costes de recursos: decenas, cientos de nanosegundos, microsegundos o decenas y cientos de microsegundos? Sería interesante obtener esa información.

Ehz, ¿medir qué? Las interrupciones son hardware, las maneja el SO, por supuesto con la ayuda de drivers.

¿temporizador? - si no me equivoco, el temporizador no puede llegar a la cola de mensajes a menos que el proceso lo esté procesando, algo sobre el sistema operativo a prueba de tontos, google WM_TIMER - debe ser detallado

¿el orden de los números? sólo se puede medir el reloj del procesador y luego multiplicarlo por el factor de cálculo del procesador, se discutióen https://www.mql5.com/ru/forum/352454#comment_18588098 , google toneladas de información sobre la medición del rendimiento

 
Renat Fatkhullin:

Vete a estudiar el tema (por lo menos 10 años) y no ensucies en este hilo, por favor.

Aquí se discuten temas con una formación y una clase diferentes.

Todos deberían ser enviados aquí, no de forma selectiva )) Pero, como siempre, se le da una patada en el sombrero a quien hace preguntas adecuadas.
Después de saber que los manejadores se ejecutan en modo de bloqueo, no he sacado este tema por nada.
He tocado el verdadero quid del problema, y no te gusta. Bien, dejaré el tema.
Pero no veo el sentido de lograr eventos puntuales en el procesamiento sincrónico.
Slava, Nikolay, Valery gracias por el diálogo constructivo.

 
Igor Makanu:

no pasa nada desde el procesador 286? hmm, no lo recuerdo y nunca me he ocupado de ello, pero definitivamente desde el Pentium-1 (leí un libro sobre ello, hace mucho tiempo sin embargo)
Es hardware todo hecho, no es medible, es el llamado núcleo del procesador que distingue a cada línea de procesadores Intel, ¡no es la caché!

Bien si lo es.
Creo que lo es. Casi todo es a nivel de hardware. De lo contrario, el multithreading no sería tan eficiente.

 
Nikolai Semko:

Bien si ese es el caso.
Creo que lo es. Casi todo es a nivel de hardware. De lo contrario, el multithreading no sería tan eficaz.

sólo así

google: modo protegido del procesador

Si no me equivoco, el modo protegido le da al kernel del SO un nivel de privilegio separado y debido a la memoria virtual para cada proceso - es imposible obtener los datos de la RAM para el programa que se está ejecutando... bueno, a menos que lo ejecute bajo el depurador como un proceso separado.... esa es otra área de experiencia ))))

pero, inequívocamente, todo funciona a nivel de hardware, es imposible medirlo, sólo las herramientas del SO - y el cambio de memoria virtual para los procesos es instantáneo, y el propio procesador funciona a nivel de frecuencia interna - multiplicador de la CPU... y si te pones a pensar en el caché... ¿Por qué? - hay un problema, ¡busca una solución! ¿quieres escribir un controlador? )))

SZZ: puedes escribir un driver, recuerdo cuando usaba TCP-logger, se instalaba como un driver y registraba todo el tráfico y luego por procesos en la tabla mostraba todo el tráfico.... sólo hay que pensar en cómo la escritura de controladores ayudará a desarrollar TCP rentable ))))



UPD: Hubr "What is Protected Mode and what does it do"https://habr.com/ru/post/118881/

UPD: Privilegio a nivel de hardware (CPU) para la ejecución de código - Wiki deAnillos Protegidos

 
Renat Fatkhullin:

Siempre está garantizado que habrá fallos en muestras individuales aleatorias de cualquier instrucción, incluyendo la más simple de tipo ensamblador inc eax. Esto se debe a la arquitectura y a las limitaciones físicas de "asignar honestamente el tiempo de miles de hilos a un pequeño número de núcleos".

Dejen de ser estúpidos y sigan atrapando a los que están fuera de lugar por cada millón de solicitudes.

He notado que CopyTicks se retrasa raramente. He escrito un script de prueba

#include <fxsaber\Benchmark\Benchmark.mqh> // https://www.mql5.com/ru/code/31279

void OnTick()
{
  Sleep(1000);
  
  MqlTick Tick[1];
  
  _B(CopyTicks(_Symbol, Tick, COPY_TICKS_ALL, 0, 1), 100);
  _B(SymbolInfoTick(_Symbol, Tick[0]), 100);
}

y lo ejecuté en modo de estrés. SymbolInfoTick tiene notablemente más alertas que CopyTicks.


No hay quejas. Sólo me gustaría entender, ¿qué afecta a la diferente percepción de la carga de estrés en las implementaciones de estas funciones?

1...686970717273747576777879808182...94
Nuevo comentario