Características da linguagem mql5, subtilezas e técnicas - página 153

Novo comentário
 
Roffild:

No ArrayReverse ajuda:

A funçãoArraySetAsSeries() não move fisicamente os elementos da matriz, mas apenas inverte a direcção de indexação para trás para organizar o acesso aos elementos como numasérie temporal. A função ArrayReverse() move fisicamente os itens da matriz para que a matriz seja "invertida".

Mas este código prova o oposto:

Porquê? É isso mesmo.

Se lidarmos com uma série em que a numeração é como numa série temporal, ou seja, a barra zero é a mais recente e a mais recente é a mais antiga, quando um novo elemento é adicionado, ele será próximo da mais recente, ou seja, a mais antiga.

E se a matriz não for numerada como nas séries temporais, então o elemento zero é o mais antigo e o mais recente é o mais recente. Por conseguinte, quando um novo elemento é adicionado, ele estará ao lado do mais recente.
Que é o que acontece no seu teste.

Onde está a prova aqui que eu não compreendo. Como o podemos provar e descobrir onde está o início da matriz na memória e que passo de incremento é positivo ou negativo.
Só o pode provar passando a matriz e usando apontadores.
Mas é mais fácil de o provar medindo o tempo que leva a executar esta operação. Se um conjunto de 100 000 000 de artigos "vira" instantaneamente, é evidente que não há viragem; a referência ao início muda e o incremento muda o seu sinal.
Eu uso a funçãoArraySetAsSeries() o tempo todo, e vejo que é absolutamente livre no tempo. Portanto, está enganado.

Para ser honesto, não entendo porque precisamos da funçãoArrayReverse lentaquando temos oArraySetAsSeries()

 
Roffild:

No ArrayReverse ajuda:

A funçãoArraySetAsSeries() não move fisicamente os elementos da matriz, mas apenas inverte a direcção de indexação para trás para organizar o acesso aos elementos como numasérie temporal. A função ArrayReverse() move fisicamente os itens da matriz para que a matriz seja "invertida".

Mas este código prova o oposto:

Tem uma reatribuição de memória para uma matriz com a bandeira asSeries, naturalmente que levaram isso em conta. Devem ter aí algo parecido com isto:

template<typename T>
T* ReAllocArray(T* array, size_t size, size_t newSize, bool asSeries) {
    auto _array = (T*)realloc(array, newSize * sizeof(T));
    if (_array == NULL) throw bad_alloc();
    auto _ptr = _array + size;
    auto ptr = _array + newSize;
    if (asSeries){
        while (_ptr != _array) *(--ptr) = *(--_ptr);
        while (ptr != _array) new(--ptr) T;
    }
    else {
        while (_ptr != ptr) new(_ptr++) T;
    }
    return _array;
}
 
Vladimir Simakov:

Tem uma realocação de memória para uma matriz com a bandeira asSeries, claro que tiveram isso em conta. Devem ter aí algo do género:

Sim, eles devem tê-lo tido em conta. Mas este comportamento não corresponde aCopyRates():

Independentemente da propriedade da matriz receptora - as_series=verdadeiro ou as_series=falso, os dados serão copiados para que o elemento mais antigo no tempo esteja no início da memória física atribuída à matriz.

Também paraArrayCopy():

Se contar<0 ou contar>src_size-src_start, todo o resto da matriz é copiado. As arrays são copiadas da esquerda para a direita. Para matrizes em série, a posição inicial é anulada correctamente , tendo em conta a cópia da esquerda para a direita.

A última frase é um pouco ambígua.
 

Estou um pouco em estado de choque. Escrevi um teste em Java. Acontece que Java é quase tão rápido como C, e portanto ligeiramente mais rápido do que MQL5.

Não sei como o fazem, na realidade é uma língua de intérprete.

Pergunto-me se será o mesmo com Python.

É claro que não está a dizer que a MQL5 é má. É que Java é demasiado fixe.

Deve-me ter escapado alguma coisa. Desde quando é que os intérpretes se tornaram tão rápidos como os compiladores?

Aparentemente, isto só é possível com uma compilação parcial, ou seja, os intérpretes não são puros.

 
Nikolai Semko:

Estou um pouco em estado de choque. Escrevi um teste em Java. Acontece que Java é quase tão rápido como C, e portanto ligeiramente mais rápido do que MQL5.

Não sei como o fazem, na realidade é uma língua de intérprete.

Pergunto-me se será o mesmo com Python.

É claro que não está a dizer que a MQL5 é má. É que Java é demasiado fixe.

Deve-me ter escapado alguma coisa. Desde quando é que os intérpretes se tornaram tão rápidos como os compiladores?

Aparentemente, isto só é possível com uma compilação parcial, ou seja, os intérpretes não são puros.

A MQL é também uma intérprete.

 
Nikolai Semko:

Estou um pouco em estado de choque. Escrevi um teste em Java. Acontece que Java é quase tão rápido como C, e portanto ligeiramente mais rápido do que MQL5.

Não compreendo como o conseguem fazer, na realidade é uma língua de intérprete.

Pergunto-me se será o mesmo com Python.

É claro que não está a dizer que a MQL5 é má. É que Java é demasiado fixe.

Deve-me ter escapado alguma coisa. Desde quando é que os intérpretes se tornaram tão rápidos como os compiladores?

Aparentemente, isto só é possível com uma compilação parcial, ou seja, os intérpretes não são puros.

Java, embora traduzida em bytecode, tem a sua própria máquina de execução virtual (JVM).
A língua é também estritamente dactilografada, ao contrário de outras línguas com um intérprete.
Muito provavelmente, a digitação rigorosa e a JVM são a razão para a rápida execução e transmissão de instruções para o hardware.
Os terminais comerciais americanos são escritos em Java por uma razão. O Grupo CME em Chicago oferece oficialmente terminais escritos em Java.
Um programador disse-me uma vez que Java tem as suas raízes nas telecomunicações.
Nas telecomunicações é preciso ter a velocidade de processamento e transferência de dados.
E a Oracle tem a sua própria comunidade para o desenvolvimento desta língua.
Ou seja, a língua está viva e a ser finalizada pela comunidade Oracle.

A propósito, a marca Quik e a língua LUA também foram desenvolvidas pelos americanos.
Mas na década de 90, foi vendida com sucesso à Federação Russa.
Naqueles anos, os americanos já compreendiam que a LUA não tinha qualquer desenvolvimento futuro.
E despejaram-na com sucesso na Federação Russa, onde uma bolsa de valores tinha acabado de começar a formar-se após o colapso da União.

 
Nikolai Semko:

Estou um pouco em estado de choque. Escrevi um teste em Java. Acontece que Java é quase tão rápido como C, e portanto ligeiramente mais rápido do que MQL5.

Não compreendo como o fazem, é essencialmente uma língua de intérprete.

O modelo lá é o mesmo que em .Net - o código fonte é compilado em bytecode, será um intérprete, e quando se desempacota o bytecode num determinado PC, o código nativo será gerado para o ambiente virtual onde será executado, ou seja, será compilado código

https://habr.com/ru/post/107585/


google "compilador ou intérprete de Java" para Java - haverá artigos semelhantes

 
Алексей Тарабанов:

A MQL é também uma intérprete.

Justificação?

 
Nikolai Semko:

Estou um pouco em estado de choque. Escrevi um teste em Java. Acontece que Java é quase tão rápido como C, e portanto ligeiramente mais rápido do que MQL5.

Não sei como o fazem, na realidade é uma língua de intérprete.

Pergunto-me se será o mesmo com Python.

É claro que não está a dizer que a MQL5 é má. É que Java é demasiado fixe.

Deve-me ter escapado alguma coisa. Desde quando é que os intérpretes se tornaram tão rápidos como os compiladores?

Aparentemente, isto só é possível com uma compilação parcial, ou seja, os intérpretes não são puros.

Alguma vez se perguntou quanto tempo de arranque leva? Quanta memória é devorada e quantos fios a JVM corre para compilar bytes de código? Corri monstro que compilou o mundo do olá na mosca e acabou com ambos nativ. Excepto que o monstro C não tem um. E sobre python.

Fórum sobre comércio, sistemas de comércio automatizados e testes estratégicos

MetaTrader 5 Python User Group - Como usar Python em Metatrader

Vitória, 2019.12.07 07:12

Sobre python - recentemente falou-se sobre ranger (gestor de ficheiros), que está escrito no mesmo. Utilizei-a durante alguns dias e a minha impressão é que é uma ideia fixe com características interessantes, mas a pitão é realmente lenta (se algumas tarefas complicadas forem executadas em segundo plano). Arrancado, não sei porque é que as pessoas são tão atraídas pela pitão. Colocar uma coisa semelhante em C.

Bem ok - compre um triturador de números multi-core com uma carroça de RAM e diga o meu java/sharp/... são muito fixes neste teste, e vamos manter-nos calados sobre a carga global. Eles nunca alcançarão C. Progresso, tomar tetris dos anos 80, reescrevê-lo em sharpe, e correr tão rápido como antes, mas com um CPU de 60 núcleos)).

ZS: semelhante a como dois fios em Elbrus só estão envolvidos na transmissão a partir de instruções x86. BelAZ a transportar uma encomenda.

 
A propósito, quanto à Sharp, parece que os pequenotes tornaram possível a compilação directa para código nativo. Ainda não experimentei, mas é suposto ser fixe.
1...146147148149150151152153154155156157158159160...247
Novo comentário
Razão: