Errores, fallos, preguntas - página 2284
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
Los ticks no se almacenan en la RAM. Se descargan a medida que se necesitan, poco a poco, según tengo entendido.
Si por garrapatas reales, entonces sí.
En una sola pasada, puede ver las estadísticas sobre la cantidad de memoria que se gasta en el almacenamiento de ticks. Cuando se optimiza, no se almacenan más de 320 megas en la memoria a la vez. El resto se almacena en el disco.
Ahora estamos considerando una solución para mantener todos los ticks en la memoria compartida, para que todos los agentes locales puedan leer de esta memoria. Entonces no habrá accesos al disco, y la optimización será más rápida.
Si por garrapatas reales, sí.
Es posible ver estadísticas sobre la cantidad de memoria que se gasta en el almacenamiento de ticks en una sola pasada. Cuando se optimiza, no se almacenan más de 320 megas en la memoria a la vez. Todo lo demás está en el disco.
Ahora estamos considerando una solución para mantener todos los ticks en una memoria compartida para que todos los agentes locales puedan leer de esta memoria. Entonces no habrá accesos al disco y la optimización será más rápida.
Sí, esto es de archivo. Si he entendido bien, ahora los ticks y las barras de minutos se almacenan sin empaquetar en el disco y en la memoria, es decir, para la barra(estructura MqlRates) son 60 bytes, y para el 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 organizar el acceso rápido a cada elemento de la matriz.
Pero incluso si mantenemos desempaquetado sólo cada 256º elemento del array, y almacenamos en los otros elementos sólo incrementos a los desempaquetados, podemos ver que el tamaño del array se reducirá en 4-5 veces y el tiempo de acceso a cada elemento no aumentará mucho (quizás 1-2 nanosegundos), pero ahorrará un tiempo enorme en guardar y leer el array desde el disco y hacia el disco.
¿Por qué el SSD se dirige constantemente (la luz parpadea a gran velocidad) durante la optimización?
Por eso no utilizo ticks, utilizo estructura de datos logarítmica (ya lo he contado), que en un momento dado consta de un par de miles de ticks, luego un par de miles de barras de minutos, 2000 M2, 2000 M5 , M10, M30, H1, H3, H6, H12, D1, W1... todas las barras MN1.
Esta estructura de datos del historial completo se forma en cualquier momento de tiempo inferior a un milisegundo y ocupa sólo 1,5 MB en la memoria RAM (en realidad ni siquiera en la RAM, sino en la caché del procesador). Y todos los algoritmos, fundados para esta estructura, simplemente vuelan.
Al fin y al cabo, nuestra vista se basa en la misma escala logarítmica: cuanto más lejos miramos, menos notamos los pequeños detalles.
Cuando en un futuro no muy lejano los ordenadores sólo tengan un dispositivo de memoria física (disco duro, memoria RAM, caché del procesador), es decir, la caché del procesador con 13 ceros, entonces yo también haré el cambio a los ticks :))
...
Aunque, tal vez sea yo el que se quite de en medio, ya que con una estructura de datos así durante la optimización la bombilla también parpadeará. Después de todo, las garrapatas seguirán cargando :((
Si por garrapatas reales, sí.
Es posible ver estadísticas sobre la cantidad de memoria que se gasta en el almacenamiento de ticks en una sola pasada. Cuando se optimiza, no se almacenan más de 320 megas en la memoria a la vez. Todo lo demás está en el disco.
Ahora estamos considerando una solución para mantener todos los ticks en la memoria compartida, para que todos los agentes locales puedan leer de esta memoria. Entonces no habrá acceso al disco, y la optimización será más rápida.
En primer lugar, empecemos con 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 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 Optimize? Es extraño que el sistema operativo no almacene en caché estos datos, ya que son menos de 7MB de ticks en forma descomprimida.
Pero incluso si almacenamos sólo cada 256º elemento de un array sin empaquetar y almacenamos sólo los incrementos de los elementos sin empaquetar, el tamaño de un array se reducirá en 4-5 veces mientras que el tiempo de acceso a cada elemento no aumentará mucho (quizás en 1-2 nanosegundos), pero se ahorrará un tiempo enorme en guardar y leer un array desde el disco y hacia el disco.
Renate no es suficiente para ti ) Cuántas veces se ha sugerido optimizar el almacenamiento del historial. Sobre todo porque no hay que gastar nada en la compresión (que es la parte que más recursos consume), porque los datos vienen inicialmente del servidor comprimidos, y sólo se mantiene la caché, que se usa constantemente, sin comprimir... Pero ahí es donde siempre viene el sermón: si no puedes comprar un disco duro más grande o más rápido, no hay nada que hacer en una MT. Y siempre se mencionan los VPS lentos por alguna razón.
Renate no es suficiente para ti ) Cuántas veces se ha sugerido optimizar el almacenamiento del historial. Sobre todo porque no hay que gastar nada en la compresión (que es la parte que más recursos consume), ya que los datos vienen originalmente del servidor comprimidos, y sólo la caché, que se utiliza constantemente, se mantiene sin comprimir... Pero ahí es donde siempre viene el sermón: si no puedes comprar un disco duro más grande o más rápido, no hay nada que hacer en una MT. Y siempre se mencionan los VPS lentos por alguna razón.
Una vez más, el principal problema de las matrices empaquetadas es organizar el acceso rápido a cualquier elemento de la matriz, en lugar de leerlos secuencialmente. Por eso, en este caso se necesita un formato de compresión diferente (o más bien un formato de almacenamiento), sí, de manera que no sea necesario desempaquetar y empaquetar. La compresión de ~10 veces como para zip, png, etc. por supuesto no funcionará, pero creo que 5 veces es posible.
Bueno, en realidad, si lo pensamos bien, en MqlRates se asignan 8*4=32 bytes para almacenar la información de los compases de un minuto (mientras que sólo se almacenan los compases de un minuto), aunque en el 99% de los casos estos valores difieren en menos de un byte de información, es decir, 8+1+1+1=11 bytes son casi suficientes, incluso si no están vinculados a los compases anteriores. Y el tiempo en el 99 % de los casos difiere del valor anterior exactamente en 60 (es decir, en el 99 % de los casos basta con 1 bit de información - 60 o no 60). Y también se asignan 8 bytes para esto.
Una vez más, el principal problema de las matrices empaquetadas es organizar el acceso rápido a cualquier elemento de la matriz, en lugar de leerlos secuencialmente. Por eso, en este caso se necesita un formato de compresión diferente (o más bien un formato de almacenamiento), sí, de manera que no sea necesario desempaquetar y empaquetar. Por supuesto, zip, png, etc. no pueden ser comprimidos ~10 veces, pero creo que 5 veces es posible.
Si hablamos de almacenamiento en disco, el acceso a un elemento específico no tiene sentido, porque la operación de archivo en sí es costosa. Por lo tanto, se lee un gran trozo de una vez. Por ejemplo, los archivos del historial de bares se desglosan por año, y los ticks por mes. Y si te refieres a mantener la historia en la memoria de forma empaquetada, desempaquetando constantemente cada elemento sobre la marcha, entonces me temo que no le conviene a nadie.
Acabo de inventar un formato de almacenamiento que almacena bloques de 256 elementos MqlRates y ocupa 2900 bytes de media (el tamaño del bloque será flotante), es decir, se asignarán 2900/256= ~12 bytes por estructura MqlRates, que es 5 veces menos, como pensaba.
El acceso a cada elemento de la estructura MqlRates empaquetada es suficientemente rápido (2-3 sumas, 2-3 comprobaciones, 2-3 desplazamientos, es decir, apenas más de 1 nanosegundo)
Si hablamos de almacenar en disco, el acceso a un elemento concreto no tiene sentido, porque la operación de archivo en sí es costosa. Por lo tanto, se lee un trozo grande de una sola vez. Por ejemplo, los archivos del historial de bares se dividen por años, los ticks se dividen por meses. Y si te refieres a mantener la historia en la memoria de forma empaquetada, desempaquetando constantemente cada elemento sobre la marcha, entonces me temo que no le conviene a nadie.
Se almacenará en el disco en un formato "comprimido" y también se leerá en la memoria en el mismo formato. No habrá conversión a un formato completo, sino que sólo habrá un cálculo en el momento de la lectura de un elemento específico de la estructura MqlRates. Y será mucho más rápido, teniendo en cuenta que habrá cinco veces menos trabajo con el disco.
El acceso a cada elemento de una estructura MqlRates empaquetada es bastante rápido
...
Se almacenará en el disco en un formato "comprimido" y se leerá en la memoria en el mismo formato. No habría ninguna conversión a un formato completo, sino sólo los cálculos resultantes en el momento de la lectura de un elemento concreto de la estructura MqlRates.
Sí, pero el concepto de "rápido" en tu caso es muy relativo. Una cosa es que el usuario pidiera un array de barras, simplemente copiara alguna zona de memoria, o pidiera alguna serie temporal concreta, 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.d. Aunque lo ideal sería tener esa opción en el terminal para elegir cómo se almacena el historial en la memoria. Por ejemplo, si el sistema tiene poca RAM, pero un procesador rápido, esto sería muy útil.