OpenCl e as ferramentas para ele. Revisões e impressões. - página 6
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
Suspeito que era isso que a Mischek estava gritando há cerca de um mês.
Vejo a aplicação do OpenCL tanto em testes pesados quanto em cálculos paralelos muito intensos em tempo real.
Até agora eu não preciso disso (todos os cálculos pesados estão no meu init() do indutor), mas vale a pena mencionar.
Alexey, tenho o mesmo problema: tento arrastar algo para o interior, e depois para o tempo real :)
Meu cérebro está voltado para uma linguagem de procedimento. O OOP é desejável, mas não é nativo.
Para aqueles fanáticos ventiladores B4 que não visitam mql5.com : OpenCL: testes internos de implementação em MQL5
Obrigado, eu pessoalmente não vi isso. Só que não é tão simples assim.
Além disso, Rinat está confundindo as pessoas: OpenCL 1.0 pode funcionar bem com flutuação dupla, é uma "opção pública" apoiada por todos os fabricantes - MAS NÃO PARA TODAS AS MAPAS VELHAS.
http://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/
"Opcional Dupla Precisão e Meio Ponto Flutuante
OpenCL 1.0 adiciona suporte para dupla precisão e meio ponto flutuante como extensões opcionais. O duplo tipo de dados deve confirmar para o formato de armazenamento de dupla precisão IEEE-754.
Uma aplicação que queira usar o dobro precisará incluir o #pragma OPENCL EXTENSION cl_khr_fp64 : habilitar a diretiva antes que qualquer tipo de dado de dupla precisão seja declarado no código do kernel. Isto ampliará a lista de tipos de dados vetoriais e escalares incorporados para incluir o seguinte:.....".
Pode funcionar no Testador de Estratégia mas não funcionará no OpenCL 1.0 Expert Advisor não porque, como diz Rinat, "não há flutuação dupla lá" mas, como já mencionei, porque não há rosqueamento seguro no OpenCL 1.0 e não há rosqueamento no MT4-5.
O OpenCL (e a CUDA) é confuso em geral. O que você quer? Afinal, os engenheiros de ferro e de rádio se propuseram a mudar o conceito de programação. Eles têm uma mentalidade de ferro.
Haverá também um problema com a chamada "PLATFORM SELECTION": o programa, ou seja, MT ou DLL ou Expert Advisor, DEVE, apenas DEVE escolher a plataforma (AMD, Nvidia, Intel), que pode ser várias diferentes que executarão o conector OpenCL, e depois selecionar manualmente DEVICE se seu computador estiver executando Multi-GPU. A auto-seleção da plataforma no OpenCL ainda não está lá. Rinat fala sobre "auto-selecionar os mais poderosos", mas não sei como é. No exemplo mostrado ali, não há seleção de plataforma e nem de dispositivo (GPU, CPU).
Além disso, ainda não existe uma paralelização automática de tarefas OpenCL em várias GPUs ou em GPU+CPU no padrão. Digamos assim: em algumas versões de seus drivers/SDK AMD costumavam introduzir esse autoprovisionamento, mas tinham alguns problemas e por enquanto a AMD desligou esse recurso.
Conclusão: para desenvolver e habilitar programas OpenCL c/o MT4-5 requer algum esforço manual e, portanto, não funcionará automaticamente ou por "recompilação com opção". O que, por sua vez, está repleto de barracas em operação no mundo real. Será um trabalho sutil e, o que é importante, eu me permito repetir, infelizmente é a PROGRAMAÇÃO JUÍZIA ORIENTADA, o que é errado. A depuração de programas paralelos para a CUDA ou OpenCL acabou sendo muito mais difícil do que os revolucionários do ferro assumiram. A Nvidia até cancelou sua conferência CUDA 2011 no outono - devido a problemas com os motoristas e muitas reclamações sobre a paralisação da depuração. Então, eles adicionaram mais 1000 novos recursos ao último Toolkit - e o que fazer com ele se os programas mais simples nem rodam ou rodam com interrupções? Afinal, eles não mencionaram sequer metade do mecanismo interno do OpenCL ou CUDA em suas ferramentas descritivas.
A velocidade da GPU (em GigaFLOPS) de uma placa de vídeo suspensa devido à compatibilidade de driver ou software é zero.
Obrigado, não o vi pessoalmente. Só que não é tão simples assim.
....Não é bem essa a questão. Você pode escrever em estilo processual em cinco.
joo: E , estou desanimado com este fato, akhtung! - MQL4 chamando dll funciona mais rápido que MQL5 chamando a mesma dll.
Isto é o que é tão alarmante.
Eles poderiam ter desenvolvido suporte nativo para OMP em MQL5. Seria fácil e barato para o codificador, e não há necessidade de escrever nenhuma dll.
Mas este enxame de abelhas numa linguagem de programação de ferro incompleta... ainda não me inspira exatamente. Bem, sim, uma aceleração centenária em alguns casos é grande, mas em termos de cultura de programação é um passo atrás.
Há muita confusão no OpenCL (e na CUDA) em geral. O que você quer? Afinal, os engenheiros de ferro e de rádio se propuseram a mudar o conceito de programação. Eles têm uma mentalidade de ferro.
Haverá também um problema com a chamada "PLATFORM SELECTION": o programa, ou seja, MT ou DLL ou EA especializado, DEVE, basta escolher a plataforma (AMD, Nvidia, Intel), que pode ser várias em seu computador e na qual o conector OpenCL estará rodando, e então selecionar manualmente DEVICE se seu computador estiver rodando Multi-GPU. A auto-seleção da plataforma no OpenCL ainda não está lá. Rinat fala sobre "auto-selecionar os mais poderosos", mas não sei como é. No exemplo mostrado ali, não há seleção de plataforma e nem de dispositivo (GPU, CPU).
Além disso, ainda não existe uma maneira padrão de paralelizar automaticamente tarefas OpenCL através de várias GPUs ou através de GPU+CPU. Digamos assim: em algumas versões de seus drivers/SDK, a AMD costumava implementar essa autoparalelização, mas havia problemas e a AMD até agora a desligou.
Conclusão: para desenvolver e habilitar programas OpenCL c/o MT4-5 requer algum esforço manual e, portanto, não funcionará automaticamente ou por "recompilação com opção". O que, por sua vez, está repleto de barracas em operação no mundo real. Será um belo trabalho e, o que é importante, eu me permito repetir, infelizmente é a PROGRAMAÇÃO JUÍZIA ORIENTADA, o que é errado. A depuração de programas paralelos para a CUDA ou OpenCL acabou sendo muito mais difícil do que os revolucionários do ferro assumiram. A Nvidia até cancelou sua conferência CUDA 2011 no outono - devido a problemas com os motoristas e muitas reclamações sobre a paralisação da depuração. Então, eles adicionaram mais 1000 novos recursos ao último Toolkit - e o que fazer com ele se os programas mais simples nem sequer rodam ou funcionam com interrupções? Afinal, eles não mencionaram sequer metade do mecanismo interno do OpenCL ou CUDA em suas ferramentas descritivas.
A velocidade da GPU (em GigaFLOPS) de uma placa de vídeo suspensa devido à compatibilidade de driver ou software é igual a zero.
Não é bem essa a questão. Você pode escrever em estilo processual também no 5.
Mas isto é alarmante.
Eles poderiam ter desenvolvido suporte nativo para OMP em MQL5. É simples e sereno, nenhuma dll tem que ser escrita.
Mas este enxame de abelhas em uma linguagem de programação de hardware incompleta... ...não parece muito excitante. Sim, uma aceleração centenária em alguns casos é grande, mas em termos de cultura de programação é um passo atrás.
Também me deparei com fatos quando o mql4 funciona mais rápido que o MQL5. Na maioria dos casos, ela se manifesta em operações matemáticas otimizadas pelo programador.
Mas eu acho que este não é o problema principal - usando o OpenCL MQ eles tomaram um caminho que corre paralelo ao caminho de programação principal - talvez até agora isto exija um passo atrás, mas no desenvolvimento futuro da tecnologia informática veremos sistemas escaláveis integrados onde já dependerá do código se o processamento seqüencial ou paralelo é usado.
Portanto, o caminho é bem certo. Embora atualmente não existam tantos algoritmos que exijam a implementação de uma abordagem paralela, mas sim porque o pensamento matemático não tinha equipamentos para a implementação de cálculos paralelos e, portanto, não havia necessidade de criar tais algoritmos.
Alexey, pense apenas em um fato, todas as descobertas matemáticas foram feitas há 200-300 anos, nos últimos 100 anos o pensamento matemático era apenas o polimento do que é. Foi apenas a descoberta da NS que criou a demanda por cálculos paralelos. Nos próximos 100 anos, os algoritmos serão substancialmente paralelos. E você, entre outros, pode inventar um deles.
Eu também vi fatos quando o mql4 é mais rápido que o MQL5. Isto é mais freqüentemente visto em operações matriciais otimizadas pelo programador.
Mas acho que este não é o problema principal - ao entrar no OpenCL MQ tomamos um caminho que corre paralelo à estrada principal de programação; talvez até agora isto exija um passo atrás, mas no desenvolvimento futuro da tecnologia de computadores veremos sistemas escaláveis integrados onde já dependerá do código se o processamento seqüencial ou paralelo é usado.
Portanto, o caminho é bem certo. Embora atualmente não existam tantos algoritmos que exijam a implementação de uma abordagem paralela, é antes porque o pensamento matemático não tinha equipamentos para a implementação de cálculos paralelos e, portanto, não havia necessidade de criar tais algoritmos.
Alexey, pense apenas em um fato, todas as descobertas matemáticas foram feitas há 200-300 anos, nos últimos 100 anos o pensamento matemático era apenas o polimento do que é. Foi apenas a descoberta da NS que formou a demanda por cálculos paralelos. Nos próximos 100 anos, os algoritmos serão substancialmente paralelos. E você, entre outros, pode inventar um deles.
Não, afinal de contas você não está completamente desesperado. :)
Hi.
MQ são bons, eles não tiveram medo de lidar com tal dor (para eles) como a introdução de suporte para cálculos de GPU. A dor, antes de tudo, está ligada ao fato de que a introdução de tecnologias fundamentalmente novas (quaisquer) reduz a confiabilidade e a tolerância a falhas da plataforma como um todo, a princípio. Mas eles entendem perfeitamente que o futuro pertence à computação paralela e mais cedo ou mais tarde teriam que fazer algo nessa direção (o primeiro passo já foi dado - a nuvem).
PS Olá Nikolai. Por que você desapareceu? - Largue-me uma linha.
Isto não é um fato como não é. O desenvolvimento qualitativo da matemática nunca foi interrompido.
E cálculos paralelos não são necessários apenas pela NS, há tarefas mais mundanas - digamos, codificação ou renderização em vídeo.
Mas o vetor geral do movimento MQ é certamente encorajador.