Erros, bugs, perguntas - página 816

[Renat Fatkhullin]

Na minha opinião, isto é apenas uma optimização do primeiro caso de acesso directo a um membro do objecto.

No segundo caso há acesso indirecto através de referência, o que num corpo de laço microscópico leva naturalmente metade do tempo, duplicando-o.

[Renat Fatkhullin]

O teste é algo incorrecto, comparando essencialmente a diferença entre uma única instrução de montagem e duas instruções de montagem colocadas numa centena de milhões de loops.

[---]

Renat:
Penso que isto é apenas uma optimização do primeiro caso de acesso directo a um membro do objecto.

No segundo caso temos acesso indirecto através de referência que naturalmente leva metade do tempo com um corpo de laço microscópico a aumentar para o dobro.

Renat, no mundo real existem grandes conjuntos de dados em processamento. Já simplifiquei o teste, apenas para mostrar a área problemática. Inicialmente criei-o usando as minhas próprias matrizes e classes. Depois reduzi-o a um esquema.

ou seja, não temos apenas um objecto de arr, mas uma série de objectos complexos (também com matrizes).

aproximadamente isto pode ser escrito no esquema como

class A
{
  double prm1;
  int prm2;
  string prm3;
  char prm4;
}

class B
{
   A m_a[1000];
}

B _b[1000];

Raciocinei que se eu conseguir uma referência a um determinado elemento de matriz A

А *item=GetPointer(_b[i]._a[j]);

O trabalho com os parâmetros A::prmX será mais rápido.

Mas verificou-se que retirar uma salsicha dos nomes da matriz

_b[i]._a[j].prmX  

seria pelo menos duas vezes mais rápido do que a referência a um determinado item.

Fiquei um pouco surpreendido com isto, e é evidente que o núcleo está a receber algum tipo de pseudo-ponto.

Existe alguma forma de optimizar a velocidade, o que pelo menos reduz a diferença de velocidade?

[mvk]

sergeev:

é assim que vai ser sem erros

Não haverá erros neste teste. Mas este método não resolve a questão principal: porque é que o compilador salta a transformação de uma referência constante de objectos para uma referência não constante sem gerar quaisquer erros e/ou avisos? Se for uma característica deste tipo, não há dúvidas, mas neste caso perde-se o significado do modificador constante para o tipo devolvido na assinatura dos métodos de classe.

[---]

mvk:
Não haverá erros desta forma neste teste. Mas este método não resolve a questão principal: porque é que o compilador salta a transformação de uma referência constante de objectos para uma referência não constante e não gera nenhum erro e/ou aviso? Se for uma característica deste tipo, não há dúvidas, mas neste caso perde-se o significado da constante modificadora para o tipo devolvido na assinatura dos métodos de classe.

tudo faz sentido para mim.

As funções do objecto constante não devem alterar o objecto em si, pelo que também devem ter um modificador constante

e sobre

   //Ошибки нет. Это НЕ правильно(CONST A* B::getA())!
   A* a2 = b.getA();

bem, sim, isso não vai funcionar em C++.

Escrever para Servicedesk.

[Renat Fatkhullin]

sergeev:

Mas acontece que puxar uma salsicha para fora de nomes de matriz

será pelo menos duas vezes mais rápido do que aceder a um item específico.

É realmente mais rápido, ou é uma construção lógica da produção baseada em outros casos mais simples?

Na minha opinião, ainda não foi apresentada uma prova limpa com base no acesso apresentado a uma matriz multidimensional. Especialmente dada a presença da função adicional francamente dispendiosa GetPointer.

Surpreendeu-me um pouco, e tornou-se claro que há algum tipo de pseudo-indexação a decorrer no núcleo.

Os apontadores no sentido convencional não existem na MQL5, eles são pegas, com todas as suas consequências.

Existe alguma forma de optimizar a velocidade, o que pelo menos reduziria a diferença de velocidade?

Estamos constantemente a trabalhar na optimização, mas no caso de referências/handles há uma sobrecarga do sistema no acesso indirecto.

De qualquer forma, vamos analisar mais de perto a optimização de tal acesso.

[---]

Renat:

É realmente mais rápido ou é uma construção lógica da conclusão baseada em outros casos mais simples?

sim, é bastante realista. testei-o ao encher as minhas matrizes. sempre foi duas vezes mais lento.

A meu ver, ainda não foi apresentada uma prova limpa baseada na matriz multidimensional de acesso apresentada.

Bem, eu expus o esquema e uma imagem das classes A, B e arrays.

Especialmente com a função adicional francamente dispendiosa GetPointer.

é chamado uma vez antes de entrar num laço. mas em princípio, para um teste mais preciso, também pode levá-lo para fora do GetTickCount

Em qualquer caso, iremos analisar mais de perto a optimização desse acesso.

OK. Obrigado. É exactamente o que precisamos.

[Renat Fatkhullin]

sergeev:

é chamado uma vez antes de entrar no laço. mas, em princípio, para um teste mais preciso, poderia também levá-lo para fora do GetTickCount

Que tal fora do laço se o código for assim?

А *item=GetPointer(_b[i]._a[j]);

[Maxim Khrolenko]

Uma sugestão. A função de zoom do texto pode ser incluída na ajuda, por exemplo, + ou - , ou a roda Ctrl+mouse.

[Rashid Umarov]

paladin800:
Uma sugestão. A função de zoom do texto pode ser incluída na ajuda. por exemplo, + ou - , ou Ctrl+ roda do rato.

Provavelmente não é possível. A versão online não é adequada?

Eis o que encontrei na Internet sobre o assunto - http://forum.ru-board.com/topic.cgi?forum=62&topic=20907

UPDate More http://forum.ixbt.com/topic.cgi?id=23:39211