Erros, bugs, perguntas - página 1626

[Vasilii Polovnikov]

Alexey Da:

Este comportamento é observado com algum perito?

Os registos seriam, no entanto, úteis. Enviar um bilhete para o Servicedesk.

Ainda não consigo anexar registos e ficheiros do meu telefone. Os parâmetros de optimização são cerca de 500. Valores dos parâmetros de 0 a 2. 2000 iterações passam num piscar de olhos. Então tudo é lento. Com a construção anterior, foram necessárias 120.000 corridas num dia.

[Alexey Oreshkin]

Alexey Navoykov:

...De outra forma, como explicar o facto de um guião completamente vazio, com apenas a função OnStart() { }, compila mais de 400 ms!

Claro que não escrevo compiladores, mas tenho a certeza de que há apenas um certo mínimo que não depende em nada da dimensão do projecto. É como chamar um táxi e conduzir até à entrada seguinte - parece mover-se um par de metros, no dinheiro um par de tostões, mas o preço mínimo de 200r também pode causar uma pergunta - há um tostão para ir, para quê ?!

[Alexey Navoykov]

Alexey Oreshkin:
Claro que não escrevo compiladores, mas tenho a certeza de que existem simplesmente alguns mínimos que não dependem em nada da dimensão do projecto. É como chamar um táxi e conduzir até à entrada seguinte - como mover um par de metros, no dinheiro um par de kopecks, mas o preço mínimo de servir em 200r também pode levantar uma questão - aqui para ir por um cêntimo, para quê?!

Bem, com o advento do Yandex Taxi e serviços semelhantes, isto já foi de certa forma mitigado. E estes números são bastante razoáveis, porque todos precisam de comer. Mas os números que citei não são claramente adequados à complexidade da tarefa.

[fxsaber]

Alexey Navoykov:

Há cerca de três meses atrás tentei levantar esta questão, mas não foi compreendida, aparentemente os meus argumentos não foram suficientemente convincentes. Por conseguinte, voltei à velha construção (1159), que compilou tudo quase instantaneamente (enquanto com novos compiladores o meu projecto compilou em 20 segundos).

E assim, há uma semana, tenho tentado mudar para uma nova construção. Pensei "esquece cerca de 20 segundos, vou aguentar por causa de coisas novas". Claro que tive de afinar um pouco o código para cumprir novas condições, o que revelou vários bugs do novo compilador (descritos aqui).O resultado é que o meu projecto já está a ser compilado há 30 segundos! Não sei se tem a ver com a complicação do projecto ou com mais uma "complicação" do compilador, mas simplesmente já não se encaixa.

O projecto contém cerca de 700 Kb de código fonte, é um Expert Advisor contendo algumas dezenas de mqh. Tudo é OOP. As pessoas escreveram-me anteriormente que a desaceleração é provavelmente causada por grandes funções. Tive alguns deles. Bem, fragmentei-os em partes mais pequenas e não têm qualquer efeito.

O que é mais espantoso é que esta compilação superlongativa não tem qualquer utilidade. A velocidade do programa é a mesma que com o antigo compilador, medi-o especificamente. Isso pede apenas uma frase: "Para quê?".

Tenho a forte sensação de que existe um bug/mal funcionamento no compilador por causa do qual ele está a correr ociosamente através de um espaço vazio. De que outra forma posso explicar o facto de um script absolutamente vazio com apenas a função OpenStart() { } compila mais de 400 ms!É inimaginável que possa demorar tanto tempo a compilar/optimizar um guião vazio. Bem, acrescentando-lhe pequenas funções e classes, pode-se ver como o tempo de compilação cresce rapidamente.

Quero dizer desde já que o meu hardware está naturalmente longe de ser poderoso - Core i5U. Mas isto não impede o meu projecto de compilar em 1-2 segundos num compilador antigo. Respectivamente, o boneco é compilado lá num instante.

Vou também notar. O compilador carece completamente não só de cache de fragmentos compilados anteriormente, mas até de uma verificação trivial para se certificar de que o código fonte era idêntico. Isto é, compila-se o projecto e depois clica-se novamente no botão "Compile" sem fazer quaisquer alterações e espera-se novamente pelos mesmos 30 segundos...

Gostaria de ouvir comentários dos programadores de MT e dos utilizadores do fórum que trabalham com grandes projectos (sou apenas eu quem está preocupado com este problema?), quanto tempo leva a compilar e em que hardware. Gostaríamos de salientar que estamos a falar da compilação de um executável.

Trata-se de construções complexas, que por vezes se reportam aqui como insectos. Se não os utilizar, o tempo será significativamente reduzido. Por exemplo, TODO o código em kodobase compila significativamente mais rápido do que 20 segundos. Tenho um 1368 construído sobre um portátil muito lento que se compila em dezenas de ms. Dê-me o código para reproduzir.

[Alexey Navoykov]

coderex:
É por isso que não estou a tentar provar mais nada, para além de que os projectos sobre as vantagens demoram muito mais tempo a construir, embora sejam muito maiores, mas estou habituado a construir em poucos minutos um ficheiro executável ou biblioteca, enquanto um projecto com vários ficheiros com uma estrutura de directório demora até várias dezenas de minutos :) e esperar 10-20 segundos não é um problema...

Não consigo imaginar quanto tempo um tal projecto demoraria a ser construído em MQL. Mesmo as IDEs com todas as características têm modos de compilação diferentes. Talvez se esteja a referir à construção da libertação, enquanto que na maioria das vezes o modo de depuração é suficiente para nós. Mas em MT não se tem muito tempo para esperar por isso.

Além disso, utilizam ficheiros pré-compilados, pelo que as construções subsequentes serão obviamente mais rápidas

[Alexey Navoykov]

fxsaber:
O assunto é sobre construções complexas, cujo fracasso frequente é por vezes aqui relatado como um bug. Se não os utilizar, o tempo será significativamente reduzido. Por exemplo, TODO o código em kodobase compila significativamente mais rápido do que 20 segundos. Tenho um 1368 construído sobre um portátil muito lento que se compila em dezenas de ms. Dê-me o código para jogar.

Não está a exagerar em relação a TODOS os códigos? Como pode ter tanta certeza? Já os experimentou todos?

E quanto aos desenhos complexos, essa é apenas a sua especulação. O que há de complicado neles? Se puderem apresentar alguma complexidade, esta só está na fase de verificação da sintaxe, e é executada instantaneamente. Isto pode ser visto, por exemplo, ao compilar mqh, onde não é criado nenhum código executável. Assim, depois desta verificação todas as aparentes dificuldades nas construções sintácticas já estão resolvidas e o compilador sabe exactamente o que fazer. O passo seguinte é a optimização do código executável. Portanto, é aqui que reside o problema.

Ok, quando estiver no meu computador vou dar-lhe algum código para reproduzir. Mas já estou confuso com as suas histórias sobre dezenas de ms em hardware fraco. Estamos a falar exactamente das mesmas coisas? O ficheiro do guião é .mq5? E que processador tem?

[Alexey Viktorov]

-Aleks-:
A ligação não dá a informação de interesse - seja específica.

Difícil de adivinhar abra a primeira página do tópico que tem duas fotografias no primeiro post???

https://www.mql5.com/ru/forum/88768

[Aleksey Vyazmikin]

Alexey Viktorov:

Difícil de adivinhar abra a primeira página do tópico que tem duas fotografias no primeiro post???

https://www.mql5.com/ru/forum/88768

Olhei para a primeira fotografia - não têm dados no sítio web sobre a conta de cêntimos para os cinco. Mas a segunda fotografia tem esses dados, mas não é claro se é possível sobrepor-se lá? E a limitação do número de encomendas em aberto e do volume de posições... Isto não é bom em geral. Mas é bom que haja uma possibilidade.

Mas, infelizmente, não tenho qualquer incentivo para reescrever todo o código (incluindo gastar dinheiro extra na reescrita de um código complexo).

[Alexey Viktorov]

-Aleks-:

Olhei para a primeira fotografia - não têm dados no sítio web sobre a conta de cêntimos para os cinco. Mas a segunda fotografia tem tais dados, mas não é claro se é possível sobrepor ali? E a limitação do número de encomendas em aberto e do volume de posições... Isto não é bom em geral. Mas é bom que haja uma possibilidade.

Mas, infelizmente, não temos qualquer incentivo para reescrever todo o código (incluindo gastar dinheiro extra para reescrever o código complexo).

Então porque é que teve de inventar tais razões? Poderia apenas dizer NIKHAT e NOBODY...

Se não tiver esse tipo de dinheiro para negociar numa conta em dólares, que restrições ao número de encomendas e aos volumes o podem pressionar? É tudo estranho.

[Aleksey Vyazmikin]

Alexey Viktorov:

Então porquê inventar tais razões? Poderia simplesmente dizer que eu não quero e não vou...

Se não tenho dinheiro suficiente para negociar numa conta em dólares, que restrições ao número de encomendas e volumes me podem pressionar? É tudo estranho.

Quero e vou - já encomendei uma aula sobre como trabalhar com encomendas - da forma como me sinto confortável - estou à espera da sua chegada até ao final do ano.

Negocio uma grelha de contra-tendência, e mesmo com lotes crescentes, com muitos pares de moedas - por isso é necessário um grande volume de encomendas e apoio para um grande volume de posições. Resolvo o problema com diferentes truques, se tiver de os desenvolver e implementar de novo, isso só me levará o meu tempo e não melhorará os meus resultados financeiros.