OpenCL: desafios reais - página 7

Novo comentário
 

1) Pragmas são um requisito de apoio em tempo de compilação, não de activação do próprio apoio (como parece pensar). Assim, cl_khr_fp64 já está envolvido se os seus visos o suportarem.

2) E se o tamanho da matriz mudar em tempo de execução? Claro que pode ser feito neste código em particular, mas não vai melhorar a situação.

Deixem-me dizer-vos desde já que estava a traçar o meu perfil no AMD CodeXL:

3) Se tomarmos apenas o tempo de computação do próprio kernel, qualquer tarefa paralela na GPU ganhará benefícios ao utilizar mais núcleos na CPU. Assim, mesmo 8 tarefas são suficientes para acelerar as coisas.

4) Eu próprio tenho muitas perguntas sobre a fórmula de cálculo local. O maior ganho teve lugar quando no trabalho_dim=1 reparti tarefas por todos os núcleos do widget e isto é UNIDADES.

E porque se divide o tamanho do tampão em geral, quando se deve dividir o número dos seus elementos? - o que de facto fiz.

Mathemat: Em resumo: o que é que o seu código tem de fazer?

Mostrar que a fase de preparação para os cálculos não é instantânea e a transferência de buffer leva muito tempo; questiona a praticabilidade da utilização do OpenCL mesmo para tarefas alimentadas.

Também mostra que a CPU não é seleccionada no testador.

 
Roffild:

Mostrar que a fase de preparação para os cálculos não é instantânea e a transferência de tampão leva muito tempo, o que põe em causa a praticabilidade da utilização do OpenCL mesmo para tarefas sobrecarregadas.

Ou seja, é bastante tolo gritar sobre isso; medi-lo, por outro lado, é uma outra questão; pode ser praticamente útil.

Também mostra que o CPU não é seleccionado no testador.

Talvez se justifique, mas talvez seja um excesso de seguro. De qualquer modo, tenho a certeza de que foi feito conscientemente para assegurar a eficiência do próprio processo de teste, ou melhor, a optimização (uma vez que é multi-tarefa). Aqui podem surgir oportunidades de conseguir a inclusão se a noção de teste e optimização estiver clara e completamente separada (a nível de política partidária), ou seja, defini-las como diferentes tipos lógicos de utilização do testador. Com suporte de software correspondente (oficialmente diferente). (Isto seria bom em muitos aspectos, e eu sou um apoiante de longa data de tal separação/distinção. Até diferentes botões para começar a optimização e testes).

Teoricamente, a selecção de CPU poderia então ser permitida durante os testes e não autorizada durante a optimização (isto é correcto).

 
Roffild: 1) Os Pragmas são um requisito de suporte em tempo de compilação, não uma activação do suporte em si (como parece pensar). Ou seja, cl_khr_fp64 já está envolvido se as vísceras o suportarem.

Sim, exagerei com o pragmatismo. Se continuar a trabalhar no seu widget e não passar o código a ninguém, não há problema. Mas se alguém o quiser ler no cartão Barts (digamos, 6870), haverá problemas. O código do kernel tentará executar sem mostrar erros.

4) Eu próprio tenho muitas perguntas sobre a fórmula de cálculo Local. O maior ganho foi quando o work_dim=1 espalha tarefas por todos os núcleos do widget, e isto é UNITS.

Não necessariamente. É muitas vezes muito mais útil aumentar o trabalho no próprio núcleo. É para equilibrar as despesas gerais associadas à transferência de dados.

E a sua UNIDADE é apenas um número de motores SIMD. De acordo com a documentação,

local_work_size[] define um subconjunto de tarefas a serem executadas pelo kernel do programa OpenCL especificado . A sua dimensão é igual a work_items[]e permite cortar o subconjunto total de tarefas em subconjuntos mais pequenos sem resíduos de divisão . De facto, o tamanho da matrizlocal_work_size[] deve ser escolhido para que o conjunto de tarefas globais work_items[] seja cortado em subconjuntos mais pequenos. Neste exemplo ,local_work_size[3]={10, 10, 10} serve , uma vez que oswork_items[40, 100, 320] podem ser montados a partir do array local_items[10, 10, 10] sem qualquer resíduo .

O número de motores SIMD é uma constante estritamente de hardware que não tem de dividir de todo a tarefa global.

Mas primeiro é preciso avaliar devidamente o problema global em si.

Sobre o CPU no testador - estou convencido, estou convencido.

 
MetaDriver:

Bem, isto não é de todo novidade. É uma tolice gritar sobre isso, mas medi-lo é outra questão inteiramente diferente; pode ser praticamente útil.

Só que, por alguma razão, tive de tomar estas medidas. Quando se lê "há um atraso na transmissão" não se tem ideia do seu tamanho.

Mathemat: E a sua UNIDADE é apenas um número de motores SIMD. De acordo com a documentação,

O número de motores SIMD é uma constante estritamente de hardware, que não tem de dividir de todo a tarefa global.

Vamos utilizar melhor a documentação oficial:

CL_DEVICE_MAX_COMPUTE_UNITS cl_uint O número de unidades de cálculo paralelas no dispositivo OpenCL. Um grupo de trabalho executa numa única unidade computacional. O valor mínimo é 1.
local_work_size.
Aponta para um conjunto de valores de trabalho_dim não assinados que descrevem o número de itens de trabalho que constituem um grupo de trabalho (também referido como o tamanho do grupo de trabalho) que executará o kernel especificado pelo kernel.
Assim, as minhas conclusões estão correctas e confirmadas pela execução do AMD CodeXL
 

A questão é diferente. Chame as suas unidades barris, mas o facto é que as unidades no seu código não dividem o inteiro da tarefa global (o meu certamente não: 240/28 não é inteiro; o seu também, uma vez que tem unidades=18). Isto é um insecto.

E segundo, aqui e agora está a trabalhar com OpenCL para MQL5 (bem, isso não está certo, mas apanhou-me); isso, afinal, é um OpenCL diferente do de Khronos.

P.S. Eu não criei o hyperlink; apenas o consegui sozinho :)

Roffild:
CL_DEVICE_MAX_COMPUTE_UNITS cl_uint O número de unidades de cálculo paralelas no dispositivo OpenCL. Um grupo de trabalho executa numa única unidade computacional. O valor mínimo é 1.

Ver outras fontes para a definição de "unidades de computação".

A propósito, aqui está uma tabela do meu segundo artigo. Seria bom se compreendesse todas estas unidades de cálculo (18), núcleos de fluxo (288), elementos de processamento (1440), max wavefronts/GPU (496) e work-items/GPU (31744). Ainda não o descobri.


 
Mathemat:

A questão é diferente. Chame as suas unidades barris, mas o facto é que as unidades no seu código não dividem o inteiro da tarefa global (o meu certamente não: 240/28 não é inteiro; o seu também, uma vez que tem unidades=18). Isto é uma falha.

Então porque é que baseou o número de bytes em 240? Pode ser capaz de o fazer, mas a placa gráfica não pode. Assim 240/8 = 30 duplas.

240 bytes é o tamanho de todo o amortecedor de 30 duplas.

E "escolher uma divisória inteira" é apenas uma recomendação da documentação oficial. E essa recomendação não funciona na perfeição.

E UNITS não é minha; é apenas um conselho dos fóruns do OpenCL. Testei-o e consegui velocidade máxima...

Mathemat:

E a segunda coisa: aqui e agora está a trabalhar com OpenCL para MQL5 (bem, isso não está certo, mas apanhou-me) onde é, afinal, um OpenCL diferente daquele de Khronos.

E o que é o "outro"?

Está a confundir implementações proprietárias e invólucros simples. OpenCL MQL é apenas um invólucro sobre Khronos OpenCL API. Sobre a diferença entre OpenCL MQL e Khronos.

 
Mathemat: A propósito, aqui está a tabela do meu segundo artigo. Seria bom se compreendesse todas estas unidades de cálculo (18), núcleos de fluxo (288), elementos de processamento (1440), max wavefronts/GPU (496) e work-items/GPU (31744). Ainda não o descobri.

unidades de computação é o número de tarefas simultâneas que estão a ser executadas.

max wavefronts/GPU (496) e work-items/GPU (31744) são a fila de espera para correr.

AMD CodeXL já tem uma resposta a todas estas perguntas.

 
Roffild:

unidades de computação é o número de tarefas simultâneas que estão a ser executadas.

max wavefronts/GPU (496) e work-items/GPU (31744) são a fila de espera para execução.

AMD CodeXL pode finalmente ajudá-lo - responde a todas estas perguntas.

Talvez eu não entenda alguma coisa, desculpe. Mas conhece Alexey pessoalmente? Mas pelo lado não parece..... falas demasiado atrevido, mais esperto que os outros? ser esperto não é pecado, vangloriar-se disso entre irmãos em espírito é vergonhoso, no entanto...

 

Eu sou um tipo simples e respondo ao ponto.

Se quer realmente compreender o OpenCL e não apenas assumir, terá de colocar AMD CodeXL e criar o seu próprio invólucro C/C++.

Posso colocar o meu invólucro, mas tem algumas linhas ilógicas devido à minha falta de prática em C/C++.

 
Roffild: Então porque é que tomou 240 bytes como número base? Pode ser capaz de o fazer, mas a placa de vídeo não o pode fazer. Assim 240/8 = 30 duplas.

240 bytes é o tamanho de todo o amortecedor de 30 duplas.

Veja o seu próprio código: 

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);
Print( "Глобальная задача = ", global_work_size[0] );  /// Это я добавил, вышло 240. Но это и так легко подсчитать: 30*double = 240
local_work_size[0] = global_work_size[0] / units;

Além disso, na última linha, você mesmo divide 240 por 18 (estas são unidades para o seu mapa).

E "apanhar a divisória inteira" é apenas uma recomendação da documentação oficial. E esta recomendação não funciona na perfeição.

Estamos a trabalhar com a MQL5 OpenCL. Estou a referir-me à documentação no nosso sítio web. Claro, estou também a olhar para Khronos.

E quanto a UNITS, não são as minhas próprias palavras, mas alguns conselhos de fóruns OpenCL. Testei-o e consegui a velocidade máxima...

Bem, consegui velocidade máxima com parâmetros diferentes. Então?

Vamos apenas dar-lhe uma ideia geral. 18 tarefas executadas simultaneamente em moscas GPU é o máximo que pode ser feito em 4-5 cordas de CPUs. E um CPU em emulação x86 pode organizar muitos mais fios. Pelo menos se for Intel. O meu antigo Pentium G840 (2 núcleos) deu uma aceleração de cerca de 70x - em duas unidades! Já para não falar do que a minha actual... i7, por assim dizer.

Uma tarefa bem paralela (ver os scripts MetaDriver do primeiro ramo ocl) permite atingir uma velocidade até 1000 ou mais na GPU (em comparação com 1 thread na CPU em MQL5). Se não o conseguir encontrar - posso descarregá-lo para que experimente no seu cartão.

Se quer realmente compreender OpenCL e não apenas adivinhar, terá de colocar AMD CodeXL e criar o seu próprio invólucro C/C++.

OK, vou dar uma vista de olhos, obrigado.

12345678
Novo comentário
Razão: