Implementaciones alternativas de funciones/enfoques estándar - página 11
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
¿Puede enviarme el enlace, por favor?
No lo guardé. Mencionado en el foro aquí. Yo mismo busqué en los motores de búsqueda.
No lo guardé. Mencionado en el foro aquí. Busqué en los motores de búsqueda yo mismo.
Obviamente, todas estas motos han sido reconstruidas muchas veces. Incluso se publicaron libros, hasta implementaciones de asm.
Hoy en día es difícil encontrar lo básico, ya que casi todo el mundo utiliza APIs relevantes para todas las ocasiones.
Así que sólo tienes que registrarte en los foros y preguntar por ahí.
Obviamente, todas estas motos han sido reconstruidas muchas veces. Incluso se han publicado libros, hasta las implementaciones de asm.
Ahora es difícil encontrar lo básico, ya que casi todo el mundo utiliza las APIs pertinentes para todas las ocasiones.
Así que sólo tienes que registrarte en los foros y preguntar.
¿Por qué no utiliza LONG_MAX/MIN? De alguna manera se vería más decente. Se ve bien, creo. He reproducido tus pruebas con gcc (con mínimas modificaciones, claro, el compilador es el muy antiguo 5.4.0, lo que tenía a mano):
Bueno, sí, no es agradable. PeroLONG_MAX= 9223372036854775807 es más que 9007199254740992. Y la forma hexadecimal de este número - 0x20000000000000 se reprueba porque debe ser sólo para el tipo ulong. Ni siquiera sé cómo aclararlo. No puedo escribir (ulong)(1<<53) porque es una operación que requiere mucho tiempo.
El tipo double comienza a contener enteros sin partes fraccionarias no desde el valorLONG_MAX sino desde la máxima mantisa posible. Pero se permiten 53 bits para la mantisa, es decir, 2^53=9007199254740992.
Su código de sincronización falla - la salida está en milisegundos (no nano), y todavía no entiendo por qué necesitamos menos t0.
t0 es el tiempo del ciclo completo de 1000000 pases de la suma del doble primo
mientras que t es el tiempo del mismo ciclo de suma de los mismos valores dobles, pero pasado por las funciones ceil, ceil, round etc.
He partido de la lógica de que la diferencia (t-t0) es el tiempo neto empleado en estas funciones.
Por supuesto, sólo se puede conseguir una mayor objetividad realizando varias mediciones.
- En la nano se calcula sobre la base del tiempo que se tarda en realizar una función entre 1.000.000. Exactamente en nano es correcto.
pavlick_:
Ejecuté sus pruebas en gcc (con mínimas modificaciones, por supuesto, el compilador es muy viejo 5.4.0, lo que estaba a la mano):
1. Compilación con -O3.
2. Compilación con -Ofast
No escribir (ulong)(1<<53), pues ya es una operación que consume tiempo.
Esta operación no consume tiempo, como todas las operaciones con constantes, incluidas las cadenas.
Esta operación es intemporal como todas las constantes, incluidas las cadenas.
¡Vaya! ¡Genial! Gracias. Y yo pensaba que siempre cuenta. Sí, bueno, es lógico, ya se puede calcular en tiempo de compilación.
Bueno, eso es todo entonces:
Sin embargo, sería más correcto escribirDBL_MANT_DIG en lugar de 53
Caso de ganancia mínima si todos los valores del doble son fraccionarios.
Así que resulta. ¿Que el código MQL5 compilado funciona más rápido que incluso Ofast? Me resulta difícil creer que debe tener un compilador de 32 bits.
He quitado el menos t0 de todo (pensé que era algún tipo de error) y mi salida tiene todo el bucle medido, no una sola pasada. Si convertimos a su forma de salida en nanosegundos por iteración (en la primera línea "Cycle time without rounding" - tenemos la misma forma de contar), obtenemos:
No hay mucha aceleración en gcc (y aún más lento en -Ofast). En mcc hay un aumento de velocidad significativo a juzgar por tu prueba, pero:
tienes 985'651 de 1'000'000 es decir, casi todas las iteraciones satisfacen la condición x < MIN || x > MAX.
-Ofast desactiva todas las comprobaciones inf/nan, la configuración de errno, es decir, se deja el redondeo desnudo en la fpu. Y este redondeo desnudo no puede ser derrotado por una simple comparación de x < MIN || x > MAX.
No hay mucha aceleración en gcc (y aún más lento en -Ofast). En µl es significativo.
Sin embargo, es difícil decirlo. Tiramos t0 por buenas cifras y obtuvimos 20 veces de diferencia. Incluso un mínimo código adicional en forma de bucle (+t0) hace que el resultado sea bonito en varias decenas de veces a menos atractivo en unas dos veces. ¿Y qué decir si no es sólo un bucle sino un algoritmo real que hace algo útil? La diferencia no será visible en absoluto, se colgará en algún lugar muy posterior al punto decimal y apenas se convertirá en un cuello de botella. En una aplicación real la recogida de mutex, las barreras de la cpu, la asignación de memoria son mucho más costosas que el redondeo. En definitiva, no merece la pena la apuesta, en mi opinión.
Sí, la diferencia no será visible en absoluto, estará en algún lugar después del punto decimal y es poco probable que sea un cuello de botella. En una aplicación real tomar mutex, barreras de cpu, asignación de memoria son mucho más costosos que el redondeo. En definitiva, no merece la pena la apuesta, en mi opinión.
Esto es cierto el 99% de las veces, sí.
Antes de optimizar, debe asegurarse de que tiene algo que optimizar.
En mi práctica sólo recuerdo un caso en el que mi propia aplicación de la atof fue realmente útil. Aunque a mí me pareció que sí.
Y debes tener en cuenta que cualquier optimización (excepto ***) no es gratuita.