OpenCL: testes internos de implementação em MQL5 - página 33
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
Andrew, digamos, Intel + Radeon é de todo uma coisa má?
Nada mau, apenas excessivamente caro (por causa do processador). :)
A propósito, sou um fã de longa data dos cartões da nVidia. Até tenho uma caixa algures com a lendária GeForce 3. E se eu quisesse jogar jogos, não hesitaria em ficar com o fabricante do chip gráfico "verde".
Numa nota séria, estou ansioso por saber que tipo de sucos vai conseguir espremer, especialmente se tiver 2 Giga DDR5. Como acontece, a memória GPU a bordo pode ser um recurso MUITO sério para o cálculo OpenCL.
De toda a informação de que disponho, concluí que o principal recurso é o número de núcleos da GPU. Se não houver núcleos suficientes, o problema divide-se em séries consecutivas de núcleos com novos fios, mas é difícil poupar neste recurso ao comprar o cartão, pois quanto mais núcleos, maior é o preço.
A segunda mais importante é a velocidade a que a memória da GPU está a funcionar (uma vez que a memória é acedida com bastante frequência). As tarefas da GPU na maioria dos casos são bastante primitivas e utilizam operações 1-2-3 antes de aceder à memória para exibir os resultados. Quaisquer operações lógicas complexas são contra-indicadas para GPU, portanto os programadores esforçar-se-iam por as minimizar, o que logicamente resultaria em acessos mais frequentes à memória. Aqui existem variantes, se a tarefa for descrita pelo programador de modo a referir-se à memória o mínimo possível, então este recurso não é tão importante.
E o terceiro recurso, eu chamaria a quantidade de memória da GPU. Desde os testes de crash demonstraram que, independentemente do número de contextos simultâneos, toda a memória distribuída nos contextos é atribuída num campo de memória e não se sobrepõe. Deixe-me explicar por exemplo: se tiver N contextos em cada um dos quais são atribuídos buffers em 1/4 da memória do dispositivo, então pode ter 4 contextos ao mesmo tempo. O quinto contexto, mesmo se o criar, não lhe será atribuída memória, uma vez que esta já é distribuída por contextos anteriores. Mas a libertação de memória em qualquer uma das anteriores (simplesmente removendo o buffer) dará algum espaço e o quinto contexto funcionará bem.
Ainda é cedo - precisamos de garantir que os programas OpenCL não penduram toda a rede devido a falhas na GPU e aos próprios programas OpenCL.
De facto, os programas OpenCL só podem ser colocados na rede após a realização de testes em agentes locais para garantir que o programa é funcional e não mata o computador.
A tarefa de uma rede de computação paralela distribuída. O próprio nome pode confundir um leitor destreinado. Se teve problemas com a organização de uma rede distribuída em máquinas com vários núcleos, agora terá problemas ao quadrado. Todos os núcleos poderiam ser considerados como unidades de rede separadas porque executam tarefas separadas. Mas anteriormente a sua velocidade de execução diferia no máximo 2-3 vezes (para as quais introduziu limites de velocidade para núcleos lentos), a quantidade de memória na maioria dos casos não desempenhava um papel, uma vez que as matrizes têm 10^7 elementos no máximo (para as máquinas modernas são cêntimos).
Mas com a GPU o problema muda drasticamente. Em primeiro lugar, apenas ~12 matrizes duplas com comprimento 10^7 já são de 1Gb, o que é um limite para muitos cartões. Em computações de CPU as tarefas com mais buffers são bastante comuns (embora, claro, o programador de GPU possa registar-se usando memória hospedeira, mas é semelhante à RAM virtual, em suma, é um mau).
Em segundo lugar, a diferença nas velocidades de execução é linearmente proporcional ao número de núcleos numa GPU. A diferença entre as duas cartas é de 10-1000 vezes.
Em geral, a tarefa do trabalho em rede resume-se à classificação do programa a ser executado. Preste atenção ao perfilador CUDA. As suas estatísticas podem ser tomadas como base para a classificação de tarefas. Se a tarefa for concebida de modo a que a maior parte do tempo seja gasto no acesso à memória, requer um cluster de máquinas com grandes tamanhos de memória, mas se a maior parte do tempo for gasto em aritmética, precisamos de um cluster com grandes números de núcleos. Os aglomerados podem ser flexíveis ou incluíveis (esta é uma questão de execução).
Embora a tarefa seja um pouco simplificada pela unificação aplicada pelo próprio tempo. Um cartão com 12 núcleos terá provavelmente 256MB, um cartão com 96 tem 512MB. Em média, os fabricantes não permitem grandes desequilíbrios (ao contrário do CPU, onde o utilizador pode enfiar a sua rocha antiga com RAM até ao aborrecimento, ou colocar o mínimo de RAM na rocha nova, apenas para poupar dinheiro ao comprar).
Embora, na minha opinião, uma abordagem mais correcta seria criar um depurador para o OpenCL e na sua base defender a optimização do dispositivo em bytecode. Caso contrário, chegaríamos ao assembler quando o programador teria de adivinhar em que cartão o programa correria e as características médias do programa para um possível ambiente.
Diga-me, se não se importa, como se faz o teste? Onde, o que mudar? Cópia, selecção, resultado:
Win7 x64 construir 607
Este exemplo não precisa de ser "executado" no testador. Para executar o guião, arraste-o do "Navegador" para o gráfico. O resultado será apresentado no painel " Ferramentas", separador " Especialistas".
w7 32 bit 4GB ( 3,5GB disponíveis)
Intel Core 2 Quad Q9505 Yorkfield (2833MHz, LGA775, L2 6144Kb, 1333MHz) vs Radeon HD 5770
w7 32 bit 4GB ( 3,5GB disponíveis)
Intel Core 2 Quad Q9505 Yorkfield (2833MHz, LGA775, L2 6144Kb, 1333MHz) vs Radeon HD 5770
Fixe, agora já sabe onde escavar... :)
os processadores já estão 2-3 gerações atrasados
e vídeo 5770 - 6770 -7770
:)
Da informação disponível cheguei à conclusão de que o principal recurso é o número de núcleos da GPU, em caso de falta deles o problema é resolvido por corridas consecutivas de núcleos com novos fios, mas é difícil poupar neste recurso quando se compra um cartão, pois quanto mais núcleos, maior é o preço.
A segunda mais importante é a velocidade a que a memória da GPU está a funcionar (uma vez que a memória é acedida com bastante frequência). As tarefas da GPU na maioria dos casos são bastante primitivas e utilizam operações 1-2-3 antes de aceder à memória para exibir os resultados. Quaisquer operações lógicas complexas são contra-indicadas para GPU, portanto os programadores esforçar-se-iam por as minimizar, o que logicamente resultaria em acessos mais frequentes à memória. Aqui existem variantes, se a tarefa for descrita pelo programador de tal forma que os acessos à memória sejam os mais baixos possíveis, então este recurso não é tão importante.
E o terceiro recurso, eu chamaria a quantidade de memória da GPU. Desde os testes de crash demonstraram que, independentemente do número de contextos simultâneos, toda a memória distribuída nos contextos é atribuída num campo de memória e não se sobrepõe. Deixe-me explicar por exemplo: se tiver N contextos em cada um dos quais são atribuídos buffers em 1/4 da memória do dispositivo, então pode ter 4 contextos ao mesmo tempo. O quinto contexto, mesmo se o criar, não lhe será atribuída memória, uma vez que esta já é distribuída por contextos anteriores. Embora ao libertar a memória em alguns dos anteriores (simplesmente removendo o buffer) algum espaço irá aparecer e o quinto contexto funcionará bem.
depois de actualizar para construir o 607, de repente consegui o opencltest a trabalhar no meu portátilhttps://www.mql5.com/ru/code/825, não funcionava antes (há cerca de duas semanas), penso que dizia "OpenCL não encontrado".
"Cheira-me a truque", ainda não mexeu com os fractais de Mandelbrot ))))))))))))) mas ainda assim é bom que um portátil novo não possa vir a calhar para testes MT5 completos