¡Necesito ayuda! No puedo resolver el problema, me encuentro con limitaciones de hardware - página 2

Nuevo comentario
 
ALXIMIKS:

Recordé un sitio donde se discutía un problema similar y variantes de su solución en C++.

Gracias, lo leeré.

Ivan Ivanov:
Lo siento, ¿qué pasa si trato de 64 bits o mt sólo girará 32
Ingenuamente pensé que una cosa tan altamente matemática debería girar en 64 bits
Por ejemplo, los programas de cálculo aerodinámico no funcionan en 32 bits.
sobre el argumento principal de que 32x es más rápido para hacer funcionar un ordenador lo sé, pero es un problema de hardware imho

El cambio a x64 sólo empuja el techo hacia atrás, y no muy lejos. No tendré que salir corriendo a comprar 16Gb de memoria. ;)

 
anonymous:

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).

1,2: se trata de hacer retroceder el techo, y se quiere resolver el problema sin estar atado a una cifra concreta.

3. El problema no es la cantidad de datos en el disco, sino la cantidad en la memoria. Puedo comprimirlo otro 10-20%, pero de nuevo, eso no resolverá el problema.

4. Mantengo la esperanza de permanecer en la caja de arena por ahora. Para no tener que escribir copiadores/sincronizadores después...

Gracias por su participación.

 
komposter:
Pasar a x64 sólo haría retroceder el techo, y no muy lejos. No tengo que salir corriendo a comprar otros 16 Gb de memoria, ¿verdad? ;)

No trabajas con este tipo de datos todo el tiempo, ¿verdad? Escriba para x64 y ejecútelo en amazon cuando lo necesite. También puedes depurar allí en la micro instancia.

Sin embargo, si te enfrentas a este problema todo el tiempo, puedes comprar una memoria de 64 GB por unos 1.000 dólares, por ejemplo. Corsair Vengeance Pro CMY64GX3M8A2133C11.

O bien replantear el diseño del algoritmo para que pueda trabajar en una sola pasada sobre los datos

p.d. También puede almacenar los datos comprimidos en la memoria, y descomprimirlos cuando sea necesario durante el tiempo suficiente para procesarlos

 
komposter:

Gracias, lo leeré.

Pasar a x64 sólo hará que el techo retroceda, y no muy lejos. No voy a salir corriendo a comprar otros 16 GB de memoria, ¿verdad? ;)

Tienes que estar bromeando :-)
soy un tonto con 8gig para jugar
 

Opción 1: Cortar la lima en trozos.

Opción 2: Cortar el archivo en pedazos, pero también sistematizarlo. Como una palabra del diccionario. Comienza con "A" y busca "A.txt". De esta forma puedes organizar los datos en forma de árbol (similar al diccionario: carpetas A, B... en la carpeta A carpetas AA, AB, etc.), la búsqueda será muy rápida.

 
komposter:

Así que tendrás que leer muchas veces, y eso es:

  • muy, muy lentamente.
  • limpiará un agujero en la unidad.

disco RAM virtual al rescate ;)

y no tendrás un agujero, y te gustará la velocidad.

y todo el volumen está disponible de inmediato.

no cortar en trozos, porque los trozos no son adecuados para la tarea

 
Yo intentaría cortar el archivo en trozos y cargar cada trozo según sea necesario (es decir, como sugiere Dima). Es difícil decirlo con exactitud, ya que depende de la tarea específica. Pero el problema es interesante, manténgame informado de sus hallazgos.
 
komposter:

1. este es el caché... O no entiendo lo que quieres decir. ¿Mi opción de leer constantemente los trozos necesarios?

Bueno... leer el archivo a través de su envoltura, la envoltura mantendrá una pequeña parte del archivo en la memoria y sustituirá sin leer. Quiero decir que sabes cómo se usa el archivo, así que el envoltorio debería resultar bastante eficiente.

komposter:

Oh, mierda...

Los mismos huevos, sólo que de lado. La lectura puede acelerar, pero no resuelve el problema globalmente.

Bueno, estaba pensando en acciones repetitivas dentro de una pequeña escala.

El uso del mapeo es utilizar el caché de Wind en lugar de escribir el propio. Cargar el trozo, leerlo, descargarlo. Si el chunk se utiliza a menudo, winds lo mantendrá en la memoria.

anónima:

3. utilizar datos comprimidos, descomprimir 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).

O bien (c).
 
Sin conocer los detalles de la estructura de datos y las operaciones que se van a realizar, sólo es posible dar consejos generales. Una de las opciones es convertir los datos brutos en metadatos de menor tamaño -los mismos 4 Gb- en una o varias pasadas (pero sin borrar el disco) y luego trabajar con los metadatos (valores agregados, cortes por algún parámetro, etc.). Si esto no funciona, entonces cargue los datos en el SGBD.
 
komposter:

Hay una gran cantidad de información (unos 20 GB en un archivo de texto).

...

Y si este archivo está comprimido con un archivador, ¿qué tamaño tiene (porque el texto debe estar muy bien comprimido)?

123456789...21
Nuevo comentario
Razón de la queja: