Borrar una matriz de elementos definidos - página 16

 
Taras Slobodyanik:

Creo que es un buen partido para las banderas:
http://osinavi.ru/asm/4.php

y para los operadores/comparadores innecesarios...

Lo he comprobado a través de los perfiles. Número de comparaciones, asignaciones y operaciones mat que coinciden
 
Nikolai Semko:

Vuelvo a mi malentendida diferencia de tiempo de ejecución de casi el 100% idéntica en lógica y número de comprobaciones y sumas de dos bucles:


Ya escribí arriba - Tengo menos operaciones de comparación en mi código...

-----

De fuera de la escuela, en algún lugar de los años 90:

1) si las (condiciones) A,B,C son independientes, entonces hay que meterlas en la función AND a medida que la probabilidad aumenta, y en la función OR a medida que disminuye.

y si son dependientes, no deben combinarse en una sola expresión (es decir, hacer si (A && B) ).

2) Si hay bucles anidados A,B, el exterior debe ser más corto

3) Si hay una condición dentro del bucle, debe dividir el bucle y llevar la condición fuera de él, si es posible.


 
Maxim Kuznetsov:

Ya he escrito más arriba que tengo menos operaciones de comparación en mi código...

-----

de estudios extraescolares, en algún momento de los años 90:

1) si (las condiciones) A,B,C son independientes, entonces deben colocarse en la función AND por probabilidad creciente, y en la función OR por probabilidad decreciente.

y si son dependientes, no pueden combinarse en una sola expresión (es decir, do if (A && B) ).

2) Si hay bucles anidados A,B, el exterior debe ser más corto

3) Si hay una condición dentro del bucle, debe dividir el bucle y sacar la condición fuera, si es posible.


1) al revés, que es exactamente lo que has hecho. Si la primera condición de un operador AND compuesto no se ejecuta, ¿por qué debemos comprobar todas las demás condiciones? Por lo tanto, primero comprobamos la condición que es muy probable que sea falsa.

Aunque, sí, lo es: ordenar por probabilidad creciente los enunciados de verdad en una condición compuesta.

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

1) al revés, que es lo que has hecho. Peculiaridades de la ejecución de operadores condicionales en C.

Quizás lo escribí mal, pero es más fácil de explicar para todos a la vez...

A && B && C

Y debe ser feyed tan pronto como sea posible para evitar probar todas las otras condiciones. El optimizador no lo hará por el programador (*), ya que no sabe sobre qué datos se ejecutará el programa.

A || B | C

aquí es al revés :-) porque es aritmética booleana. ((!A)&&(!B)&&(!C) ) (si no te equivocas con los paréntesis, firma de nuevo)

(*) Los compiladores de optimización pueden confiar en que las condiciones están establecidas de forma correcta y construyen su cocina interna sobre estos supuestos

 
Maxim Kuznetsov:

Quizá esté mal escrito, pero tiene más sentido para todos a la vez...

A && B && C

Y debe ser feyed tan pronto como sea posible para no pasar por todas las otras condiciones. El optimizador no lo hará por el programador (*) porque no sabe sobre qué datos se ejecutará el programa

A || B | C

es al revés :-) porque la aritmética booleana... ((!A)&&(!B)&&(!C) ) (si de nuevo entre paréntesis, los signos no se confunden)

(*) Los compiladores de optimización pueden confiar en que las condiciones están establecidas de forma correcta y construyen su cocina interna sobre estos supuestos

Estoy completamente de acuerdo.

 
Nikolai Semko:

Vuelvo a mi malentendida diferencia de tiempo de ejecución de casi el 100% idéntica en lógica y número de comprobaciones y sumas de dos bucles:

Así que, de nuevo, por qué esa variante del código de Kuznetsov:

funciona más del doble de rápido que el mismo que hace exactamente lo mismo:

¿Cuáles son las maravillas del compilador?
¿Es realmente posible un diseño así?

el compilador encuentra algún comando de búsqueda especial del ensamblador para el procesador? Pero hay una comprobación adicional i<j dentro, ¿no?

Porque lo mismo a través de for se ejecuta mucho más lento:

Se adjunta el código del script de demostración

Así es como suele ocurrir. Estás ocupado con alguna basura innecesaria y descubres algo bastante interesante.

Desarrolladores, ¿podrían echar un vistazo al código ejecutable y ver a qué se debe esta diferencia?

Hay que entender la lógica del compilador para poder crear algoritmos más óptimos en el futuro.

Qué situación tan extraña en general. Creo que muchas cosas dependen del compilador y de la máquina en la que esté probando. Aquí está mi resultado de su ejemplo en una máquina de 32 bits

1


como puedes ver no hay ninguna ventaja en particular. Y aquí está una prueba de las funciones de borrado de arrays de la última variante.

2

 
A veces los resultados de las pruebas pueden ser muy diferentes de los resultados anteriores y no está claro a qué se debe, quizás a algún sistema específico de interrupciones en el procesamiento del código MQL
 
Stanislav Dray:
A veces, durante las pruebas, los resultados pueden ser muy diferentes de los anteriores, y no está claro por qué, tal vez tenga algo que ver con algún sistema de interrupción específico en el procesamiento del código MQL

Cuando se prueban los algoritmos, hay que tener en cuenta

* o conjuntos de datos preparados de antemano (más o menos similares a los que realmente se necesitan),

* o hacer un número muy significativo de pases en el RNG,

en las pruebas:

* alternar/barajar la secuencia de pruebas y

* observar las pausas y restablecer todo tipo de cachés



 
Maxim Kuznetsov:

Cuando se prueban los algoritmos, hay que tener en cuenta

* o conjuntos de datos preparados de antemano (más o menos similares a los que realmente se necesitan),

* o hacer un número muy significativo de pases en el RNG,

en las pruebas:

* alternar/barajar la secuencia de prueba y

* observar las pausas y volcar todo tipo de cachés



bien, como si utilizáramos datos preparados de antemano. Para todas las funciones se utilizan los mismos datos para la prueba. En cuanto a la baraja/cola, sí, he notado una diferencia si se cambia el orden de las pruebas. Pero, ¿cómo restablecer las cachés?

 
Maxim Kuznetsov:

Cuando se prueban los algoritmos, hay que tener en cuenta

* o conjuntos de datos preparados de antemano (más o menos similares a los que realmente se necesitan),

* o hacer un número muy significativo de pases en el RNG,

en las pruebas:

* alternar/barajar secuencias de pruebas y

* observar las pausas y volcar todo tipo de cachés



No te burles de la gente