Erros, bugs, perguntas - página 1952

Novo comentário
 
Stanislav Korotky:

O compilador não ajuda aqui - testado - o objecto local por devolução é duplicado e depois pregado. Neste caso, não há uma jogada ideal.


Fez testes de velocidade? Ou apenas o diagnóstico da criação de objectos? Se for o segundo, então é claro que nada será removido do código, porque você mesmo o impede com os seus cheques.

 
Alexey Navoykov:


Efectuou testes de velocidade? Ou está apenas a diagnosticar o facto da criação de objectos? Se for este último, é claro que nada será excluído do código, uma vez que você mesmo o impede através dos seus controlos.

Como assim? Todos os meus controlos consistem apenas em vestígios colocados em construtores e destruidores. Se forem criadas e eliminadas cópias extra, isso é prova suficiente para mim de que não há optimização.

 
Alexey Navoykov:


Já realizou testes de medição de velocidade? Ou apenas diagnosticar o facto da criação de objectos? Se o segundo, então é claro que nada será excluído do código, porque você mesmo o impede com os seus cheques.

Bem, se não se podem mover linhas, não se podem mover objectos mais complexos.

 
Stanislav Korotky:

Como assim? Todos os meus controlos consistem apenas em vestígios colocados em construtores e destruidores. Se forem criadas e eliminadas cópias extra, isso para mim é prova suficiente da falta de optimização.

O optimizador não consegue arrancar um fragmento que contenha o seu traço). Só as coisas que não afectam a sua lógica podem ser recortadas.
 

Agora no OnTesterInit pode definir intervalos de optimização para cada parâmetro de entrada. O testador gera então uma tabela de passes por si próprio, divide-a no número de Agentes/Pacotes e envia-a para os Agentes. Esta tabela não é editável de forma alguma agora.

Mas durante a Optimização é de facto muito comum preocupar-se primeiro com passagens em que alguns parâmetros importantes mudam, depois onde outro muda, etc. Se fosse possível editar uma tabela de passes gerada (para alterar lugares de elementos (conjuntos de parâmetros de entrada)) ou geri-la por si próprio, seria possível definir a prioridade necessária, quando os passes mais interessantes iriam primeiro para os Agentes, e depois - passes menos interessantes.


Por conseguinte, proponho acrescentar ao OnTesterInit a possibilidade de alterar a tabela padrão de passes:

long PassesTotal(); // количество проходов в таблице для Оптимизации

// Получает список входных параметров соответствующего прохода
int PassesGet( const int Index,  MqlParam& Parameters[] );


// Прописывает список входных параметров для соответствующего прохода,
// если индекс не меньше размера таблицы, то идет дозапись в конец таблицы и размер ее увеличивается на единицу
int PassesSet( const int Index, const MqlParam& Parameters[] );
 
Alexey Navoykov:
O optimizador não poderá cortar a secção com o seu traço ) Só pode cortar coisas que não afectem a lógica do trabalho.

Bem, o tema está encerrado ;-). Penso que a optimização neste caso só poderia acontecer naquele local de código onde o valor de retorno ocorre, e de forma alguma depende do que está escrito no construtor.

Norma C++11: Quando determinados critérios são cumpridos, uma implementação é autorizada a omitir a cópia/movimento da construção de um objecto de classe, mesmo que a cópia/movimento do construtor e/ou destruidor do objecto tenha efeitos secundários. Nesses casos, a implementação trata a fonte e o alvo da operação de cópia/movimento omitida como simplesmente duas formas diferentes de se referir ao mesmo objecto, e a destruição desse objecto ocorre na última das vezes em que os dois objectos teriam sido destruídos sem a optimização.

 
Stanislav Korotky:

Bem, o tema está encerrado ;-). Na minha opinião, a optimização neste caso só poderia ter lugar naquele lugar de código onde o retorno do valor acontece, e não depende de forma alguma do que está escrito no construtor.

De qualquer forma, devo lamentar que o compilador MQL esteja longe de ser tão inteligente como eu pensava que era ) Eu diria mesmo que não é nada inteligente. ) Tentei fazer alguns exemplos simples e descobri que mesmo que eu crie um objecto fictício, que não é usado em lado nenhum e não faz nada, o compilador não se importa com isso. Não está de todo optimizado. Estou a julgar apenas pela velocidade. E por alguma razão funciona mais lentamente em construções novas do que nas antigas.

Aqui está um código trivial:

class A { };

void OnStart()
  {
    uint starttick= GetTickCount();
    for (int i=0; i<1 e8; i++)
    { 
      A a;
    }
    Print(GetTickCount()-starttick," ms");
  }
 
Alexey Navoykov:

Bem, infelizmente tenho de admitir que o compilador MQL não é tão inteligente como eu imaginava que fosse ) Eu diria até que não é nada inteligente).


Alguma vez pensou que poderia ser afinado para optimizar as coisas reais que a maioria das pessoas usa, em vez dos disparates que escreveu do nada?

 
Stanislav Korotky:

Bem, o tema está encerrado ;-). Na minha opinião, a optimização neste caso só poderia ter lugar no local de código onde se verifica a devolução do valor, e de forma alguma depende do que está escrito no construtor.


Foi apenas em 2 anos que foram introduzidos os construtores de cópias.
Seguem-se na linha RVO (optimização do valor de retorno) e NRVO (chamada optimização do valor de retorno)...

 
Sergey Dzyublik:

Já considerou que poderia ser afiado para optimizar as coisas reais que a maioria das pessoas usa, em vez das tretas que fazem do ar rarefeito?

o que é "o verdadeiro material que a maioria das pessoas usa" ?
1...194519461947194819491950195119521953195419551956195719581959...3184
Novo comentário