¡Necesito ayuda! No puedo resolver el problema, me encuentro con limitaciones de hardware
komposter:
¿Algún consejo, amigos? Me encargaré de ello).
Como opciones...
1. Crea tu propia caché. En este caso, tú controlas lo que hay en la memoria. Conoces el algoritmo, así que puedes hacer que la caché sea eficiente.
2. Utiliza el mapeo para el archivo. Wind guardará en caché lo que necesite y no borrará el disco duro.
Como opciones...
1. Crear tu propia caché. En este caso, podrás gestionar tú mismo todos los contenidos.
2. Utilizar el mapeo para el archivo. El propio vin almacenará en caché lo que necesite, de modo que no sobrescribirá el disco.
1. este es el caché... O no entiendo lo que quieres decir. ¿Mi opción de leer constantemente los trozos necesarios?
2. ¿Puede explicarse un poco más? ¿Qué hará el mapeo y qué manera de abordarlo?
Oh, mierda...
32-битные архитектуры (Intel 386, ARM 9) не могут создавать отображения длиной более 4 Гб
Los mismos huevos, pero de lado. La lectura puede acelerar, pero no resuelve el problema globalmente.
Otra idea es pasar todo a una base de datos (¿MySQL?) y trabajar con ella. La idea es que las bases de datos están diseñadas para esos volúmenes y la excavación constante.
¿Hay algún experto? ¿Quién tiene algo que decir?
1) ¿Hay alguna forma de rehacer el algoritmo? Cargar un bloque (2GB), procesarlo, guardar el resultado (más corto), liberar memoria, cargar el siguiente bloque...
y al final, volver a procesar todos los resultados.
2) Cuando hay mucho trabajo con la memoria, se asocian las soluciones basadas en hash, los árboles B (y sus modificaciones), la descarga a la base de datos.
1) ¿Hay alguna forma de rehacer el algoritmo? Cargar un bloque (2GB), procesarlo, guardar el resultado (más corto), liberar la memoria, cargar el siguiente bloque...
y al final, volver a procesar todos los resultados.
2) Cuando hay mucho trabajo con la memoria, se asocian las soluciones basadas en hash, los árboles B (y sus modificaciones), la descarga a la base de datos.
1. Ya lo escribí: se puede, pero el problema es que hay que procesar los datos varias veces. Será muy lento.
2. Mañana me buscaré en Google, agradeceré una breve descripción.
1. He escrito sobre ello: se puede, pero el problema es que hay que procesar los datos varias veces. Sería muy lento.
2. Mañana me buscaré en Google, te agradecería una breve descripción.
Recordé un sitio donde se discutía un problema similar y variantes de su solución en C++.
- www.fulcrumweb.com.ua
1. Naturalmente, utilice un sistema x64.
2. alquilar una máquina más potente en la nube de Amazon EC2 y hacer los cálculos en ella.
3. utilizar datos comprimidos, descomprimir en memoria sobre la marcha. Los datos reales se comprimen mejor si se dividen en flujos (signo/mantisa/exponente); se puede utilizar float de 12 bits (a costa de la precisión).
4. hacer un cálculo fuera de la asesoría con algo que pueda manejar big data (Matlab/R/etc).
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Usted acepta la política del sitio web y las condiciones de uso
Hay una gran cantidad de información (unos 20 GB en un archivo de texto).
La información consiste en el mismo tipo de secuencias, alrededor de un millón de ellas.
Es necesariorepasar todas las secuenciasrepetidamente y hacer algunos cálculos.
Lo primero que se nos ocurre es leer todo el contenido del archivo, llenar el array de estructuras con él y trabajar con ellas en memoria.
Pero no funcionó, con el siguiente redimensionamiento MT jura "Memory handler: cannot allocate 5610000 bytes of memory".
Dispatcher muestra que terminal.exe utiliza 3,5 GB de RAM (de 16 físicos). Supongo que esto se debe a que el proceso sólo puede obtener 4GB.
EA dice "¡¡¡No hay suficiente memoria(4007 Mb utilizados, 88 Mb disponibles, 4095 Mb en total)!!!".
Y esto es sólo el 15,3% de la cantidad requerida (y me gustaría aumentarla también en el futuro).
Opción 2 - leer cada vez el archivo. Encontrar la pieza necesaria, guardarla en la estructura, leer la siguiente pieza, comparar el resultado, sobrescribir la estructura.
Y si tuviera que pasar por estas secuencias una vez, eso es lo que haría. Pero hay que pasar por ellos muchas veces, avanzando un poco cada vez.
Así que tienes que leer un montón de veces, que es:
También es frustrante la cantidad de información que hay... Si fueran 10 GiG, lo pasaría a disco RAM (de hecho, a la memoria) y leería todo lo que pudiera. ¿Sí?
Eso es todo lo que se me ocurre.
¿Intentar recompilar estas secuencias, de modo que haya muchas piezas, pero cada una conteniendo sólo la información necesaria en el momento?
¿También tratar de comprimir los datos (ya he convertido a floats con tipos char en todos los lugares que puedo)? Pero me dará un 10%-20% más como mucho, y necesito reducir el volumen en un orden de magnitud...
¿Algún consejo, amigos? Lo conseguiré.)