![MQL5 - Linguagem para estratégias de negociação inseridas no terminal do cliente MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Bem, então porque é que afixou disparates não controlados?
Talvez eu seja o único que já tentou o OpenCL no testador, afinal de contas. experimentou-o...
Bem, então porque é que postou disparates não verificados?
Afinal, sou provavelmente o único que utilizou o OpenCL no testador. experimentou-o...
Não é um disparate, é um pedido satisfeito.
Mais uma vez, escreva ao Servicedesk e justifique o que pretende. Se não o conseguir justificar, esse é o seu problema.
No momento da redacção destes artigos, a conversa sobre a utilização do OpenCL no testador ainda não tinha começado com seriedade. O pedido refere-se a esse mesmo tempo.
Revisar novamente os meus postos.
O critério principal: execução do código MQL no "OpenCL style" para 1 tick deve exceder o tempo = Number_Buffers * 0,35300 ms
Para descobrir a velocidade do algoritmo em MQL com precisão a microssegundos (1000 microssegundos = 1 milissegundo) terá de correr várias vezes no testador e no Total_Time / Number_of_Ticks (o meu posto superior).
Se não fosse o atraso do tampão, o meu código passaria o teste em ~30 segundos - isto é ~2 vezes mais rápido que o MQL "estilo OpenCL" (55 segundos) e ~11 vezes mais rápido que o código normal (320 segundos).
Que outros critérios existem?
Não lhe peço que releia todas as minhas mensagens do fórum no OpnCL. :) Todos os critérios básicos são aí descritos e discutidos.
O critério principal é a razão t_alg/t_mem onde t_alg- algoritmo optimizado de tempo de cálculo do algoritmo do kernel e t_mem- tempo de acesso da memória apagada (*). Quanto mais longo for este critério, melhores são as perspectivas de aceleração via OpenCL. Por outras palavras, quanto mais pesados forem os cálculos e quanto menos transferências de matriz de e para o dispositivo, melhores são as perspectivas.
(*) memória remota = todos os tipos de memória "sem registo" (a memória de registo é muito rápida), por exemplo (1) a memória global do dispositivo é muito mais lenta do que a memória de registo mas muito mais rápida do que (2) a memória externa ao dispositivo (CPU RAM).
Isto não é um disparate, mas uma aplicação satisfatória.
Mais uma vez, escreva ao Servicedesk e justifique o que pretende. Se não o conseguir justificar, esse é o seu problema.
Mais uma vez: bug #865549 de 2013.10.17 23:17 e os criadores são notificados, mas é pouco provável que consertem alguma coisa. Provavelmente esta limitação alguém deles adicionou de propósito para não suspender todo o processador durante a optimização.
Mas os artigos não dizem uma palavra sobre o assunto!
Este comando não está presente na implementação do OpenCL para MQL5. Do que está a falar?
Eh.... Também está a distribuir artigos sobre OpenCL...
Só para que saiba, clEnqueueReadBuffer = CLBufferRead e clEnqueueWriteBuffer = CLBufferWrite são chamados sincronicamente.
A aprendizagem começa aqui
Pessoal, antes de continuarem a discutir, pensem nos três postos que aqui começam e especificamente sobre
Porque estão concentrados na optimização do próprio núcleo enquanto os meus posts são sobre amortecedores.
Há muito tempo que sei que a implementação do OpenCL para MQL5 é apenas um invólucro sobre o verdadeiro API. A propósito, escrevi no meu segundo artigo que falta a possibilidade de definir a dimensão do grupo de trabalho. Fizeram um pedido de servicedesk, e fizeram-no passado algum tempo.
Também sei que CLBuffer[Leitura/Escrita] é semelhante ao clEnqueue[Leitura/Escrita]Buffer, mas estas funções não são de todo idênticas: têm sintaxes diferentes.
Mas não compreendo porque continua a falar de funções clEnqueueXXX que não estão presentes no OpenCL para MQL5.
Tentarei compreender o que pretende.
É tempo de ligar o cérebro porque 0,35300 ms refere-se ao clEnqueue[Leitura/Escrita]Buffer() e não ao acesso à memória global dentro do kernel.
A segunda pode ser resolvida através da optimização do próprio núcleo enquanto a primeira é uma limitação de ferro.
Mas não compreendo porque continua a falar de funções clEnqueueXXX que não existem no OpenCL para MQL5.
Não há aí qualquer diferença. Provavelmente existe um invólucro deste tipo:
Por isso, também não é necessário elaborar sobre a sintaxe. O facto de o 3º argumento = CL_TRUE já ter sido confirmado.
Mathemat:
A queixa é para os redactores dos artigos que não há dados práticos sobre esta limitação mais importante! (Não havia, até eu o testar).
A queixa é dirigida aos autores do artigo, de que não há dados práticos sobre esta limitação mais importante! (Não havia, até eu o testar).
E não leia mais artigos, não se vai queixar. ;)
--
Porque está a implicar comigo? Como pode citar dados desconhecidos num artigo? O atraso na transferência de dados de/para um dispositivo é enorme e deve ser tido em conta? Os números específicos dependem do hardware específico. Bem, já o testou em si mesmo e bom para si. Por vezes, as pessoas (incluindo eu próprio) estabelecem o código de teste para estimar as capacidades e limitações de diferentes hardware. Pedem a outras pessoas que partilhem resultados, as pessoas fazem-no frequentemente (kudos para eles por isso), ao mesmo tempo que todos podem ver estatísticas e o que funciona em que combinações. Depois alguém recompra hardware ou altera abordagens à escrita de código com os resultados em mente. O que quer? Bem, escreva uma queixa ao Sportlotto, talvez isso faça o seu código funcionar mais rapidamente...
:)
Na verdade, já terminei tudo em https://www.mql5.com/ru/forum/13715/page5#comment_646513, mas os próprios autores dos artigos queriam provar algo mais.
Não há informação específica e muito importante nos seus artigos, pelo que não estão acabados e descrevem tarefas irrealistas.
Pode não acrescentar informações aos artigos, mas é uma tolice fingir que estas figuras particulares não significam nada.
Não compreendo o significado oculto do guião/conselheiro que postou, Roffild. O código é, para o dizer de forma suave, incompreensível.
- Onde está o pragma cl_khr_fp64? É necessário quando se calcula com o dobro no núcleo.
- Porque é que existe este código na função OnTick(), que pode ser colocado na inicialização inicial calculando uma vez?
- Porque é que a dimensão da tarefa global é igual a 240 bytes? Teria de ser muito maior para se obter algum benefício do OpenCL. Bem, deveria ser pelo menos um milhão de vezes maior se se puder julgar apenas a olho nu.
- Porque é que uma tarefa global deve dividir-se pelo número de unidades para obter o tamanho de uma unidade local? Tanto a CPU como a GPU permitem dividir uma tarefa global num número muito maior de subtarefas. E as unidades no seu caso são apenas um número de motores SIMD.
Digamos que tenho, por exemplo, o número de unidades na minha placa de vídeo é 28 (Radeon HD7950). Mas este número não divide exactamente 240. Isto significa que uma parte significativa dos cálculos pode ser não paralela.
O número de shaders que tenho é de 1792. O seu é 1440. Este é aproximadamente o número que é melhor dividir a tarefa global, para carregar correctamente o mapa. Mas terá de calcular o tamanho correcto da tarefa global. (E é melhor não dividir, mas multiplicar).
E o que o seu mapa está a contar durante todo este tempo não é de todo claro.
Em resumo: o que deve fazer o seu código?