Programação assíncrona e multi-tarefa em MQL - página 23
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
Explique-me o que há de errado com o opencl. O terminal implementa a capacidade de escrever código opencl, e isto é multithreading. Quero entender por mim mesmo quais são as diferenças da multi-tarefa que está aqui escrita e esta característica.
Não há placas de vídeo nos servidores VPS, ou é muito pouco rentável se elas forem ))
Mesmo a maioria dos usuários em placas de vídeo locais, não suportam opencl))
Para não mencionar a complexidade de escrever um código adequado para opencl.
Sim, há uma opção, mas para um círculo muito pequeno de pessoas.
As placas de vídeo não estão disponíveis em servidores VPS, ou muito pouco rentáveis se estiverem disponíveis ))
Mesmo a maioria dos usuários em um site local não suporta opencl))
Para não mencionar a complexidade de escrever um código adequado para opencl.
Opção sim, existe, mas para um círculo muito estreito de pessoas.
Em um processador opencl, ele também funciona. Você simplesmente seleciona o dispositivo que executará o código. Não se trata apenas de tecnologia de placas de vídeo. Nos servidores, eu sei que há problemas com os cartões de vídeo.
Mas eu não sabia que o opencl também funciona em CPUs. Ainda não consegui chegar ao artigo de Renat para ler sobre o opencl.
Também li aqui um post sobre opencl, mas não consigo colocar todos os programadores em opencl, os métodos padrão de tarefas da caixa parecem mais utilizáveis.
Então, o opencl funciona em qualquer processador? Ou também depende do modelo?
Mas eu não sabia que o opencl também funciona em processadores. Ainda não consegui chegar ao artigo de Renat para ler sobre o opencl.
Também li aqui um post sobre opencl, mas você não pode colocar todos os programadores em opencl, os métodos padrão de tarefas fora da caixa parecem mais utilizáveis.
Então, o opencl funciona em qualquer processador? Ou também depende do modelo?
Parece que sim, deve funcionar na Intel e, pelo contrário, você só precisa instalar drivers. Experimentei na amd e funcionou.
Acontece que, mesmo assim, algum grau de dependência depende tanto do modelo do processador quanto dos motoristas.
Isto pode não ser adequado para todos, por exemplo, aqueles que distribuem (vendem) seu trabalho.
Há pessoas que se preocupam com a portabilidade do programa, na minha opinião, ele também é um parâmetro importante.
O opencl pode trabalhar com dlls personalizadas?
ou seja, chamar funções exportadas de forma assíncrona da dll?
Se tivéssemos uma classe padrão para trabalhar com tarefas, poderíamos chamar nossas próprias funções a partir da dll de forma assíncrona.
Ou seja, a funcionalidade regular é muito mais utilizável e mais acessível em código escrito.
Pena que não tenhamos ouvido do chefe do departamento de transporte - que tarefa específica você quer implementar multi-tarefas? Desenhe um diagrama de blocos simples da solução proposta.
Você está tentando teimar em uma tarefa MKL para a qual ela não foi originalmente destinada. Em uma palavra, de modo algum. Existem soluções prontas - veja a ZeroMQ que tem API para quase todos os JDs. Além disso, o gentil homem Ding Li desenvolveu uma biblioteca para a ZeroMQ usando com MQL4/5 com um conjunto de exemplos. Favor ler o tópico do fórum sobre este tópico com exemplos práticos de código.
Por que você (o iniciador do tópico) está empurrando água em uma panela? Ou você também está vinculado ao mercado?
Boa sorte.
O opencl sabe como trabalhar com dlls personalizadas?
Isto é, chamar funções exportadas de forma assíncrona da dll ?
Havia uma classe interna para trabalhar com tarefas, você poderia chamar suas funções a partir da dll de forma assíncrona também.
Ou seja, a funcionalidade regular é muito mais utilizável e mais acessível em código escrito.
Chame a função DLL. Você cria uma thread na DLL e transfere dados para ela, desconecta a thread e a esquece - ela terminará por conta própria após completar sua tarefa. Quando você desconecta o fio na DLL, o fio terminal é liberado. Todo o processo leva, creio eu, menos de um milissegundo. A julgar pelo fato de que mesmo sem desconectar o fio, o processo de escrita no banco de dados é de 4-5 ms. Bem, e 60 ticks/min é suficiente para não ficar triste com a chamada assíncrona do terminal.
Pena que não tenhamos ouvido do chefe do departamento de transporte - que tarefa específica você quer implementar multi-tarefas? Desenhe um diagrama de blocos simples da solução proposta.
Você está tentando teimar em uma tarefa MKL para a qual ela não foi originalmente destinada. Em uma palavra, de modo algum. Existem soluções prontas - veja a ZeroMQ que tem API para quase todos os JDs. Além disso, o gentil homem Ding Li desenvolveu uma biblioteca para a ZeroMQ usando com MQL4/5 com um conjunto de exemplos. Favor ler o tópico do fórum sobre este tópico com exemplos práticos de código.
Por que você (o iniciador do tópico) está empurrando água em uma panela? Ou você também está vinculado ao mercado?
Boa sorte.
Eu tento não usar soluções de terceiros.
Já encontrei uma solução para meu problema de rede, então tudo o que tenho que fazer é estudá-la, aplicá-la e não foder meus miolos.
Mas há programadores aqui que também precisam de chamadas sem bloqueio e assíncrono.
É por isso que sugeri implementar esta funcionalidade na entrega de idiomas padrão. E cabe aos desenvolvedores, o principal é a idéia, e é sensata.
Por que você acha que o terminal não foi projetado para implementar o EventLoop? Especialmente a partir da palavra go...
Que algoritmo é usado para executar agentes locais? Provavelmente em uma piscina de fios, certo? Quem os administra, distribui as tarefas?
Então, o terminal já possui tal algoritmo, por que não usá-lo para ampliar sua funcionalidade?
Dar aos programadores um modo assíncrono de escrita de código.
Sou a favor da idéia, se ninguém precisa dela de forma assíncrona, bem, o que posso dizer, só lamento que muitos estejam presos em um único fio.
Chame a função DLL. Você cria uma thread na DLL e transfere dados para ela, desconecta a thread e a esquece - ela completa sua tarefa por si só. Quando você desconecta o fio na DLL, o fio terminal é liberado. Todo o processo leva, creio eu, menos de um milissegundo. A julgar pelo fato de que mesmo sem desconectar o fio, o processo de escrita no banco de dados é de 4-5 ms. Bem, 60 ticks/s é suficiente para não ficar triste com a chamada assíncrona do terminal.
Aqui, obrigado por outra idéia, posso escrever dll de acordo com artigos locais, mas infelizmente eles não descrevem o procedimento do ponto de entrada, inicialização,alocação de memória, criação de threads, etc.
Não consigo encontrar nenhuma literatura sobre este assunto, não consigo encontrar como lidar corretamente com o ponto de entrada. Se houver alguma informação sobre este assunto, por favor me avise.
Ou se você puder me ensinar, terei prazer em aceitar o conhecimento.
Não estudei como programador, tudo o que aprendi eu mesmo, portanto, não me chute o chicote ))
Explique-me o que há de errado com o opencl. O terminal implementa a capacidade de escrever código opencl, e isto é multithreading. Quero entender por mim mesmo quais são as diferenças da multi-tarefa que está aqui escrita e esta característica.