Errores, fallos, preguntas - página 2285
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
Sí, pero la noción de "rápido" en su caso es muy relativa. Una cosa es que un usuario solicite un array de barras - se le acaba de copiar una zona de memoria, o que solicite una serie temporal concreta, entonces también es un simple copiado de datos con paso constante, igual al tamaño de la estructura. Y otra cosa son los cálculos y conversiones adicionales sobre cada número.
Aunque, personalmente, preferiría tener un historial comprimido, para no malgastar memoria, porque de todos modos estoy organizando mis propias matrices para almacenarlo. Así que estoy dispuesto a tolerar un pequeño retraso. Pero la mayoría de los demás usuarios te harían pedazos por ello )
p.s. Aunque lo ideal sería tener una opción de este tipo en el terminal, para elegir el modo de almacenar el historial en la memoria. Por ejemplo, si el sistema tiene poca RAM, pero un procesador rápido, sería muy útil.
Pues mira. Acabo de medir las velocidades de escritura y lectura de mi SDD. Resultó que el tiempo de escritura y lectura de 8 bytes (1 tipo de valor double o datetime o long) ~ 48 ns. Y según mis cálculos el tiempo de lectura de 8 bytes de información desde un array empaquetado es de 1-2 ns. Así, mientras que perdemos 1-2 ns en el acceso a un elemento de la estructura, ganamos 48*0,8 = 38 ns para la escritura y la lectura del disco. Además, tenemos una memoria RAM y un espacio en disco 5 veces mayor. Incluso no hablo del disco duro.
Pues mira. Acabo de medir la velocidad de lectura y escritura de mi SDD. Resulta que el tiempo de escritura y lectura de 8 bytes (1 tipo de valor double o datetime o long) ~ 48 ns. Y según mis cálculos el tiempo de lectura de 8 bytes de información desde un array empaquetado es de 1-2 ns. Así, mientras perdemos 1-2 ns en el acceso a un elemento de la estructura, ganamos 48*0,8 = 38 ns para la escritura y la lectura del disco. Además, tenemos un ahorro de memoria y espacio en disco 5 veces mayor, y ni siquiera hablo del disco duro.
No lo discuto. Hace 4 años tuvimos una discusión con Renat sobre este tema, en el momento en que los SSD eran todavía bastante infrecuentes y la gran mayoría de los usuarios estaban sentados en lentos HDD.Así que yo (con el ejemplo de mi SSD) intenté convencerle de que el funcionamiento del HDD es el eslabón más lento del sistema y que deberíamos intentar minimizar la cantidad de datos que se consumen de él, y no al revés. Pero él tenía argumentos de este tipo: no es necesario sobrecargar la CPU con trabajo extra, y todos vosotros sois tontos, no entendéis nada, etc. En general, todo como siempre )
Es cierto que las SSD se han acelerado significativamente en estos días.
Resultaque el tiempo de escritura y lectura es de 8 bytes
Foro sobre trading, sistemas de trading automatizados y pruebas de estrategias de trading
Bichos, errores, preguntas
fxsaber, 2018.09.10 21:28
Primero, el registro de optimización.
Tester optimization finished, total passes 714240 Statistics optimization done in 7 hours 31 minutes 06 seconds Statistics local 714240 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%) Core 1 connection closed Core 2 connection closed Core 3 connection closed Core 4 connection closed Core 5 connection closed Core 6 connection closed Core 7 connection closed Core 8 connection closed Tester 714240 new records saved to cache file 'tester\cache\Test.FILTER_EURUSD.rann_RannForex.M1.20180226.20180909.40.2D734373DF0CAD251E2BD6535A4C6C84.opt'Durante esas 7,5 horas, se accedió al SSD con una enorme frecuencia. Si los ticks se leen en cada pasada, eso supone una media de 26 veces por segundo durante 7,5 horas. De ahí un parpadeo tan salvaje: más de 700 mil lecturas.
Registro de una carrera
Como se ve, se utilizan ~130K ticks y 60K barras (el modo "Todo el historial" está seleccionado en el Probador). Es decir, una cantidad muy pequeña de historia.
El historial del símbolo personalizado en el Terminal contiene la siguiente cantidad de datos del historial
Es decir, en la historia del símbolo es muy poco más de lo que utiliza el Probador.
ZS Es una pena mirar el SSD... ¿Cuánto más rápido podría ser el Optimise? Es extraño que el sistema operativo no almacene en caché estos datos, ya que son menos de 7MB de ticks en forma descomprimida.
¿Qué carpeta de Terminal a través de mklink a RAM-disco, de modo que los datos no se lee / escribe desde SSD, pero a partir de la memoria? Estoy dispuesto a proporcionar los datos, qué tipo de speedup esto daría en la optimización.
Sí, esto es de archivo. Si he entendido bien, ahora los ticks y las barras de minutos se almacenan sin empaquetar, es decir, para una barra(estructura MqlRates) son 60 bytes, y para un tick(estructura MqlTick) son 52 bytes.
¡Es horrible! Hay que hacer algo al respecto desde hace mucho tiempo.
Entiendo que el principal problema de las matrices comprimidas es la organización del acceso rápido a cada elemento de la matriz.
Pero incluso si almacenamos sólo cada elemento 256 de un array desempaquetado y almacenamos en otros elementos sólo incrementos a los desempaquetados, podemos ver que el tamaño del array será 4-5 veces menor y el tiempo de acceso a cada elemento no aumentará demasiado (quizás 1-2 nanosegundos), pero ahorrará un tiempo enorme en guardar y leer el array desde el disco y hacia el disco.
"Todo ha sido ya robado antes que tú" (cz)
Al principio del día es una garrapata completa. Luego oferta y/o demanda y/o flipper completo, todo lo demás en incrementos si está disponible. Una media de 10 bytes por tic.
Dado que el acceso a los ticks es estrictamente secuencial, no hay problema en organizar el acceso rápido a cada elemento de la matriz
Una gran petición para publicar la fuente del registro "Tester\cache\*.opt". En el contenido se puede ver que el formato es muy sencillo.
Es muy necesario trabajar con los resultados de la optimización. Gracias.
Por alguna razón, el rendimiento del probador disminuye a medida que aumenta el número de operaciones. No hay ninguna referencia al historial de operaciones por parte del Asesor Experto.
No parece que este sea el caso.
En el Comprobador, se memoriza el intervalo correspondiente al modo "Todo el historial". Agrego el historial al símbolo personalizado, vuelvo a cargar el Terminal y el intervalo correspondiente a "Todo el historial" no cambia.
No puedo cambiar el modo por defecto, pero si selecciono todo el historial, lo pongo manualmente. Por favor, corrige.
Falta una cruz en el lugar marcado - borrando la línea correspondiente de la entrada de la caché.
Hago muchas optimizaciones. Algunos están desfasados desde hace mucho tiempo. Y no hay ningún mecanismo para eliminar estas opciones. A veces se obtiene una lista enorme y se empieza a buscar entre variantes innecesarias.
Por lo tanto, considere la posibilidad de eliminar los datos innecesarios mediante una cruz en el lugar marcado en la imagen.
Error durante la ejecución
Resultado: verdadero:falso:7:4
¿Cómo es que cuerdas de diferente longitud son de repente iguales? Mientras que la comparación mediante StringCompare da el resultado contrario ==
Gracias por el post, hemos cambiado el comportamiento de la comparación de cadenas carácter por carácter.
Antes las cadenas se comparaban como cadena Z (hasta el carácter nulo), ahora se comparan como cadena PASCAL (teniendo en cuenta la longitud).
Los códigos existentes con cadenas "normales" (sin caracteres Z dentro) no se verán afectados por este cambio.