Características del lenguaje mql5, sutilezas y técnicas - página 153

Nuevo comentario
 
Roffild:

En la ayuda de ArrayReverse:

La funciónArraySetAsSeries() no mueve físicamente los elementos del array, sino que sólo invierte la dirección de indexación hacia atrás para organizar el acceso a los elementos como en unaserie temporal. La función ArrayReverse() mueve físicamente los elementos del array para que éste se "invierta".

Pero este código demuestra lo contrario:

¿Por qué? Así es.

Si tratamos con un array en el que la numeración es como en una serie de tiempo, es decir, la barra cero es la más reciente y la más reciente es la más antigua, cuando se añada un nuevo elemento, éste se situará junto al más reciente, es decir, el más antiguo.

Y si la matriz no está numerada como en las series de tiempo, entonces el elemento cero es el más antiguo y el último es el más tardío. Por lo tanto, cuando se añada un nuevo elemento, estará al lado del más reciente.
Que es lo que ocurre en tu prueba.

Dónde está la prueba aquí no lo entiendo. Cómo podemos probarlo y averiguar dónde está el inicio del array en la memoria y qué paso de incremento es positivo o negativo.
Sólo se puede probar pasando el array y utilizando punteros.
Pero es más fácil demostrarlo midiendo el tiempo que se tarda en ejecutar esta operación. Si una matriz de 100 000 000 elementos se "voltea" instantáneamente, está claro que no hay volteo; la referencia al principio cambia y el incremento cambia de signo.
Yo uso la funciónArraySetAsSeries() todo el tiempo, y puedo ver que es absolutamente libre en el tiempo. Así que te equivocas.

Para ser honesto, no entiendo por qué necesitamos la lenta funciónArrayReverse cuando tenemos la rápidaArraySetAsSeries()

 
Roffild:

En la ayuda de ArrayReverse:

La funciónArraySetAsSeries() no mueve físicamente los elementos del array, sino que sólo invierte la dirección de indexación hacia atrás para organizar el acceso a los elementos como en unaserie temporal. La función ArrayReverse() mueve físicamente los elementos del array para que éste se "invierta".

Pero este código demuestra lo contrario:

Tienes reasignación de memoria para un array con la bandera asSeries, naturalmente lo han tenido en cuenta. Deben tener algo así allí:

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:

Tienes reasignación de memoria para un array con bandera asSeries, por supuesto que lo han tenido en cuenta. Deben tener algo así allí:

Sí, lo habrán tenido en cuenta. Pero este comportamiento no corresponde aCopyRates():

Independientemente de la propiedad que tenga el array receptor - as_series=true o as_series=false, los datos se copiarán de forma que el elemento más antiguo en el tiempo estará al principio de la memoria física asignada al array.

También aArrayCopy():

Si count<0 o count>src_size-src_start, se copia todo el resto de la matriz. Las matrices se copian de izquierda a derecha. Para las matrices en serie, la posición de inicio se anula correctamente , teniendo en cuenta la copia de izquierda a derecha.

La última frase es un poco ambigua.
 

Estoy un poco en estado de shock. He escrito una prueba en Java. Resulta que Java es casi tan rápido como C, y por tanto ligeramente más rápido que MQL5.

No sé cómo lo hacen, de hecho es una lengua de interpretación.

Me pregunto si ocurre lo mismo con Python.

Por supuesto, no se trata de decir que MQL5 sea malo. Es que Java es demasiado genial.

Debo haberme perdido algo. ¿Desde cuándo los intérpretes son tan rápidos como los compiladores?

Aparentemente, esto sólo es posible con la compilación parcial, es decir, los intérpretes no son puros.

 
Nikolai Semko:

Estoy un poco en estado de shock. He escrito una prueba en Java. Resulta que Java es casi tan rápido como C, y por tanto ligeramente más rápido que MQL5.

No sé cómo lo hacen, de hecho es una lengua de interpretación.

Me pregunto si ocurre lo mismo con Python.

Por supuesto, no se trata de decir que MQL5 sea malo. Es que Java es demasiado genial.

Debo haberme perdido algo. ¿Desde cuándo los intérpretes son tan rápidos como los compiladores?

Aparentemente, esto sólo es posible con la compilación parcial, es decir, los intérpretes no son puros.

MQL también es un intérprete.

 
Nikolai Semko:

Estoy un poco en estado de shock. He escrito una prueba en Java. Resulta que Java es casi tan rápido como C, y por tanto ligeramente más rápido que MQL5.

No sé cómo lo hacen, de hecho es una lengua de interpretación.

Me pregunto si ocurre lo mismo con Python.

Por supuesto, no se trata de decir que MQL5 sea malo. Es que Java es demasiado genial.

Debo haberme perdido algo. ¿Desde cuándo los intérpretes son tan rápidos como los compiladores?

Aparentemente, esto sólo es posible con la compilación parcial, es decir, los intérpretes no son puros.

Java, aunque traducido a bytecode, tiene su propia máquina de ejecución virtual (JVM).
El lenguaje también es estrictamente tipado, a diferencia de otros lenguajes con intérprete.
Lo más probable es que la tipificación estricta y la JVM sean la razón de la rápida ejecución y transmisión de instrucciones al hardware.
Los terminales de comercio estadounidenses están escritos en Java por una razón. El CME Group de Chicago ofrece oficialmente terminales escritos en Java.
Un programador me dijo una vez que Java tiene sus raíces en las telecomunicaciones.
En telecomunicaciones hay que tener velocidad para procesar y transferir datos desde el principio.
Y Oracle tiene su propia comunidad para el desarrollo de este lenguaje.
Es decir, el lenguaje está vivo y está siendo ultimado por la comunidad Oracle.

Por cierto, la marca Quik y el lenguaje LUA también fueron desarrollados por los estadounidenses.
Sin embargo, en la década de los 90, se vendió con éxito a la Federación Rusa.
En aquellos años, los americanos ya entendían que la LUA no tenía ningún desarrollo futuro.
Y lo volcaron con éxito en la Federación Rusa, donde acababa de empezar a formarse un mercado de valores tras el colapso de la Unión.

 
Nikolai Semko:

Estoy un poco en estado de shock. He escrito una prueba en Java. Resulta que Java es casi tan rápido como C, y por tanto ligeramente más rápido que MQL5.

No entiendo cómo lo hacen, es esencialmente un lenguaje de interpretación.

El modelo allí es el mismo que en .Net - el código fuente se compila en bytecode, será un intérprete, y cuando se descompone el bytecode en un PC determinado, se generará el código nativo para el entorno virtual donde se ejecutará, es decir, será código compilado

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


busque en Google "compilador o intérprete de Java" para Java - habrá artículos similares

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

MQL también es un intérprete.

¿Justificación?

 
Nikolai Semko:

Estoy un poco en estado de shock. He escrito una prueba en Java. Resulta que Java es casi tan rápido como C, y por tanto ligeramente más rápido que MQL5.

No sé cómo lo hacen, de hecho es una lengua de interpretación.

Me pregunto si ocurre lo mismo con Python.

Por supuesto, no se trata de decir que MQL5 sea malo. Es que Java es demasiado genial.

Debo haberme perdido algo. ¿Desde cuándo los intérpretes son tan rápidos como los compiladores?

Aparentemente, esto sólo es posible con la compilación parcial, es decir, los intérpretes no son puros.

¿Te has preguntado alguna vez cuánto tiempo de arranque lleva? ¿Cuánta memoria se engulle y cuántos hilos ejecuta la JVM para compilar bytes de código? Corrí monstruo que compilado hola mundo sobre la marcha y terminó con ambos nativ. Excepto que el monstruo C no tiene uno. Y sobre python.

Foro sobre comercio, sistemas de comercio automatizados y pruebas de estrategias

Grupo de usuarios de Python de MetaTrader 5 - Cómo utilizar Python en Metatrader

Vict, 2019.12.07 07:12

Sobre python - recientemente se habló de ranger (administrador de archivos), que está escrito en él. Lo he usado durante unos días y mis impresiones son que es una idea genial con características interesantes, pero python es realmente lento (si se realizan algunas tareas complicadas en segundo plano). Lo he arrancado, no sé por qué a la gente le gusta tanto el pitón. Poniendo algo similar en C.

Bueno ok - comprar una trituradora de números multinúcleo con un vagón de RAM y decir mi java/sharp/... están muy bien en esta prueba, y vamos a guardar silencio sobre la carga total. Nunca alcanzarán a C. Progreso, coge el tetris de los 80, reescríbelo en sharpe, y corre tan rápido como antes, pero con una CPU de 60 núcleos)).

ZS: como dos hilos en Elbrus sólo participan en la transmisión de instrucciones x86. BelAZ transportando un paquete.

 
Por cierto, en cuanto a Sharp, parece que los pequeños softwares hicieron posible la compilación directa a código nativo. Todavía no lo he probado, pero debe ser genial.
1...146147148149150151152153154155156157158159160...247
Nuevo comentario