OpenCL: testes internos de implementação em MQL5 - página 4
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
Se bem entendi, 1 GPU é um agente muito poderoso? É possível desactivar os agentes CPU nesse caso (devido à sua baixa velocidade em relação ao vídeo)? E mais uma vez: é possível ter duas ATIs sem fogo cruzado?
A AMD desencoraja fortemente a utilização de Crossfire para OpenCL - uma vez que com Crossfire existem de facto duas GPUs mas o condutor TEM de dividir UM trabalho gráfico entre elas. Pelo contrário, para o OpenCL 1.1, ainda não há maneira de o próprio condutor da placa de vídeo dividir um único trabalho OpenCL entre as duas GPUs (ver acima).
O mesmo para a nvidia SLI.
Como é que a inclusão do OpenCL irá afectar o custo do cálculo na nuvem?
O custo de um agente com GPU será superior ao custo de um agente sem GPU, uma vez que o tempo estimado para o primeiro agente será significativamente mais curto?
Dado que apenas um agente na máquina local receberá uma GPU, verifica-se que o custo de diferentes agentes na mesma máquina local será diferente (e pré-calculado)?
Como é que a inclusão do OpenCL irá afectar o custo da computação na nuvem?
O custo de um agente com GPU será superior ao custo de um agente sem GPU porque o tempo de computação do primeiro agente será significativamente mais curto?
Dado que apenas um agente na máquina local receberá GPU, verifica-se que o custo de diferentes agentes na mesma máquina local será diferente (e pré-calculado)?
Por defeito, o terminal/agente escolhe o dispositivo GPU mais potente pela sua característica definida no arranque. Até agora, não há ideia de seleccionar dispositivos da MQL5 - isto só irá complicar o código e levar a erros adicionais.
Em vez disso, há uma ideia mais bonita na forma de atribuição automática de cada GPU físico para separar os agentes, o que permitirá utilizá-los em todo o seu potencial.
Digamos que temos um EX5 (usando OpenCL) que optimiza 20 vezes mais rápido em agentes com GPU do que sem GPU.
Executamos a optimização na nuvem. É evidente que é mais benéfico (em termos de tempo necessário) executar a optimização em primeiro lugar sobre os agentes que têm uma GPU física. Dando-lhes a maior parte das opções de enumeração. É equivalente ao facto de o seu RP ser 20 vezes superior. MAS, a sua RP sem utilizar GPU é a mesma. Ou seja, é necessário introduzir um novo cálculo PR, PR_gpu.
"Quando uma tarefa é executada, o trabalho realizado pelo agente de teste é contado como o produto do seu RP pelo Tempo gasto. "
Decorre desta fórmula que se não houver PR_gpu, o custo de toda a optimização na nuvem com GPU será mais barato do que sem GPU.
Infelizmente, a introdução de um cálculo alternativo de PR - single test pass do ficheiro EX5 optimizado contém um grande número de armadilhas, devido às quais é impossível utilizá-lo universalmente.
Decorre desta fórmula que se não houver PR_gpu, o custo de toda a optimização na nuvem com GPU será mais barato do que sem GPU.
Infelizmente, a introdução de um cálculo alternativo de PR - um único teste de aprovação de um ficheiro EX5 optimizado contém um enorme número de armadilhas que tornam impossível a sua utilização universal.
sem entrar em detalhes, o que não sei, se as relações públicas reais não forem revistas, então não vale a pena virar-se para a nuvem com a GPU
Além disso, se introduzir um novo conceito, e você o adora) Por exemplo, se está a introduzirum novo conceito, o que gosta de fazer, então é melhor defini-lo imediatamente ou adivinhar que se trata do lado do utilizador neste caso.
Actualmente PR = Const Koef / tempo necessário para completar a tarefa de referência.
O custo da optimização é igual ao número de tarefas de referência que poderiam ser calculadas no tempo em que a optimização durou. Ou seja, o custo do cálculo não depende de como a nuvem aloca tarefas entre os agentes. Mas a duração final da optimização depende de uma atribuição adequada, que é a métrica mais importante.
É evidente que a nuvem atribui tarefas aos agentes em proporção ao PR pré-calculado para reduzir o tempo de cálculo (mas não o custo - CONST).
As tarefas do OpenCL serão obviamente atribuídas primeiro aos agentes com a GPU certa.
o custo do cálculo não depende de como a nuvem aloca tarefas entre os agentes.
Infelizmente, a introdução de um cálculo alternativo de PR - uma única execução de teste de um ficheiro EX5 optimizado - contém um número enorme de armadilhas que tornam impossível a utilização universal.
Como o custo para o optimizador é sempre constante, mas a sua duração depende fortemente de um cálculo PR adequado (para a tarefa dada), talvez devêssemos introduzir o optimizador para introduzir o seu código EX5 PR_calculate na sua consciência. Onde o optimizador, com base nas características do seu algoritmo, definirá o RP distributivo mais adequado para a sua tarefa.
Por exemplo, se a tarefa for puramente computacional, a ênfase em PR_calculate será dada à matemática.
Se a tarefa tratar de enormes quantidades de dados, a ênfase será na velocidade de tratamento da memória.
Se a GPU for usada um pouco - exiba-a no seu PR_calculate.
Se a GPU for utilizada em todo o EX5 - escreva um calaculado PR_ adequado (com utilização apropriada da GPU).
Sob este esquema, aqueles que alugam energia à nuvem não perdem nada, e aqueles que utilizam a energia da nuvem têm a oportunidade de acelerar significativamente os seus cálculos.
Se o PR_calculate não for especificado, é utilizada a tarefa de referência universal já aceite.
P.S. PR_calculate é usado apenas para atribuir tarefas na nuvem. Para o cálculo de custos, ainda se utiliza o mesmo antigo PR.
P.P.S. Existem, naturalmente, armadilhas - PR_calculate precisa de ser pré-calculado em todos os agentes livres. PR_calculate pode ser escrito por engano - looped. Assim, durante o tempo que leva a calcular o PR_calculate, também é necessário cobrar dinheiro de acordo com o esquema clássico de PR. Etc.
Como o custo para o optimizador é sempre constante, mas a sua duração depende fortemente do cálculo adequado (para a tarefa dada) de PR, talvez valha a pena introduzir na consciência da entrada do optimizador o seu código EX5 PR_calculate. Onde o optimizador, com base nas características do seu algoritmo, definirá o RP distributivo mais adequado para a sua tarefa.