OpenCL: desafios reais - página 6

[Roffild]

Mathemat: Ainda não o verifiquei no testador.

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...

[Sceptic Philozoff]

Roffild:

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.

É você que deve ligar o seu cérebro porque 0,35300 ms refere-se ao clEnqueue[Read/Write]Buffer() e não ao acesso à memória global dentro do núcleo.

Este comando não está presente no OpenCL para implementação de MQL5. Do que está a falar?

[Vladimir Gomonov]

Roffild:

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).

[Roffild]

Mathemat:

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!

Mathemat:

É 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 núcleo.

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

MetaDriver: O critério principal é a razão t_alg/t_mem, onde t_alg é o tempo de cálculo optimizado do algoritmo do kernel e t_mem é o tempo de acesso à memória eliminada (*). Por outras palavras, quanto mais "pesados" forem os cálculos e quanto menor for a transferência da matriz de e para o dispositivo, maior é o potencial de aceleração com o OpenCL.

Este é um critério apenas para optimizar a execução. Não havia números aproximados sobre a taxa de transferência dos próprios amortecedores antes dos meus postos.

[Roffild]

Pessoal, antes de continuarem a discutir, pensem nos três postos que aqui começam e especificamente sobre

mql5: Neste exemplo particular, a vantagem de utilizar o OpenCL é consumida pelas despesas de cópia em buffer.

Porque estão concentrados na optimização do próprio núcleo enquanto os meus posts são sobre amortecedores.

[Sceptic Philozoff]

Roffild: Só para que saiba: clEnqueueReadBuffer = CLBufferRead e clEnqueueWriteBuffer = CLBufferWrite e são chamados sincronicamente.

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.

Roffild:

É 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.

Está bem. Contra quem tem uma queixa? O fabricante da placa gráfica?

[Roffild]

Mathemat: Também sei que CLBuffer[Leitura/Escrita] é análogo 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 existem no OpenCL para MQL5.

Não há aí qualquer diferença. Provavelmente existe um invólucro deste tipo:

template<typename T>
cl_int BufferWrite(cl_mem buffer, const T *ptr)
{
        size_t bufsize;
        errcode = clGetMemObjectInfo(buffer, CL_MEM_SIZE, sizeof(bufsize), &bufsize, 0);
        return (errcode = clEnqueueWriteBuffer(enqueue, buffer, CL_TRUE, 0, bufsize, ptr, NULL, NULL, NULL));
}
template<typename T>
cl_int BufferRead(cl_mem buffer, T *ptr)
{
        size_t bufsize;
        errcode = clGetMemObjectInfo(buffer, CL_MEM_SIZE, sizeof(bufsize), &bufsize, 0);
        return (errcode = clEnqueueReadBuffer(enqueue, buffer, CL_TRUE, 0, bufsize, ptr, NULL, NULL, NULL));
}

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 segunda pode ser resolvida optimizando o próprio núcleo, enquanto a primeira é uma restrição de ferro e o cérebro não vai ajudar.

Ok. Contra quem tem uma queixa? O fabricante da placa de vídeo?

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).

[Vladimir Gomonov]

Roffild:

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...

:)

[Roffild]

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.

[Sceptic Philozoff]

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?

uint units = (uint)CLGetInfoInteger(hcontext, CL_DEVICE_MAX_COMPUTE_UNITS);
uint global_work_offset[] = {0};
uint global_work_size[1];
uint local_work_size[1];
global_work_size[0] = ArraySize(price);
local_work_size[0] = global_work_size[0] / units;

- 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?