Mi enfoque. El núcleo es el motor. - página 123
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
...
ZS. Es posible, sin embargo, que el procesador se esté sobrecargando al redibujar. Es decir, dibujar dentro de una matriz de píxeles. En otras palabras, la inicialización constante de la matriz con valores, que se produce a alta (16ms) frecuencia del temporizador.
No, el redibujado no carga el procesador de ninguna manera; tarda unos nano o, como mucho, microsegundos en enviar una orden al controlador de gráficos. El procesador de la tarjeta de vídeo realiza el pintado por sí mismo, píxel a píxel, mientras que suele haber cientos de ellos y trabajan simultáneamente con el procesador en paralelo. Es decir, el procesador emite la orden al controlador gráfico: mostrar un círculo con el centro en las coordenadas de pantalla Xc, Yc y radio R en modo CopyPut. Para el procesador esto es sólo una llamada a una función con parámetros pasados. No va más allá de esto. Tales llamadas que hace no más a menudo que, por ejemplo, 2 veces por segundo, de lo contrario el usuario simplemente no puede entender nada en la pantalla, no se puede tirar tan a menudo. Para una lista de operaciones abiertas, puede imaginarse que puede tardar una hora o un día o más.
Y el algoritmo (busca en Google "Algoritmo Bresenham", por ejemplo) de coloreado píxel a píxel lo ejecuta la tarjeta gráfica, y el procesador no se entretiene en ello. También se ejecuta muy rápidamente. Y... una vez por llamada. No es necesaria la reinicialización a los 16ms, la imagen de la pantalla se almacena permanentemente en la memoria de vídeo hasta un nuevo cambio a la orden del procesador. No sólo eso, la memoria de vídeo también se mantiene por duplicado para acelerar la respuesta de la pantalla visible, los cambios se realizan en la invisible, y luego se cambia la página de vídeo inmediatamente.
Si su enfoque de la salida de la pantalla todavía tiene la " inicialización constante de la matriz" de píxeles que usted describe - usted debe deshacerse de él, no es el caso.
Haga clic para ver.
Hay un problema con los datos de la columna de la hora de apertura en la imagen.
No, el redibujado no carga el procesador de ninguna manera; tarda como mucho unos nano o microsegundos en enviar una orden al controlador de gráficos. Los procesadores de la tarjeta de vídeo realizan el pintado propiamente dicho, píxel a píxel, y suelen ser cientos y trabajan simultáneamente con el procesador, en paralelo. Es decir, el procesador emite la orden al controlador gráfico: mostrar un círculo con el centro en las coordenadas de pantalla Xc, Yc y radio R en modo CopyPut. Para el procesador esto es sólo una llamada a una función con parámetros pasados. No va más allá de esto. Tales llamadas que hace no más a menudo que, por ejemplo, 2 veces por segundo, de lo contrario el usuario simplemente no puede entender nada en la pantalla, no se puede tirar tan a menudo. Para una lista de operaciones abiertas, puede imaginarse que puede tardar una hora o un día o más.
Y el algoritmo (busca en Google "Algoritmo Bresenham", por ejemplo) de coloreado píxel a píxel lo ejecuta la tarjeta gráfica, y el procesador no se entretiene en ello. También se ejecuta muy rápidamente. Y... una vez por llamada. No es necesario reiniciar a los 16ms, la imagen de la pantalla se mantiene constante en la memoria de vídeo hasta que se realiza un nuevo cambio a la orden del procesador. No sólo eso, para acelerar la respuesta de la pantalla visible, la memoria de vídeo también se mantiene en dos instancias, los cambios se hacen en la invisible, después de lo cual la página de vídeo se cambia inmediatamente.
Si su enfoque de la salida de la pantalla todavía tiene la " inicialización permanente de la matriz" de píxeles que usted describe - usted debe deshacerse de él, no es el caso.
Qué lío...
Es una mezcla de conocimientos fragmentarios...
Al final, no es así como funciona.
No, el redibujado no carga el procesador de ninguna manera; tarda como mucho unos nano o microsegundos en enviar una orden al controlador de gráficos. Los procesadores de la tarjeta de vídeo realizan el pintado propiamente dicho, píxel a píxel, y suelen ser cientos y trabajan simultáneamente con el procesador, en paralelo. Es decir, el procesador emite la orden al controlador gráfico: mostrar un círculo con el centro en las coordenadas de pantalla Xc, Yc y radio R en modo CopyPut. Para el procesador esto es sólo una llamada a una función con parámetros pasados. No va más allá de esto. Tales llamadas que hace no más a menudo que, por ejemplo, 2 veces por segundo, de lo contrario el usuario simplemente no puede entender nada en la pantalla, no se puede tirar tan a menudo. Para una lista de operaciones abiertas, puede imaginarse que puede tardar una hora o un día o más.
Y el algoritmo (busca en Google "Algoritmo Bresenham", por ejemplo) de coloreado píxel a píxel lo ejecuta la tarjeta gráfica, y el procesador no se entretiene en ello. También se ejecuta muy rápidamente. Y... una vez por llamada. No es necesario reiniciar a los 16ms, la imagen de la pantalla se mantiene constante en la memoria de vídeo hasta que se realiza un nuevo cambio a la orden del procesador. Y no sólo eso, para acelerar la respuesta de la pantalla visible, la memoria de vídeo también se mantiene por duplicado, los cambios se realizan en la invisible y luego se cambia inmediatamente a la página de vídeo.
Si su enfoque de la salida todavía tiene la " inicialización constante de la matriz" de píxeles - usted necesita para deshacerse de él.
Tienes una teoría interesante, aunque no encaja del todo con los resultados de mis experimentos, que publicaré a continuación.
Como muestra la prueba, es la inicialización de la matriz de píxeles lo que más carga la CPU.
Comprueba la prueba EA que aparece a continuación.
Tengo que admitir que me sorprendieron un poco los resultados de la prueba.
Por lo tanto, estamos hablando de llamadas constantes a funciones con una frecuencia de 16 ms.
Resulta que es la inicialización de la matriz de píxeles durante el dibujo lo que más carga al procesador.
Pero lo más extraño fue que la repetida llamada a la función
cargaría el procesador entre un 10 y un 15%.
Además, las llamadas
cargar el procesador en el mismo 10-15%.
Al mismo tiempo, las llamadas simultáneas de las tres funciones
No provoca el apilamiento de la carga. La carga sigue siendo del 10-15%.
Sin embargo, si a estas llamadas se les añade un bucle constante de reinicialización de arrays de un millón de celdas
entonces la carga de la CPU sube al 50%.
//-----------------------------------------------------------------------------------------------------------------------------------------------------
La función en sí misma
no carga el procesador.
La función
cargará de 0 a 5% dependiendo del tamaño de la matriz Arr[].
Aquí hay un asesor de prueba. Tienes que comentar las líneas y comprobar la carga de la CPU en el administrador de tareas.
Aquí está su código:
Hay un problema con los datos de la columna de la hora de apertura en la imagen.
Sí, he utilizado TimeToStr(OrderOpenPrice(),TIME_MINUTES|TIME_SECONDS);
No sé por qué es así.
Tengo que admitir que me sorprendieron un poco los resultados de la prueba.
Por lo tanto, estamos hablando de llamadas constantes a funciones con una frecuencia de 16 ms.
Resulta que es la inicialización de la matriz de píxeles durante el dibujo lo que más carga al procesador.
Pero lo más extraño fue que la repetida llamada a la función
cargaría el procesador entre un 10 y un 15%.
Además, las llamadas
cargar el procesador en el mismo 10-15%.
Al mismo tiempo, las llamadas simultáneas de las tres funciones
No provoca el apilamiento de la carga. La carga sigue siendo del 10-15%.
Sin embargo, si a estas llamadas se les añade un bucle constante de reinicialización de arrays de un millón de celdas
entonces la carga de la CPU sube al 50%.
//-----------------------------------------------------------------------------------------------------------------------------------------------------
La función en sí misma
no carga el procesador.
La función
carga de 0 a 5%, dependiendo del tamaño de la matriz Arr[].
Debo admitir que me sorprendieron un poco los resultados de la prueba.
Por lo tanto, estamos hablando de llamadas de función constantes a 16 mseg.
Resulta que es la inicialización de una matriz de píxeles durante el dibujo lo que más carga al procesador.
Pero lo más extraño fue que la repetida llamada a la función
cargaría el procesador entre un 10 y un 15%.
Además, las llamadas
cargar el procesador en el mismo 10-15%.
Al mismo tiempo, las llamadas simultáneas de las tres funciones
No provoca el apilamiento de la carga. La carga sigue siendo del 10-15%.
Sin embargo, si a estas llamadas se les añade un bucle constante de reinicialización de arrays de un millón de celdas
entonces la carga de la CPU sube al 50%.
//-----------------------------------------------------------------------------------------------------------------------------------------------------
La función en sí misma
no carga el procesador.
La función
cargará de 0 a 5% dependiendo del tamaño de la matriz Arr[].
Peter, hay una sensación persistente de que no escuchas nada de lo que te han dicho durante cientos de páginas.
Vuelve a leer el hilo: hay respuestas a la pregunta "¿por qué?"
Sí, he utilizado TimeToStr(OrderOpenPrice(),TIME_MINUTES|TIME_SECONDS);
No sé por qué.
Porque en lugar de OrderOpenPrice poner OrderOpenTime()