Mais uma vez, sobre multithreading
Caros Desenvolvedores, pesquisei sobre o tema da multithreading e encontrei uma frase que disse que não ia acrescentar funções que criassem e gerissem fios na MQL5. Foi dito há mais de um ano e meio atrás. Será que as suas opiniões mudaram desde então?
Se ainda não se quer preocupar com isso, porque não deixar os utilizadores implementá-lo eles próprios? Para isso, precisamos de um ponteiro de função. Que tal acrescentar uma característica deste tipo? I.e. GetPointer(myfunc)
Além disso, se quiser explicar por que razão não implementou a multi-tarefa na MQL5, por que razão viu quaisquer dificuldades particulares? Ou talvez tenha sido apenas uma questão de princípio?
Permitam-me que vos recorde que este já não é o ano 2000 e que os processadores com vários núcleos já há muito se tornaram a norma para todos, o número de núcleos só irá aumentar todos os anos. Agora são 4, dentro de alguns anos serão 6-8, etc. E não permite aos utilizadores a utilização adequada do processador com o programa que estão a executar.
Qual é o objectivo das suas comparações de velocidade constante entre MQL e C++ então, se está apenas a comparar trabalho num só fio? Afinal de contas, nenhum programador C++ razoável penduraria uma tarefa de recursos intensivos num único fio quando existem vários processadores que podem aumentar o desempenho muitas vezes. É por isso que todos os seus testes têm pouca relação com a vida real. Dentro de alguns anos o núcleo do processador crescerá até 10 núcleos e ainda se orgulhará dos seus testes de MQL com uma única rosca?
Quanto à utilização do OpenCL, isso é xamanismo, especialmente na forma como é implementado aqui - através da linha de texto. Então depura o seu código noutro lugar, e depois copia-o para MQL5... Que circo! Seria então mais fácil implementar tudo isto numa DLL e importá-la. Além disso, muito poucas pessoas gostariam de escrever um programa em várias línguas.
Multithreading em MQL5 ainda está disponível, mas ao contrário de C++, é implementado como um ambiente de execução virtual chamado gráfico.
Cada gráfico está a correr num fio separado. Isto é feito para evitar a sincronização problemática de fios, acesso a dados e outras questões que surgem durante a comunicação entre fios.
Muito feio? Sim, mas para o utilizador de massa (que já se queixa da complexidade da língua) é a coisa certa.
No que diz respeito ao OpenCL, trata-se de uma questão à parte. Nem sequer estava nos planos de desenvolvimento da plataforma. No início, os utilizadores do fórum avançado atraíram o interesse dos criadores sobre este tópico, mas a resposta oficial foi "não e não será". Mas então a liderança do MQ mudou a sua raiva por misericórdia(obrigado Ilyaz).
Sobre Dll: MQ considera-os potencialmente perigosos, pelo que sempre que possível para os evitar tentam implementá-los, especialmente para os serviços públicos. Mas não os proíbe em geral, porque os programadores escrevem não só para o público, mas também para os interlocutores.
Em suma, parece ser pura afirmação teórica.
Não há nada de errado com o multithreading e a utilização plena de processadores no terminal. Veja quantos fios estão a correr no terminal e como o número de fios muda no tempo. Os princípios da multi-tarefa foram explicados e demonstrados muitas vezes. Por exemplo, como funcionam os tópicos independentes de recálculo de indicadores, recálculo de símbolos, paginação de dados de gráficos e funcionamento independente de todos os Expert Advisors e scripts.
A fim de paralelizar os cálculos de qualquer coisa, deve primeiro perceber que apenas uma pequena parte da matemática pode ser paralelizada.
Veja-se o testador multi-core, MQL5 Cloud Network e OpenCL. Já há muito tempo que estamos à frente da curva, especialmente na computação em nuvem. Neste momento, ligue a MQL5 Cloud Network no seu testador e obtenha até 14.000 CPUs para o ajudar:
Também não parece saber nada sobre o OpenCL. A apresentação do código do programa na forma de código fonte a ser enviado para o compilador OpenCL é a forma habitual e padrão de trabalho. Tenha em mente que diferentes manipuladores do OpenCL (Ndivia, AMD, Intel, etc.) têm de obter o código e retrabalhá-lo para si próprios.
- cloud.mql5.com
O que é multithreading no MetaTrader 5:
Basta clicar no teste para obter instantaneamente 5.743 agentes/CPU's para trabalhar e executar 381.468 passagens no optimizador em 6 minutos. Cada passe demorava entre 1 e 2 segundos a correr. Se eu tivesse feito o teste no meu computador com 8 núcleos, teria passado 800 a 1600 minutos em vez de 6 minutos (381468 / 8 = 47683 segundos = 794 minutos).
E para além de carregar no botão Start, não tive de fazer mais nada. Alguns skynet levantaram-se, sincronizaram sozinhos toda a história gráfica necessária, distribuíram a tarefa a milhares de computadores em todo o mundo e trabalharam-nos em massa.
Bem-vindo à realidade...
Renat,
pergunta sobre a criação de fios dentro da MQL5 Expert Advisor.
Renate,
A questão sobre a criação de roscas dentro da MQL5 Expert Advisor.
Estou ciente disso.
Só não escrevi que é melhor não falar de multithreading a uma pessoa que não compreende porque não há multithreading numa linguagem computacional aplicada. Implementámos toda a infra-estrutura multi-tarefa do terminal de uma forma completa e eficaz.
A verdadeira multi-tarefa é necessária em locais onde se possa realmente paralelizar tarefas. Este é um testador. E este é o local onde o implementamos de tal forma que muitas pessoas estão longe de compreender a qualidade, o controlo e o volume do trabalho realizado.
O meu exemplo com claude é uma simples prova da qualidade e do nível de elaboração da tarefa.
Sim, Renat, não leste cuidadosamente o meu post. Não estamos a falar de multithreading de MT5, mas de multithreading de MQL5. Não podemos criar estes fios num programa em execução por nós próprios. A abertura do programa de um novo gráfico com um indicador é uma dança de pandeiro, não uma solução.
É espantoso, tem feito muitas coisas desnecessárias na MQL5, considerando um utilizador em massa. E, no que me diz respeito, o seu foco está principalmente nos bonecos, não nos programadores alfabetizados. Daí o monte de restrições, a impossibilidade de trabalhar directamente com a memória, etc. Então a questão é: porque é que os bonecos precisam, por exemplo, de aulas?
Se posiciona o seu produto não só para bonecos, porque não pode dar aos programadores experientes uma oportunidade de utilizar eficazmente os recursos do sistema?
A falta de multithreading não será compensada com nenhuma classe. Por muito inteligente que um programa possa parecer, mas se utiliza os recursos do sistema de forma ineficiente, é uma vergonha para tudo isto. Talvez tenha esquecido, na busca da inovação, que a linguagem MQL se destina principalmente à escrita de programas comerciais e analíticos, e não à programação para fins de programação. Portanto, a velocidade e a eficácia do programa, em vez da velocidade de escrita do código, deve ser a primeira prioridade. Porque o trabalho com dados de grandes dimensões é esperado a priori.
Penso que as capacidades da MQL4 serão bastante suficientes para a maioria dos utilizadores. As únicas coisas que faltavam eram o suporte de estruturas, ponteiros para variáveis e ponteiros para funções (ou suporte integrado de funções de callback). E isso é tudo. Com este arsenal, é possível criar qualquer programa que funcione muito eficazmente, criar o número necessário de fios, callbacks, etc.
carne, sem ofensa, mas com este nível de compreensão das questões no jardim-de-infância.
Li tudo cuidadosamente, mas não tenho a possibilidade de dar uma educação em larga escala. Tenho 11 anos de experiência nas línguas MQL/MQL2/MQL4/MQL5.
Não se trata de MT5 multithreading de todo, trata-se de MQL5 multithreading. Não podemos criar estes fios no programa em execução por nós próprios. E a abertura do software de um novo gráfico com um indicador é, concordará, uma dança de pandeiro, não uma solução.
O mais surpreendente é que tenha feito tantas coisas desnecessárias na MQL5, se tivermos em conta um utilizador em massa.
Se levar um único utilizador, pode haver muitas coisas desnecessárias. E quando se começa a alargar os horizontes e são necessárias características adicionais, acontece que, pelo contrário, algo já está aqui e algo está em falta.
A MQL5 ainda se encontra em desenvolvimento. Algo de novo está a ser acrescentado pouco a pouco. Embora, claro, também haja desvantagens, por exemplo, não é possível criar os seus próprios eventos, não há manipuladores de excepções e multithreading. Espero que tudo isto saia um dia? Mas duvido que tudo isto venha a ser implementado amanhã.
Se realmente se quiser, a multi-tarefa está disponível para testar agentes também no OpenCL. Não é inteiramente conveniente, mas ainda assim está lá e pode fazer o paralelismo de tarefas.
carne, sem ofensa, mas com este nível de compreensão das questões no jardim-de-infância.
E você diz que não é o padrão da empresa))
Se forem feitas perguntas, isso significa que as respostas não estão à superfície.
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Você concorda com a política do site e com os termos de uso
Se ainda não se quer preocupar com isso, porque não deixar os utilizadores implementá-lo eles próprios? Para isso, precisamos de um ponteiro de função. Que tal acrescentar uma característica deste tipo? I.e. GetPointer(myfunc)
Além disso, se quiser explicar por que razão não implementou a multi-tarefa na MQL5, por que razão viu quaisquer dificuldades particulares? Ou talvez tenha sido apenas uma questão de princípio?
Permitam-me que vos recorde que este já não é o ano 2000 e que os processadores com vários núcleos já há muito se tornaram a norma para todos, o número de núcleos só irá aumentar todos os anos. Agora são 4, dentro de alguns anos serão 6-8, etc. E não permite aos utilizadores a utilização adequada do processador com o programa que estão a executar.
Qual é o objectivo das suas comparações de velocidade constante entre MQL e C++ então, se está apenas a comparar trabalho num só fio? Afinal de contas, nenhum programador C++ razoável penduraria uma tarefa de recursos intensivos num único fio quando existem vários processadores que podem aumentar o desempenho muitas vezes. É por isso que todos os seus testes têm pouca relação com a vida real. Dentro de alguns anos o núcleo do processador crescerá até 10 núcleos e ainda se orgulhará dos seus testes de MQL com uma única rosca?
Quanto à utilização do OpenCL, isso é xamanismo, especialmente na forma como é implementado aqui - através da linha de texto. Então depura o seu código noutro lugar, e depois copia-o para MQL5... Que circo! Seria então mais fácil implementar tudo isto numa DLL e importá-la. Além disso, muito poucas pessoas gostariam de escrever um programa em várias línguas.