OpenCl e as ferramentas para ele. Revisões e impressões. - página 28
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
Daqui a alguns anos, vamos lembrá-lo desta linha.
Pessoalmente para mim este ramo foi muito útil - mesmo quando o iniciador do tópico começou a assustar meu espírito imaturo de horrores de precisão reduzida dos cálculos.
O modo de otimização no MT5 é muito lento quando o algoritmo genético é habilitado. Eu fiz um Expert Advisor no MT4 e o testei e otimizei. O tempo de otimização não excede 5 minutos no dual core (é claro que o MT4 tem apenas um core envolvido, mas outras tarefas não interferem, pois podem funcionar no segundo core). Eu reescrevi o mesmo Expert Advisor para o MT5. Eu o testei para otimização. O tempo de otimização é mais de uma hora, ou quase 2 horas para ser exato. Qual é a diferença?
Agora não há diferença.
Bem, o MetaTrader 5 parece estar à frente mesmo ao testar através de preços de abertura: Compare a velocidade de teste no MetaTrader 4 e no MetaTrader 5
Como prometido, simplificamos o modo de teste de abertura de barra e o tornamos mais rápido.
Bem, já se passaram dois anos.
A versão CUDA da EA está funcionando. Em MT4. Até agora, está apenas em modo de teste. Até agora, não consigo obter a velocidade dos cálculos prometidos pela nVidia.
Há dois problemas aqui:
1. A própria nVidia, que exagera a velocidade do redesenho de programas, ou NÃO prepara sua documentação, ou altera fundamentalmente alguns aspectos essenciais da programação.
2. A paralelização dos algoritmos sob GPU leva muito mais tempo do que o esperado. Quando comecei a portar um programa de DLL para CUDA-DLL, com base em meus mais de 20 anos de experiência no idioma caeliano, achei que as promessas da nVidia deveriam ser divididas por 3, e o tempo de portabilidade do algoritmo citado deveria ser multiplicado por, digamos, 3.
Mas, afinal, a regra geral é: todas as promessas da nVidia devem ser divididas por RTE e o tempo estimado de portabilidade C para a CUDA deve ser multiplicado por 10.
Nota: se você tiver compreendido os princípios da operação do acelerador GPU, você pode portar o algoritmo de C para CUDA em TRÊS SEMANAS. E você pode fazer isso diretamente - apenas para verificar a construção. Ou seja, seu programa será executado por UM ÚNICO de centenas ou MESMOS de pequenos processadores na placa de vídeo. Isto funciona cerca de 70 (setenta) vezes mais lento do que na CPU. Sim, lento, mas funciona.
Então você pode, com consideravelmente mais esforço, começar a paralisar seu programa. Isto já funciona 4-5 vezes mais lento, ou apenas 2-3 vezes mais rápido do que no processador central.
E para modificar seu ALGORITHM globalmente, para que seja executado em PAIXÕES, repito em PAIXÕES, e não sequencialmente como ensinam em todas as universidades do mundo, essa é uma tarefa difícil.
Vamos deixar claro - é difícil, mas não raro, paralelizar um algoritmo seqüencial usual pelo princípio da Multithreading. É uma coisa. Você recebe 5-10 vezes mais velocidade na GPU da mesma forma. Mas converter o algoritmo seqüencial em um algoritmo de grupo (não tenho palavras melhores em meu vocabulário), para carregar centenas e milhares de processadores GPU e obter a velocidade de 100 vezes como prometido pela nVidia - isto pode ser um problema.
Mas é solvível também. É apenas uma questão de tempo.
Mas há também Crimea, Benderites e assim por diante .....
3. O MetaTrader-4 não tem problemas ao escrever uma DLL para a CUDA.
O problema é que os desenvolvedores de software da nVidia (2500 pessoas) discordam radicalmente do modelo multithreading usado no MetaTrader-4-5. Nvidia mudou fundamentalmente este modelo quando mudaram de CUDA 3.2 para CUDA 4.0+. Além disso, se você começar a perguntar-lhes por que foi assim (como Metatrader-4 e centenas de outros programas multithreaded) e agora é assim, tudo o que você vai ouvir em resposta é "você fundamentalmente entendeu mal nosso kAnstment".
já ouvi dizer que em algum lugar antes.... recentemente.....
4. É muito mais fácil traduzir um novo algoritmo de C para CUDA do que de C para OpenCL genérico diretamente, por isso recomendo este caminho. Ainda mais que hoje a nVidia deve apresentar oficialmente o CUDA-6 no qual, teoricamente, nas novas GPUs Maxwell-series e sob alguns sistemas operacionais será possível reduzir significativamente a quantidade de programação - devido à unificação da memória e à queda das operações de encaminhamento entre a CPU e a GPU.
Bem?
Então?
Ninguém está interessado em nada?
Nem uma única pergunta ou postagem em um ano.
Mas é interessante para Nvidia: ela leu minhas reclamações sobre este e outros fóruns, reuniu seu conselho de artes, esfregou de todas as maneiras possíveis - e decidiu que os comerciantes também são pessoas, e que o terminal comercial também é um programa, e introduziu na última versão da CUDA uma chave especial para o compilador - para criar um programa altamente multi-tarefa na CUDA.
http://devblogs.nvidia.com/parallelforall/gpu-pro-tip-cuda-7-streams-simplify-concurrency/
um fio como
nvcc --default-stream por rosca ./pthread_test.cu -o pthreads_per_thread
Infelizmente, mesmo o Xeon Phi não decolou. E está ainda mais próxima da programação convencional.
Quem precisar de energia nos cálculos universais pode agora obtê-la facilmente sem muita tensão em sistemas de multiprocessadores de uso geral. O número de núcleos nos processadores Intel está crescendo rápido o suficiente.
Por exemplo, nossos servidores têm 40 núcleos cada um, tenho até um computador funcional com 20 núcleos e memória DDR4. Um servidor com 40 núcleos de 3Ghz Xeon bate inequivocamente um Xeon Phi de baixa freqüência com 56 ou mais núcleos sem ter que reescrever uma única linha de código.
Quem precisar de energia nos cálculos de propósito geral pode agora obtê-la facilmente sem muita tensão em sistemas de multiprocessadores de propósito geral. O número de núcleos nos processadores Intel está crescendo muito rapidamente.
Por exemplo, nossos servidores têm 40 núcleos cada um, eu tenho até um computador funcional com 20 núcleos e memória DDR4. Um servidor baseado em Xeon com 40 núcleos em 3Ghz bate inequivocamente um Xeon Phi de baixa freqüência com 56 ou mais núcleos, sem exigir uma única linha de código a ser reescrita.
Você está ligeiramente enganado (2 vezes. Ambos.). Basicamente, eu também costumava pensar assim, especialmente ao entrar na programação da GPU.
(1). A "potência em cálculos universais" em uma UCP hospedeira pode ser facilmente obtida SOMENTE para os algoritmos mais simples. Esse é o ponto de fricção para a maioria dos programadores OpenMP e GPU. Existem centenas de milhões de placas de vídeo CUDA vendidas, mas apenas cerca de 300 programas para isso. Para finanças - apenas cerca de 7-8 (sem contar as coleções de bibliotecas inúteis).
Confira a lista completa no site da nVidia:
http://www.nvidia.com/object/gpu-applications.html?cFncE
(Nosso primeiro EA acelerado por CUDA disponível comercialmente para o terminal comercial MT4 ainda não existe).
Esta lista não mudou durante vários anos.
Por quê? Bem, porque o complexo algoritmo adaptativo, que pode ser facilmente montado a partir de peças em uma UCP hospedeira, acaba por não ser suficiente para programá-lo, ele precisa BREAK. E isso não é uma coisa tão fácil de se fazer por causa do :
a). peculiaridades e limitações do modelo CUDA-OpenCL GPU (núcleos de diferentes tamanhos devem ser executados sequencialmente).
b). qualquer transferência de dados através do barramento PCI entre a GPU e o processador host irá matar todo o ganho de velocidade. E em algoritmos adaptativos complexos, não se pode passar sem eles.
(2). "não exigindo uma única linha de código a ser reescrita" é também apenas para algoritmos simples. A situação é agravada pelo fato de o OpenMP - como uma alternativa real à GPU - funcionar misteriosamente, ou seja, às vezes funciona, e às vezes produz lixo. É uma ilusão que apenas adicionando uma linha pragmática em um só lugar, o algoritmo se paralelizará imediatamente dessa forma. Está longe disso. Em um algoritmo complexo, tais correlações inesperadas ocorrem entre dados e fios paralelos que não podemos fazer sem a construção de um gráfico.
A GPU é um assunto totalmente diferente. Há mais trabalho a ser feito no início, mas o programa SEMPRE funciona corretamente, em termos de tempo. Além disso, um programa reescrito para a CUDA (mesmo sem escrever os grãos) é traduzido em OpenMP ACTIVAMENTE por uma linha de pragmatismo e ESTE funciona. Não faz nenhum sentido traduzi-lo em OpenMP logo em seguida - seria muito mais perspectiva e confiável acrescentar núcleos para CUDA-OpenCL. Surpreendentemente, os núcleos para as GPUs CUDA acabam por ser curtos, claros e confiáveis.
Bem e em termos de velocidade absoluta e confiabilidade - a UCP hospedeira não tem nenhuma chance contra a GPU.
=Os mercados financeiros e forex em particular são uma versão MUITO comprimida de enormes processos ao redor do mundo.
= Por esta razão, um agloritmo para a previsão de preços não pode ser simples. Portanto, atualmente, ela tem que ser adaptável e figurativamente falando estatística.
= Então, sem simulação e feedback adaptativo em um algoritmo tão bom, não há para onde ir.
=Portanto, se a UCP hospedeira ainda pode ser útil para fazer pedidos (ou seja, sua velocidade ainda é suficientemente alta), é quase impossível trabalhar sem a GPU para fins de teste e otimização.
Você declarou que eu estava errado duas vezes e depois, sob o pretexto de prova, entregou uma prova completamente estranha.
Estou certo sobre o seguinte (que foi declarado imediatamente):
Eu não mencionei o OpenMP de forma alguma. Do meu ponto de vista, o OpenMP é uma "bala de prata para os maricas". Se você estiver lutando por um desempenho real, livre-se das bobagens do OpenMP e escreva à mão inicialmente o código multi-tarefa correto/nativo, trace um perfil e empurre-o ao máximo.
Você mesmo já provou que não há software de computação GPU suficiente. A maioria dos programas de GPU é apenas o mais simples dos casos, incluindo crackers de senhas e mineiros bobos (jogos que não devem ser discutidos).
Minha opinião é que as CPUs e a infra-estrutura subjacente estão evoluindo rapidamente o suficiente para realmente superar as GPUs em desempenho no mundo real em aplicações do mundo real. Há 3-4 anos, você poderia ter acreditado no potencial das GPUs, mas agora isso se tornou claro.
Você declarou que eu estava errado duas vezes e depois, sob o pretexto de prova, entregou uma prova completamente estranha.
Estou certo sobre o seguinte (que foi declarado imediatamente):
Eu não mencionei OpenMP de forma alguma. Do meu ponto de vista, o OpenMP é uma "bala de prata para os maricas". Se você estiver lutando por um desempenho real, deixe de lado o absurdo do OpenMP e escreva à mão inicialmente o código multi-tarefa correto/nativo, trace um perfil e empurre-o ao máximo.
Você mesmo já provou que não há software de computação GPU suficiente. A maioria dos programas de GPU são apenas os casos mais simples, incluindo crackers de senhas e mineiros bobos (jogos que não devem ser discutidos).
Minha opinião é que as CPUs e a infra-estrutura subjacente estão evoluindo rapidamente o suficiente para realmente superar as GPUs em desempenho no mundo real em aplicações do mundo real. Há 3-4 anos, você poderia ter acreditado no potencial das GPUs, mas agora isso se tornou claro.
1. extrapolando a taxa de crescimento dos núcleos a partir da CPU hospedeira, é improvável que nos próximos anos seu número atinja 3000 núcleos como o que uma boa placa de vídeo tem HOJE. E cada núcleo de placa de vídeo funciona a cerca de 1GHz. Portanto, seria impossível para um processador anfitrião competir com a GPU. Mas isso assumindo que há um bom programa que pode não só e não apenas trabalhar esses 3000 núcleos, mas também ATUALIZAR todas as armadilhas da arquitetura de hardware da GPU de hoje. E a velocidade de vídeo da memória GDDR5 na placa de vídeo média hoje é de cerca de 150 GBytes/segundo. Todos os tipos de memória DDR4 (25 GB/seg.) ainda têm um longo caminho a percorrer.
Como um processador host pode competir com 40-60 núcleos, mesmo a 4GHz e 25Gb/s de memória?
2. Todos os tipos de exóticos como Phi não têm o suporte e a versatilidade necessários como placa de vídeo. Portanto, eles se extinguiram.
3. Sobre a necessidade de programação multithreading direta - sim, concordo com você, mas é uma tarefa árdua . Escrever um complexo NOVO algoritmo adaptativo de uma só vez em uma versão multi-tarefa é muito difícil. E você tem que trabalhar por evolução, por assim dizer. Além disso, não preciso lhe dizer o quão mal o Windows lida com multi-tarefas quando fica realmente cheio (há todos os tipos de atrasos). É por isso que até mesmo o sistema operacional veio com as chamadas fibras - fios simplificados.
Conclusão: Não há nada mais barato, mais promissor e confiável do que a GPU.