Mon approche. Le noyau est le moteur.

Vladimir 2019.01.05 00:14 #1221

Реter Konow:

...

ZS. Il est possible, cependant, que le processeur soit surchargé par le redécoupage. C'est-à-dire, dessiner à l'intérieur d'un tableau de pixels. En d'autres termes, l'initialisation constante du tableau avec des valeurs, se produisant à la fréquence élevée (16ms) du timer.

Non, le redécoupage ne charge pas le processeur de quelque manière que ce soit ; il lui faut quelques nano- ou tout au plus quelques microsecondes pour envoyer une commande au pilote graphique. Le processeur de la carte vidéo effectue lui-même la peinture, pixel par pixel, alors qu'il y en a généralement des centaines et qu'ils travaillent simultanément avec le processeur en parallèle. Autrement dit, le processeur envoie la commande suivante au pilote graphique : afficher un cercle dont le centre est situé aux coordonnées Xc, Yc de l'écran et dont le rayon est R en mode CopyPut. Pour le processeur, il s'agit simplement d'un appel de fonction avec des paramètres passés. Il ne va pas plus loin que cela. De tels appels ne sont pas effectués plus souvent que, par exemple, 2 fois par seconde, sinon l'utilisateur ne peut tout simplement rien comprendre à l'écran, il ne peut pas être tiré aussi souvent. Pour une liste de transactions ouvertes, vous pouvez imaginer que cela peut prendre une heure, un jour ou plus.

Et l'algorithme (googlez "Algorithme de Bresenham", par exemple) de coloration pixel par pixel est exécuté par la carte graphique, et le processeur ne s'y attarde pas. Il s'exécute également très rapidement. Et... une fois par appel. Aucune réinitialisation à 16 ms n'est nécessaire, l'image de l'écran est maintenue constante dans la mémoire vidéo jusqu'à ce qu'un nouveau changement soit effectué sur commande du processeur. En outre, pour accélérer la réponse de l'écran visible, la mémoire vidéo est également conservée dans deux instances, les modifications sont effectuées sur l'instance invisible, puis la page vidéo est immédiatement basculée.

Si votre approche de la sortie écran comporte toujours "l'initialisation constante du tableau" de pixels que vous décrivez - vous devriez vous en débarrasser, ce n'est pas le cas.

Réaliser un projet de L'apprentissage automatique dans la Erreurs, bugs, questions

Andrey Barinov 2019.01.05 03:23 #1222

Реter Konow:

Cliquez pour voir.

Il y a un problème avec les données de la colonne Heure d'ouverture dans l'image.

Nikolai Semko 2019.01.05 04:54 #1223

Vladimir:

Non, le redécoupage ne charge pas le processeur de quelque manière que ce soit ; il lui faut tout au plus quelques nano- ou microsecondes pour envoyer une commande au pilote graphique. Les processeurs de la carte vidéo réalisent la peinture elle-même, pixel par pixel, alors qu'il y en a généralement des centaines et qu'ils travaillent simultanément avec le processeur, en parallèle. En d'autres termes, le processeur envoie la commande suivante au pilote graphique : afficher un cercle dont le centre est situé dans l'écran aux coordonnées Xc, Yc et de rayon R en mode CopyPut. Pour le processeur, il s'agit simplement d'un appel de fonction avec des paramètres passés. Il ne va pas plus loin que cela. De tels appels ne sont pas effectués plus souvent que, par exemple, 2 fois par seconde, sinon l'utilisateur ne peut tout simplement rien comprendre à l'écran, il ne peut pas être tiré aussi souvent. Pour une liste de transactions ouvertes, vous pouvez imaginer que cela peut prendre une heure, un jour ou plus.

Et l'algorithme (googlez "Algorithme de Bresenham", par exemple) de coloration pixel par pixel est exécuté par la carte graphique, et le processeur ne s'y attarde pas. Il s'exécute également très rapidement. Et... une fois par appel. Aucune réinitialisation à 16 ms n'est nécessaire, l'image de l'écran reste constante dans la mémoire vidéo jusqu'à ce qu'un nouveau changement soit effectué sur commande du processeur. De plus, pour accélérer la réponse de l'écran visible, la mémoire vidéo est également conservée dans deux instances, les modifications sont effectuées sur l'instance invisible et la page vidéo est alors immédiatement basculée.

Si votre approche de la sortie écran comporte toujours "l'initialisation permanente des tableaux" de pixels que vous décrivez - vous devriez vous en débarrasser, ce n'est pas le cas.

Quel gâchis...
C'est un méli-mélo de connaissances fragmentaires...

En fin de compte, ce n'est pas comme ça que ça marche.

Реter Konow 2019.01.05 10:07 #1224

Vladimir:

Non, le redécoupage ne charge pas le processeur de quelque manière que ce soit ; il lui faut tout au plus quelques nano- ou microsecondes pour envoyer une commande au pilote graphique. Les processeurs de la carte vidéo réalisent la peinture elle-même, pixel par pixel, alors qu'il y en a généralement des centaines et qu'ils travaillent simultanément avec le processeur, en parallèle. En d'autres termes, le processeur envoie la commande suivante au pilote graphique : afficher un cercle dont le centre est situé dans l'écran aux coordonnées Xc, Yc et de rayon R en mode CopyPut. Pour le processeur, il s'agit simplement d'un appel de fonction avec des paramètres passés. Il ne va pas plus loin que cela. De tels appels ne sont pas effectués plus souvent que, par exemple, 2 fois par seconde, sinon l'utilisateur ne peut tout simplement rien comprendre à l'écran, il ne peut pas être tiré aussi souvent. Pour une liste de transactions ouvertes, vous pouvez imaginer que cela peut prendre une heure, un jour ou plus.

Et l'algorithme (googlez "Algorithme de Bresenham", par exemple) de coloration pixel par pixel est exécuté par la carte graphique, et le processeur ne s'y attarde pas. Il s'exécute également très rapidement. Et... une fois par appel. Aucune réinitialisation à 16 ms n'est nécessaire, l'image de l'écran reste constante dans la mémoire vidéo jusqu'à ce qu'un nouveau changement soit effectué sur commande du processeur. En outre, pour accélérer la réponse de l'écran visible, la mémoire vidéo est également conservée dans deux instances, les modifications sont effectuées sur l'instance invisible, puis la page vidéo est immédiatement basculée.

Si votre approche de la sortie comporte toujours "l'initialisation constante du tableau" de pixels - vous devez vous en débarrasser.

Votre théorie est intéressante, bien qu'elle ne corresponde pas tout à fait aux résultats de mes expériences, que je vais maintenant poster ci-dessous.

Comme le montre le test, c'est l'initialisation de la matrice de pixels qui sollicite le plus le CPU.

Vérifiez le test EA ci-dessous.

[Toute question de débutant, [Archive] Toute question de FOREX - Tendances, prévisions

Реter Konow 2019.01.05 10:16 #1225

Je dois admettre que j'ai été un peu surpris par les résultats du test.

Nous parlons donc d'appels de fonction constants à une fréquence de 16 ms.

Il s'avère que c'est l'initialisation de la matrice de pixels pendant le dessin qui charge le plus le processeur.

Mais la chose la plus étrange était que l'appel répété de la fonction

ObjectSetInteger(0,"MT object",OBJPROP_SELECTED,1);

chargerait le processeur de 10 à 15%.

De plus, les appels

   ObjectSetString(0,"MT object",OBJPROP_BMPFILE,"::MT object");  

   ObjectSetString(0,"MT object",OBJPROP_TEXT,"QWERTY");

charger le processeur de ces mêmes 10-15%.

En même temps, les appels simultanés des trois fonctions

ObjectSetInteger(0,"MT object",OBJPROP_SELECTED,1);
   
ObjectSetString(0,"MT object",OBJPROP_BMPFILE,"::MT object");  

ObjectSetString(0,"MT object",OBJPROP_TEXT,"QWERTY");

Ne provoque pas l'empilement des charges. La charge est encore de 10-15%.

Cependant, si vous ajoutez à ces appels une boucle de réinitialisation constante du tableau d'un million de cellules

for(int a1 = 0; a1 < 1000000; a1++)Arr[a1] = MathRand();

puis la charge du CPU passe à 50%.

//-----------------------------------------------------------------------------------------------------------------------------------------------------

La fonction elle-même

ResourceCreate("::MT object",Arr,1000000,1,0,0,0,COLOR_FORMAT_XRGB_NOALPHA);

ne charge pas le processeur.

La fonction

ResourceReadImage("::MT object",Arr,w,h);

chargera de 0 à 5% selon la taille du tableau Arr[].

DirectX MetaTrader 4 Build 529 Comment êtes-vous avec un

Реter Konow 2019.01.05 10:17 #1226

Voici un conseiller de test. Vous devez commenter les lignes et vérifier la charge du processeur dans le gestionnaire de tâches.

Dossiers :

Test_1.mq4 11 kb

Реter Konow 2019.01.05 10:21 #1227

Voici son code :

//+------------------------------------------------------------------+
//|                                                       Test_1.mq4 |
//|                                                      Peter Konow |
//|                                             https://www.mql5.com |
//+------------------------------------------------------------------+
#property copyright "Peter Konow"
#property link      "https://www.mql5.com"
#property version   "1.00"
#property strict
//+------------------------------------------------------------------+
//| Expert initialization function                                   |
//+------------------------------------------------------------------+
uint Arr[1000000];
//+------------------------------------------------------------------+
int OnInit()
  {
//--- create timer
   EventSetMillisecondTimer(16); 
   //----------------------------------------------------
   //Создаем МТ-объект.
   //----------------------------------------------------
   ObjectCreate(0,"MT object",OBJ_BITMAP_LABEL,0,0,0);
   //----------------------------------------------------
   //Соединяем с файлом.
   //----------------------------------------------------   
   ObjectSetString(0,"MT object",OBJPROP_BMPFILE,"::MT object");
   //----------------------------------------------------
   //Создаем ресурс.
   //----------------------------------------------------
   ResourceCreate("::MT object",Arr,1000000,1,0,0,0,COLOR_FORMAT_XRGB_NOALPHA);   
   //----------------------------------------------------  
//---
   return(INIT_SUCCEEDED);
  }
//+------------------------------------------------------------------+
//| Expert deinitialization function                                 |
//+------------------------------------------------------------------+
void OnDeinit(const int reason)
  {
//--- destroy timer
   EventKillTimer();
   
  }
//+------------------------------------------------------------------+
//| Expert tick function                                             |
//+------------------------------------------------------------------+
void OnTick()
  {
//---
   
  }
//+------------------------------------------------------------------+
//| Timer function                                                   |
//+------------------------------------------------------------------+
void OnTimer()
  {
//---
   uint w = 0,h = 0;
   string name;
   //----------------------------------------------------
   //Читаем свойство bool.//Нагрузка процессора отсутствует.
   //----------------------------------------------------
   ObjectGetInteger(0,"MT object",OBJPROP_SELECTED);
   //----------------------------------------------------
   
   //----------------------------------------------------
   //Устанавливаем свойство bool.//Нагрузка процессора: 10% - 15%.
   //----------------------------------------------------
   ObjectSetInteger(0,"MT object",OBJPROP_SELECTED,1);
   //---------------------------------------------------- 
   
   //---------------------------------------------------- 
   //Перерисовываем изображение в массиве Arr[].
   //Нагрузка процессора зависит от размера массива. 
   //При 10000 ячеек, нагрузки нет, при 1000000 ячеек, - ~35%.
   //---------------------------------------------------- 
   for(int a1 = 0; a1 < 1000000; a1++)Arr[a1] = MathRand();
   //---------------------------------------------------- 
   
   //---------------------------------------------------- 
   //Пересоздаем ресурс.//Нагрузка процессора отсутствует
   //при любом размере массива.
   //----------------------------------------------------
   ResourceCreate("::MT object",Arr,1000000,1,0,0,0,COLOR_FORMAT_XRGB_NOALPHA);   
   //---------------------------------------------------- 
   
   //----------------------------------------------------
   //Читаем ресурс.
   //Нагрузка процессора зависит от размера массива. 
   //При 10000 ячеек, нагрузки нет, при 1000000 ячеек, 
   //Нагрузка "плавает" от 1 до 6%.   
   //----------------------------------------------------
   ResourceReadImage("::MT object",Arr,w,h);     
   //----------------------------------------------------
   
   //----------------------------------------------------
   //Пересоединяем с файлом.//Нагрузка процессора: 10% - 15%
   //----------------------------------------------------   
   ObjectSetString(0,"MT object",OBJPROP_BMPFILE,"::MT object");  
   //----------------------------------------------------
   
   //----------------------------------------------------
   //Устанавливаем описание объекта.//Нагрузка процессора: 10% - 15%
   //---------------------------------------------------- 
   ObjectSetString(0,"MT object",OBJPROP_TEXT,"QWERTY");   
   //----------------------------------------------------
   
   //----------------------------------------------------
   //Читаем описание объекта.//Нагрузка процессора отсутствует.
   //---------------------------------------------------- 
   name = ObjectGetString(0,"MT object",OBJPROP_TEXT);         
  }
//+------------------------------------------------------------------+

Реter Konow 2019.01.05 10:30 #1228

Andrey Barinov:

Il y a un problème avec les données de la colonne Heure d'ouverture dans l'image.

Oui, j'ai utilisé TimeToStr(OrderOpenPrice(),TIME_MINUTES|TIME_SECONDS) ;

Je ne sais pas pourquoi c'est comme ça.

Maxim Kuznetsov 2019.01.05 10:48 #1229

Реter Konow:

Je dois admettre que j'ai été un peu surpris par les résultats du test.

Nous parlons donc d'appels de fonction constants à une fréquence de 16 ms.

Il s'avère que c'est l'initialisation de la matrice de pixels pendant le dessin qui charge le plus le processeur.

Mais la chose la plus étrange était que l'appel répété de la fonction

chargerait le processeur de 10 à 15%.

De plus, les appels

charger le processeur de ces mêmes 10-15%.

En même temps, les appels simultanés des trois fonctions

Ne provoque pas l'empilement des charges. La charge est encore de 10-15%.

Cependant, si vous ajoutez à ces appels une boucle de réinitialisation constante du tableau d'un million de cellules

puis la charge du CPU passe à 50%.

//-----------------------------------------------------------------------------------------------------------------------------------------------------

La fonction elle-même

ne charge pas le processeur.

La fonction

charge de 0 à 5%, selon la taille du tableau Arr[].

Retrog Konow:

Je dois admettre que j'ai été un peu surpris par les résultats du test.

Donc, nous parlons d'appels de fonctions constants à 16 msec.

Il s'avère que c'est l'initialisation d'un tableau de pixels pendant le dessin qui charge le plus le processeur.

Mais la chose la plus étrange était que l'appel répété de la fonction

chargerait le processeur de 10 à 15%.

De plus, les appels

charger le processeur de ces mêmes 10-15%.

En même temps, les appels simultanés des trois fonctions

Ne provoque pas l'empilement des charges. La charge est encore de 10-15%.

Cependant, si vous ajoutez à ces appels une boucle de réinitialisation constante du tableau d'un million de cellules

puis la charge du CPU passe à 50%.

//-----------------------------------------------------------------------------------------------------------------------------------------------------

La fonction elle-même

ne charge pas le processeur.

La fonction

chargera de 0 à 5% selon la taille du tableau Arr[].

Peter, il y a un sentiment persistant que vous n'écoutez rien de ce qu'on vous dit depuis des centaines de pages.
Relisez le fil de discussion - il y a des réponses à la question "pourquoi".

Andrey Barinov 2019.01.05 11:49 #1230

Реter Konow:

Oui, j'ai utilisé TimeToStr(OrderOpenPrice(),TIME_MINUTES|TIME_SECONDS) ;

Je ne sais pas pourquoi.

Parce qu'au lieu de OrderOpenPrice mettez OrderOpenTime()

Mon approche. Le noyau est le moteur. - page 123