El lienzo es genial. - página 18
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
Parece que hay un malentendido sobre lo que se está hablando aquí. Me refería a un ejemplo de problema privado de Tester, donde los precios enteros pueden dar una ganancia en ciertas situaciones. El caso universal no estaba en mente. Por eso mi Tester, al que he dado el enlace más arriba, está implementado en los doblajes, ya que es universal.
No puedo estar de acuerdo al 100%.
Has hecho una afirmación:
Estoy casi seguro de que si haces que los ticks sean enteros, el Probador empezará a funcionar mucho más rápido.
Es absolutamente erróneo cuando se trata de aplicarlo en la práctica. Se equivoca el 100% de las veces en la práctica.
Así que no es necesario entrar en la teoría o la sustitución de temas. El tema es "el probador actual puede ser acelerado cuando se convierte en entero". Y el tema es 100% erróneo sin excepciones.
Has hecho una afirmación:
Es completamente erróneo cuando se intenta ponerlo en práctica. En la práctica es un error al 100%.
Así que no hace falta entrar en la teoría ni cambiar de tema. El tema es "el probador actual puede ser acelerado cuando se convierte en entero". Y el tema es 100% erróneo sin excepción.
Tenga en cuenta que esta es la única declaración mía en la que originalmente llevé la palabra Tester entre comillas. Ha entendido mal el punto que he planteado.
Se trata de un complemento de su Probador, que sin cambiar el código de ningún EA (con ningún indicador) hace una pasada completa con todas las operaciones y beneficios. Pero lo hace más rápido que el Tester normal. Se han dado todas las pruebas reproducibles. Personas del recurso han verificado estas afirmaciones.
Enséñales.
Y luego demostrar que se trata de cambiar a un mecanismo entero, no de que hayamos implementado ineficientemente un mecanismo u otro por descuido.
Si nos referimos al impacto de recalcular la base de posiciones abiertas, entonces hay verdaderos frenos ahí, que arreglaremos en los próximos días.Tenga en cuenta que esta es la única declaración mía en la que la palabra Tester fue tomada originalmente por mí entre comillas. Has entendido mal el tema que se ha planteado.
He acertado.
Y abordó correctamente el tema con detalles desagradables para ti. Si crees que no hemos calculado el probador de enteros, estás muy equivocado.
Muéstrame.
Espectáculo.
Y luego demostrar que se trata de cambiar a un mecanismo entero, no de que hayamos implementado ineficientemente un mecanismo u otro por descuido.
Abandoné los probadores de enteros porque no eran versátiles. Eran más rápidos, pero había más desventajas que ventajas. Sin embargo, como fenómeno, pueden existir. Trabajo virtual - en los doblajes.
¡Eso sería genial!
Te lo enseño.
¿Este?
https://www.mql5.com/ru/forum/285631/page107#comment_10271917
Estoy bastante seguro de que si haces que los ticks sean enteros, el "Tester" será mucho más rápido.
He comparado la velocidad de double e int en estos dos scripts idénticos:
Sorprendentemente, la variante dominada por el doble fue incluso ligeramente más rápida en mi CPU.
Salió muy bien.
Conseguí 347 fps sin antialiasing y 97 con antialiasing en un lienzo de 2100x550 píxeles.
A título informativo, tenemos un limitador de velocidad de actualización de ventanas de 500 fps. Esto demuestra el rendimiento que se puede conseguir en los gráficos.
Gracias.
En realidad, con el antialiasing los círculos dobles son más lentos que los círculos int originales sin antialiasing en un 20% aproximadamente. Tengo 300 vs 250 fps.
Es que por lo visto has estado midiendo círculos antialiasing con sombras, y la sombra de un círculo es mucho más voraz que el propio círculo. La sombra se puede desactivar con el parámetro dibujar una sombra? = falso.
He comparado la velocidad de double e int en estos dos scripts idénticos:
Sorprendentemente, la variante dominada por el doble fue incluso ligeramente más rápida en mi CPU.
Cuidado con las conversiones masivas como (int)double o (double)int y la mezcla de int+double en las operaciones matemáticas en general.
Esto da la sobrecarga más salvaje en el procesador - sólo un comando ensamblador tan caro. Si estás contando en doble, sigue contando en él y no cambies a tipos enteros.
Comandos como cvtsi2sd/cvttsd2si son muy largos. Un pequeño consejo en el artículo"La instrucción x86 más lenta", villano número 2.
El Manual de Referencia de Optimización de las Arquitecturas Intel® 64 e IA-32 dice que el coste de la instrucción cvtsd2si es de 5 latencias (ver Apéndice C-16). cvtsi2sd, dependiendo de su arquitectura, tiene una latencia que varía desde 1 en Silvermont hasta más bien 7-16 en varias otras arquitecturas.
Lastablas de instrucciones de Agner Fog tienen números más precisos/sensibles, como la latencia de 5 ciclos para cvtsi2sd en Silvermont (con un rendimiento de 1 por cada 2 relojes), o la latencia de 4c en Haswell, con un rendimiento por cada reloj (si se evita la dependencia del registro de destino de la fusión con la mitad superior antigua, como suele hacer gcc con pxor xmm0,xmm0).
Gracias.
En realidad, con el antialiasing los círculos dobles son más lentos que los círculos int originales sin antialiasing en un 20% aproximadamente. Tengo 300 vs 250 fps.
Es que por lo visto has estado midiendo círculos antialiasing con sombras, y la sombra de un círculo es mucho más voraz que el propio círculo. La sombra se puede desactivar con el parámetro dibujar una sombra? = falso.
Resulta que estaba mirando la frecuencia de generación de la red, no la frecuencia de salida.
Son números diferentes, múltiplos uno del otro.