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
Veja o seu próprio código: E depois, na última linha, você mesmo divide 240 por 18 (isto é, unidades para o seu cartão).
Está obviamente confuso com alguma coisa. Aqui está a peça controversa:
Conclusão: global=30 local=1
E 240 bytes é exactamente quando se cria o tampão.
Está obviamente confuso com alguma coisa. Aqui está uma peça controversa:
Produção: global=30 local=1
E 240 bytes exactamente quando se cria o tampão.
global_work_size[0]
E local_work_size[0] = (uint) 240/18 = 13
P.S. Sim, acertou. Perdão. Fiquei um pouco confuso.
local_work_size[0] = (uint) 30/18 = 1. E eu tenho o mesmo, desde unidades=28.
Mais uma vez, Roffild:
Mathemat: Давай тупо прикинем. 18 задач, выполняемых одновременно на мухах GPU, - это максимум то, что можно сделать на 4-5 нитках CPU. А CPU на x86 эмуляции может организовать гораздо больше ниток. Во всяком случае, если это Intel. Мой бывший Pentium G840 (2 ядра) дал ускорение примерно в 70 раз - на двух unit'ах! Я уже не говорю о том, что вытворяет мой текущий... условно говоря, i7.
Uma tarefa bem paralela (ver os scripts do MetaDriver da primeira thread ocl) pode atingir velocidades até 1000 ou mais na GPU (em comparação com a execução de 1 thread na CPU no MQL5). Se não o conseguir encontrar - posso enviar-lho, pode testá-lo no seu cartão.
Já descobriu o tampão e a sua velocidade?
É melhor usar o AMD CodeXL para descobrir UNIDADES, etc. - tem bons gráficos de desempenho.
O próprio AMD CodeXL é defeituoso, mas é difícil tirar quaisquer conclusões sem ele.
Não vou usar OpenCL até que o testador me permita usar CPU ou até que execute uma tarefa que dure mais do que o Número de_buffers * 0,353 msec.
P.S.
Finalmente terminei a optimização do meu código e a variante final passa o teste em 33 segundos (320 segundos - antes da optimização, 55 segundos - "OpenCL-style").
Não há nada a descobrir. É evidente que se trata de uma operação lenta. Conclusão - aumentar o trabalho dentro do núcleo (há muito pouco dele no seu código).
E comprar uma placa de vídeo mais moderna, parece ter-se tornado melhor com ela.
O próprio AMD CodeXL é defeituoso, mas é difícil tirar quaisquer conclusões sem ele.
A utilidade da Intel é bastante útil também, mas para as pedras Intel. Bem, e por apanhar os erros mais óbvios no núcleo.
P.S. Afinal, acabei de optimizar o meu código e a variante final passa agora o teste em 33 segundos (320 segundos - antes da optimização, 55 segundos - "estilo OpenCL").
Já está muito melhor.
Hoje precisava de gerar uma matriz com 1 bit em números.
Ao mesmo tempo, pratiquei com OpenCL.
Estou a afixar o código como uma demonstração de um método interessante para calcular o_tamanho_trabalho_global e o_tamanho_trabalho_local. A ideia em si é retirada de IntrotoOpenCL.pdf (tenho uma cópia), mas eu afinei-a.