¡Necesito ayuda! No puedo resolver el problema, me encuentro con limitaciones de hardware - página 19
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
Por lo tanto, ¡habría que recorrer varios millones de ofertas de otras secuencias! Ese es exactamente mi punto.
Bueno, estoy hablando de comprobar un solo número (número de secuencia), un millón no es tanto para una operación tan elemental. Si contamos el criterio de forma recursiva, es sólo una pasada del archivo, y tendremos que hacerlo de todos modos. Otra cosa a tener en cuenta es que el mapa de datos de la recursión contendrá los mismos varios millones de elementos (multiplicados por el número de parámetros de una secuencia).
Otra alternativa es recalcular y almacenar completamente los criterios antes de la clasificación. De nuevo, la posibilidad de utilizar la recursividad es fundamental.
Está claro que habrá muchas operaciones, pero ¿son menos en la versión original?
En C++ se puede hacer sin parser si:
empujando la idea 10 veces - iniciar otro archivo con los valores de las posiciones de inicio de las secuencias en otro archivo, entonces usted ni siquiera necesita para almacenar el número de operaciones en la estructura de la secuencia.
Obtendrá un índice ordinario, que ya se ha mencionado anteriormente.
He implementado el algoritmo que he descrito anteriormente.
El procesamiento de mis datos con X = 20 (cálculo del criterio en 20 tratos) tomó alrededor de112 minutos (no lo atrapó exactamente), la parte del león se la comió el desplazamiento de la matriz (40% según el perfilador).
Tras los bucles de las matrices y alguna otra optimización, el procesamiento se hizo más rápido:
La memoria sólo era suficiente para 65 transacciones (multiplicadas por un millón de secuencias). Esto, por supuesto, no es suficiente - contaba con al menos 100.
El siguiente paso fue descartar toda la información innecesaria sobre los oficios. Dejando sólo los tiempos de apertura y cierre, y el beneficio en pips, consiguió despegar con X = 185.
Siguiente - sólo acelerar el trabajo con el archivo, FileReadXXX ahora toma el 30% del tiempo (y el despachador dice que no hay trabajo con el disco, pero la CPU está cargada).
FileRead es exactamente el primero después de FileSeek, es decir, la lectura secuencial funciona rápidamente.
Le informaré de los nuevos resultados.
En C++ se hace por fread en un buffer de 64K-128K, analizándolo mejor por su propio parser, porque los sscanf-es son muy lentos.
Intentaré trabajar con los archivos a través de WinAPI, me lo ha aconsejado el servicio técnico:
Estoy empujando la idea 10 veces - para iniciar otro archivo con los valores de las posiciones iniciales de las secuencias en otro archivo, a continuación, en la estructura de la secuencia ni siquiera será necesario almacenar el número de ofertas.
No entiendo qué hará el índice.
Escribir el número de operaciones no supone ninguna diferencia, la lectura secuencial funciona rápidamente, el problema es exactamente la lectura del bloque después de moverse por el archivo.
Por favor, escriba un algoritmo sugerido.
El problema no es trivial, pero todavía no hay una sola línea de código. Andrey, aquí hay mucha gente interesada: formula el problema y ofrece datos de prueba. Vamos a organizar una programación deportiva.
Necesitamos datos de prueba + pseudocódigo, con principios generales de trabajo con datos.
La tarea se formula de principio a fin.
Y los datos de la prueba se pueden generar con un script ligeramente modificado, que he publicado antes.
Lo haré un poco más tarde.
¿por qué pasar por las opciones de la base? ¿sería mejor generar operaciones sobre el historial según los criterios? ¿no? ¿no sería lo mismo que lo que se requiere?
Si es para pruebas, por supuesto que sí, pero si es para resolver el problema, por supuesto que no )
Candidato:
Bueno, estamos hablando de comprobar un solo número (número de secuencia), un millón no es tanto para una operación tan elemental. Si consideramos el criterio de forma recursiva, es sólo una pasada de archivo, tendremos que hacerlo de todas formas. Otra cosa a tener en cuenta es que el mapa de datos de la recursión contendrá los mismos varios millones de elementos (multiplicados por el número de parámetros de una secuencia).
Otra alternativa es recalcular y almacenar completamente los criteriosantes de la clasificación. De nuevo, la posibilidad de utilizar la recursividad es fundamental.
Está claro que habrá muchas operaciones, pero ¿hay menos en la versión original?
En la variante inicial, se puede calcular el criterio una vez al encontrar la última transacción del historial pasado.
Y hay que leer un fragmento del archivo tal que contenga X número de tratos de todas las secuencias. Será mucho mayor que X *número de secuencias, porque hay diferentes cantidades de tratos y pueden no estar distribuidos uniformemente.
2 todos:
De todos modos, gracias por el apoyo.
Si no te importa, por favor, ejecuta el script de prueba y comparte los resultados.
Y los datos de prueba se pueden generar con el script ligeramente modificado que he publicado antes.
Adjunto el script actualizado, ahora no se limita a registrar operaciones idénticas, sino que genera secuencias aleatorias con los ajustes especificados(duración - desde y hasta, beneficio - desde y hasta).
Para obtener un archivo comparable al mío, ejecute el script con la configuración por defecto:
2014.08.28 04:12:36.044 sTest_ReadWriteBIN EURUSD,M15: 140.000 secuencias de escritura en 57,1 segundos
2014.08.28 04:13:20.688 sTest_ReadWriteBIN EURUSD,M15: 6632 Mb cargados en 44,0 seg(150,7 MB/seg)
Después de eso, puedes elaborar el algoritmo en él.
Para los más perezosos, archivar el archivo en google drive.
komposter:
1. En la variante original se puede calcular el criterio una vez al encontrar la última operación del historial pasado.
En su variante, necesita leer un archivo de este tipo, que contenga X tratos de todas las secuencias. Será mucho mayor que X *número de secuencias, ya que el número de tratos es diferente y pueden no estar distribuidos uniformemente.
1 Esto no está muy claro, si buscamos el criterio máximo (mínimo), todavía tenemos que calcular el criterio para todos los candidatos al final. Ni siquiera importa si se busca un extremo local o global.
2. Evidentemente, lo más importante es la cuestión del tamaño aceptable o no en cuanto a la memoria necesaria. Además, un tamaño de bloque mayor en términos de velocidad de lectura del disco es aún mejor. Ciertamente, todavía no es un problema para la RAM. Es fundamental que la lectura sea secuencial y que sólo se realice una vez.
Sin embargo, la variante de calcular los criterios antes de clasificar requiere una doble lectura. Pero tiene sus propias ventajas, sobre todo teniendo en cuenta la posibilidad de dividir los datos en varios archivos más pequeños y su posterior tratamiento conjunto.
Sin embargo, sin la aplicación, todos los argumentos seguirían siendo abstractos. Así que en este punto de la discusión tendré que despedirme :)
Cómo hacer la costura de archivos con la indexación de qué bit es el principio y el final de cada archivo.
Por ejemplo, hacer 1000 metafichas de 1000 archivos, y si se conocen los criterios, hacer una ordenación estadística para encajar archivos similares en una metaficha.
Mejor experimenta con FileOpen, ¿cómo funciona más rápido para abrir un archivo grande o uno pequeño, en el sentido de abrir 1000 veces un archivo grande igual en tamaño a 1000 pequeños o 1000000 veces para abrir uno pequeño?
Puede resultar que los archivos no deban fusionarse, sino dividirse.
Cómo hacer la costura de archivos con la indexación de qué bit es el principio y el final de cada archivo.
Por ejemplo, hacer 1000 metafichas de 1000 archivos, y si se conocen los criterios, hacer una ordenación estadística para encajar archivos similares en una metaficha.
Mejor experimenta con FileOpen, ¿cómo funciona más rápido para abrir un archivo grande o uno pequeño, en el sentido de abrir 1000 veces un archivo grande igual en tamaño a 1000 pequeños o 1000000 veces para abrir uno pequeño?
Puede resultar que los archivos no deban fusionarse, sino dividirse.
Actualmente estoy trabajando con un archivo grande, pero quería pasar a un millón de archivos pequeños.
En primer lugar, se pueden anexar y, en segundo lugar, se puede acceder a ellas por su nombre (no es necesario almacenar el "inicio de cada secuencia").
He preguntado en el servicio de atención al cliente sobre un millón de aperturas de diferentes archivos (tengo la caché implementada de esa manera). La respuesta es clara y directa.
Probaré las funciones api tanto para un archivo grande como para millones de archivos pequeños, publicaré los resultados.
Sin embargo, sin la implementación, todos los argumentos seguirán siendo abstractos. Así que en este punto de la discusión sería apropiado que me retirara :)
Debería haber empezado con ello ;)
Pero en cualquier caso, gracias por tu participación, las ideas sin código también son valiosas.
Con un millón de archivos arruinarás ntfs de tal manera que llorarás por esta locura de microsoft, que ha encerrado a todo el mundo para siempre en su implementación insanamente lenta del sistema de archivos.
Todo lo que ha hecho ms en sus sistemas de archivos es un peso monstruoso, un retraso y una estupidez. Joder, estos idiotas no han hecho ningún esfuerzo de optimización y velocidad, y la api es simplemente primitiva. En 2014 esto se puede afirmar de forma inequívoca. Bueno y llora.
Cualquiera que quiera mejorar la eficiencia del manejo de un montón de archivos en Windows, lo primero que hace es ir a trozos - agrupación y su propia estructura de datos dentro de un solo archivo.
Una vez que empiezas a almacenar más de mil (y mucho menos decenas o cientos de miles) de archivos dispares en windows, estás jodido.
Las operaciones de archivo en MQL4/5 pasan por nuestros eficientes mecanismos de caché, que nos permiten alcanzar velocidades de lectura y escritura muy eficientes y elevadas.
Puedes transmitir los datos byte a byte: todos ellos se recogerán rápidamente en el búfer interno y se escribirán en el disco sólo en trozos grandes. El número de llamadas a la WinAPI es mínimo, lo que proporciona un funcionamiento de alta velocidad. La lectura es similar: funciona de forma proactiva, leyendo en grandes trozos, llamando muy raramente a la WinAPI y devolviendo muy rápidamente los datos de su caché con una sobrecarga mínima.
A grandes rasgos, en comparación con la compilación 509, hemos aumentado la velocidad de las operaciones de archivo en MQL4/5 en un orden de magnitud (si nos referimos a la operación regular basada en trozos, en lugar de "escribir por bloques de megabytes para maximizar las mediciones de velocidad").