Minha abordagem. O núcleo é o motor. - página 123

Novo comentário
 
Реter Konow:

...

ZS. É possível, no entanto, que o processador esteja sendo sobrecarregado por um novo desenho. Ou seja, desenhando dentro de uma matriz de pixels. Em outras palavras, inicialização constante da matriz com valores, ocorrendo em alta freqüência (16ms) de tempo.

Não, o redesenho não carrega o processador de forma alguma; são necessários alguns nano- ou no máximo microssegundos para que ele envie um comando para o driver gráfico. O processador da placa de vídeo realiza a pintura em si, pixel a pixel, enquanto que geralmente há centenas delas e elas trabalham simultaneamente com o processador em paralelo. Ou seja, o processador emite o comando para o driver gráfico: exibir um círculo com o centro nas coordenadas Xc, Yc e raio R em modo CopyPut. Para o processador, esta é apenas uma chamada de função com parâmetros passados. Não vai mais longe do que isso. Tais chamadas não fazem mais do que, por exemplo, 2 vezes por segundo, caso contrário o usuário simplesmente não consegue entender nada na tela, não pode ser puxado com tanta freqüência. Para uma lista de negociações abertas, você pode imaginar que pode levar uma hora ou um dia ou mais.

E o algoritmo (google "Bresenham Algorithm", por exemplo) de coloração pixel por pixel é executado pela placa gráfica, e o processador não permanece sobre ela. Também é executado muito rapidamente. E... uma vez por chamada. Nenhuma reinicialização a 16ms é necessária, a imagem da tela é mantida constante na memória de vídeo até que uma nova mudança seja feita sob o comando do processador. Além disso, para acelerar a resposta da tela visível, a memória de vídeo também é mantida em duas instâncias, as mudanças são feitas na invisível, e então a página de vídeo é trocada imediatamente.

Se sua abordagem da saída da tela ainda tiver a " inicialização constante da matriz" de pixels que você descreve - você deve se livrar dela, não é o caso.

 
Реter Konow:

Clique para ver.

Há algo errado com os dados da coluna Tempo de Abertura na figura.

 
Vladimir:

Não, o redesenho não carrega o processador de forma alguma; são necessários no máximo alguns nano- ou microssegundos para que ele envie um comando para o driver gráfico. Os processadores da placa de vídeo executam a pintura em si, pixel a pixel, enquanto normalmente há centenas deles e trabalham simultaneamente com o processador, em paralelo. Ou seja, o processador emite o comando para o driver gráfico: exibir um círculo com o centro nas coordenadas Xc, Yc e raio R em modo CopyPut. Para o processador, esta é apenas uma chamada de função com parâmetros passados. Não vai mais longe do que isso. Tais chamadas não fazem mais do que, por exemplo, 2 vezes por segundo, caso contrário o usuário simplesmente não consegue entender nada na tela, não pode ser puxado com tanta freqüência. Para uma lista de negociações abertas, você pode imaginar que pode levar uma hora ou um dia ou mais.

E o algoritmo (google "Bresenham Algorithm", por exemplo) de coloração pixel por pixel é executado pela placa gráfica, e o processador não permanece sobre ela. Também é executado muito rapidamente. E... uma vez por chamada. Nenhuma reinicialização a 16ms é necessária, a imagem da tela é mantida constante na memória de vídeo até que uma nova mudança seja feita sob o comando do processador. Além disso, para acelerar a resposta da tela visível, a memória de vídeo também é mantida em duas cópias, as mudanças são feitas na invisível, e então a página de vídeo é trocada imediatamente.

Se sua abordagem para a saída da tela ainda tiver a " inicialização permanente da matriz" de pixels que você descreve - você deve se livrar dela, não é o caso.

Que bagunça...
É uma miscelânea de conhecimentos fragmentados.

No final das contas, não é assim que funciona.

 
Vladimir:

Não, o redesenho não carrega o processador de forma alguma; são necessários no máximo alguns nano- ou microssegundos para que ele envie um comando para o driver gráfico. Os processadores da placa de vídeo executam a pintura em si, pixel a pixel, enquanto normalmente há centenas deles e trabalham simultaneamente com o processador, em paralelo. Ou seja, o processador emite o comando para o driver gráfico: exibir um círculo com o centro nas coordenadas Xc, Yc e raio R em modo CopyPut. Para o processador, esta é apenas uma chamada de função com parâmetros passados. Não vai mais longe do que isso. Tais chamadas não fazem mais do que, por exemplo, 2 vezes por segundo, caso contrário o usuário simplesmente não consegue entender nada na tela, não pode ser puxado com tanta freqüência. Para uma lista de negociações abertas, você pode imaginar que pode levar uma hora ou um dia ou mais.

E o algoritmo (google "Bresenham Algorithm", por exemplo) de coloração pixel por pixel é executado pela placa gráfica, e o processador não permanece sobre ela. Também é executado muito rapidamente. E... uma vez por chamada. Nenhuma reinicialização a 16ms é necessária, a imagem da tela é mantida constante na memória de vídeo até que uma nova mudança seja feita sob o comando do processador. Além disso, para acelerar a resposta da tela visível, a memória de vídeo também é mantida em duas instâncias, as mudanças são feitas na invisível, e então a página de vídeo é trocada imediatamente.

Se sua abordagem da saída ainda tiver a " inicialização constante da matriz" de pixels - você precisa se livrar dela.

Você tem uma teoria interessante, embora não se encaixe bem com os resultados de minhas experiências, que agora vou postar abaixo.

Como o teste mostra, é a inicialização da matriz de pixels que mais carrega a CPU.

Verifique o teste EA abaixo.

 

Tenho que admitir que fiquei um pouco surpreso com os resultados do teste.

E assim, estamos falando de chamadas de funções constantes a uma freqüência de 16 ms.

Acontece que é a inicialização da matriz de pixels durante o desenho que mais carrega o processador.

Mas o mais estranho foi que a repetida chamada de função

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

carregaria o processador em 10 a 15%.

Além disso, as chamadas

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

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

carregar o processador pelos mesmos 10-15%.

Ao mesmo tempo, chamadas simultâneas de todas as três funções

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

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

Não causa empilhamento de carga. A carga ainda é de 10-15%.

Entretanto, se você adicionar um loop de reinicialização constante de um milhão de células a essas chamadas

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

então a carga da CPU sobe para 50%.

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

A função em si

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

não carrega o processador.

A função

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

será carregado de 0 a 5%, dependendo do tamanho da matriz Arr[].

 

Aqui está um assessor de testes. Você precisa comentar sobre as linhas e verificar a carga da CPU no gerenciador de tarefas.

Arquivos anexados:
Test_1.mq4  11 kb
 

Aqui está seu código:

//+------------------------------------------------------------------+
//|                                                       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);         
  }
//+------------------------------------------------------------------+
 
Andrey Barinov:

Há algo errado com os dados da coluna Tempo de Abertura na figura.

Sim. Eu usei TimeToStr(OrderOpenPrice(),TIME_MINUTES|TIME_SECONDS);

Eu não sei por que é assim.

 
Реter Konow:

Tenho que admitir que fiquei um pouco surpreso com os resultados do teste.

E assim, estamos falando de chamadas de funções constantes a uma freqüência de 16 ms.

Acontece que é a inicialização da matriz de pixels durante o desenho que mais carrega o processador.

Mas o mais estranho foi que a repetida chamada de função

carregaria o processador em 10 a 15%.

Além disso, as chamadas

carregar o processador pelos mesmos 10-15%.

Ao mesmo tempo, chamadas simultâneas de todas as três funções

Não causa empilhamento de carga. A carga ainda é de 10-15%.

Entretanto, se você adicionar um loop de reinicialização constante de um milhão de células a essas chamadas

então a carga da CPU sobe para 50%.

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

A função em si

não carrega o processador.

A função

cargas de 0 a 5%, dependendo do tamanho da matriz Arr[].

Retrog Konow:

Devo admitir que fiquei um pouco surpreso com os resultados do teste.

Portanto, estamos falando de chamadas de funções constantes a 16 msec.

Acontece que é a inicialização de um conjunto de pixels durante o desenho que carrega o processador mais do que tudo.

Mas o mais estranho foi que a repetida chamada de função

carregaria o processador em 10 a 15%.

Além disso, as chamadas

carregar o processador pelos mesmos 10-15%.

Ao mesmo tempo, chamadas simultâneas de todas as três funções

Não causa empilhamento de carga. A carga ainda é de 10-15%.

Entretanto, se você adicionar um loop de reinicialização constante de um milhão de células a essas chamadas

então a carga da CPU sobe para 50%.

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

A função em si

não carrega o processador.

A função

será carregado de 0 a 5%, dependendo do tamanho da matriz Arr[].


Peter, há um forte sentimento de que você não escuta nada do que lhe foi dito durante centenas de páginas.
Reler o fio - há respostas para a pergunta "por que assim é".

 
Реter Konow:

Sim. Eu usei TimeToStr(OrderOpenPrice(),TIME_MINUTES|TIME_SECONDS);

Eu não sei por que.

Porque ao invés de OrderOpenPrice colocar OrderOpenTime()

1...116117118119120121122123124125126127128129130...184
Novo comentário