Me estoy poniendo un problema de memoria me parece que no puede entender.

Estoy en un windows 7 de 64 bits de la máquina con 8 gb de memoria y el funcionamiento de un 32bit programa en python.

De los programas que se lee en un 5,118 con cremallera numpy archivos (npz).
Windows informa de que los archivos ocupan 1.98 GB en el disco

Cada npz archivo contiene dos piezas de datos:
‘arr_0’ es de tipo np.float32 y
‘arr_1’ es de tipo np.uint8

La secuencia de comandos de python lee cada archivo agrega sus datos en dos listas y, a continuación, cierra el archivo.

Alrededor de archivo 4284/5118 el programa produce un MemoryException

Sin embargo, el administrador de tareas dice que el uso de memoria de python.exe *32 cuando se produce el error es 1,854,848 K ~= 1,8 GB. Mucho menos de mis 8 GB de límite, o la supuesta límite de 4 gb de un programa de 32 bits.

En el programa que captura el error de la memoria y los informes:
Cada lista tiene una longitud de 4285.
La primera lista contiene un total de 1,928,588,480 float32 s ~= 229.9 MB de datos.
La segunda lista contiene 12,342,966,272 uint8 s ~= 1,471.3 MB de datos.

Por lo tanto, todo parece ser la comprobación. A excepción de la parte donde me da un error de memoria.
Estoy totalmente de tener más memoria, y el archivo que se estrella en es ~800 KB, así que no es por falta de lectura de un archivo enorme.

También, el archivo no está dañado. Puedo leer bien, si yo no uso todo lo que la memoria de antemano.

Para hacer las cosas más confusas, todo esto parece que funciona muy bien en mi máquina Linux (aunque tiene 16GB de memoria frente a los 8GB en mi máquina Windows), pero aún así, no parece ser la memoria RAM de máquina que está causando este problema.

¿Por qué es Python tirar un error de memoria, cuando creo que debería ser capaz de asignar a otro de 2GB de datos?

  • La cantidad de RAM física que tiene es irrelevante. En Windows, que siempre tienes swap, lo quieras o no.
  • Cuando esto funciona en su máquina linux… es que con el de 32 bits Python así?
  • podría publicar el código que se utiliza para cargar el .npz archivo? si utiliza np.load(file, mmap_mode='r+') se consumen mucha menos memoria, ya que con este argumento, se abrirá un memory-mapped array
  • Hay un motivo por el que estás usando una versión de 32 bits intérprete de Python para el proceso de gigabytes de datos? Sólo estás haciendo las cosas más difíciles para ti, y a menos que tengas una buena razón, ¿por qué hacer eso?
  • Debido a la instalación de 64bis python y sus dependencias en windows es un dolor ?
  • Acabo de descargar el «Python Windows X86_64 MSI Installer» de python.org y corrió, y funciona bien. Christoph Gohlke del no oficial de Windows binarios tiene el mismo conjunto de paquetes de 32 y 64 bits. La configuración de construir extensiones en C localmente es un dolor, pero tiene las mismas dependencias y el mismo conjunto de pasos de cualquier manera. Qué parte estás teniendo problemas con el?
  • El problema no es con el propio python pero con numpy y scipy, que necesita un 64bit compilador de fortran. El único existente, si de Intel si recuerdo correctamente, y no es libre. Yo sé que usted puede usar WinPyton por lo que es posible. Aún así, usted tiene que utilizar no oficial binarios de un sitio web no afiliados a python.org.
  • sí linux es de 32 bits así. La razón por la que estoy usando 32 bits python es porque es más estable que el de 64, y el proyecto en el que estoy trabajando, hay que trabajar en los equipos antiguos (aunque sin esa cantidad de memoria). También, python facilita las cosas mucho más a menudo de lo que hace que las cosas difíciles.
  • Castro Gracias, me aseguraré de hacerlo, independientemente de que la solución de este problema. Yo estaba usando np.load(archivo)
  • Cuánto tiempo ha pasado desde que comprobado que? gfortran construye para MinGW64 tan fácilmente como para MinGW, y tiene para un rato ahora. O usted puede descargar los binarios de exactamente la misma página en gcc.gnu.org como el MinGW32-para-Win64 binarios.
  • ¿Qué te hace pensar de 32 bits Python es más estable? La mayoría de los principales desarrolladores están en Unix de 64 bits cuadros de hoy en día. Ha habido muchos errores y problemas de rendimiento, donde un cambio de 32 bits peor y nadie se dio cuenta por meses, y muy pocos en la otra dirección. Puedo entender tener build/toolchain problemas, pero si el motivo es realmente el pensamiento de que el propio Python es inestable en 64 bits, estás muy equivocado.
  • el post es de agosto de 2012: spyder-ide.blogspot.fr/2012/08/…
  • Hace más de un año, había dos problemas. En primer lugar, gfortran, no estaba listo para el prime time de MinGW64, pero eso no es cierto hoy en día; ahora es uno de los plataformas compatibles, como MinGW32 (y nativo Win32, cygwin, y todos los *nixes). La otra parte de ella—de que Christoph Gohkle del Win64 binario paquete scipy puede haber tenido algún claro de concesión de licencias que causó problemas para cualquier persona que quería distribuir los paquetes binarios que utilizan ellos—no es relevante para muchas personas, especialmente uno que no quiere usar «no oficial binarios de un sitio web no afiliados a python.org».
  • Bueno, supongo que es una novedad para mí. Voy a ver en el cambio a 64 bits python.

InformationsquelleAutor Erotemic | 2013-08-16

1 Comentario

  1. 37

    No sé por qué piensas que tu proceso debe ser capaz de acceder a 4GB. De acuerdo a Los Límites de la memoria para las Versiones de Windows en MSDN, en la versión de 64 bits de Windows 7, por defecto un proceso de 32 bits consigue 2 GB.* Que es exactamente donde se ejecutan.

    Es así, ¿hay alguna forma de evitar esto?

    Bien, usted podría hacer una versión personalizada de 32 bits Python que utiliza el IMAGE_FILE_LARGE_ADDRESS_AWARE bandera, y reconstruir numpy y todos los otros módulos de extensión. No puedo prometerte que todo el código que realmente es seguro ejecutar con la gran dirección consciente de la bandera; hay una buena probabilidad de que lo es, pero a menos que alguien ya está hecho y probado, «una buena oportunidad» es el mejor nadie es probable que sé.

    O, más obviamente, sólo tiene que utilizar de 64 bits de Python en su lugar.


    La cantidad de RAM física es completamente irrelevante. Usted parece pensar que usted tiene
    un «8GB límite» con 8GB de RAM, pero que no funciona. Su sistema se lleva toda la RAM además de lo que el espacio de intercambio que necesita y se divide entre aplicaciones, una aplicación puede ser capaz de obtener 20GB de memoria virtual sin llegar a un error de memoria, incluso en una de 8GB de la máquina. Y mientras tanto, una de 32 bits de la aplicación no tiene manera de acceder a más de 4 GB y el sistema operativo utilizará parte de ese espacio de direcciones (la mitad de ella de forma predeterminada, en Windows), por lo que sólo se puede obtener de 2 gb, incluso en una de 8GB de la máquina que no se ejecuta nada más. (No es posible ser «no se ejecuta nada más» en un sistema operativo moderno, pero usted sabe a qué me refiero.)


    Así que, ¿por qué funciona esto en linux?

    Debido a su cuadro de linux está configurado para dar los procesos de 32 bits de 3,5 GB de espacio de direcciones virtuales, o 3.99 GB, o… Bueno, yo no te puedo decir el número exacto, pero cada distro que he visto durante muchos años ha sido configurado para que al menos 3.25 GB.


    * Tenga en cuenta también que incluso no realmente conseguir que el total de 2GB de datos; su programa. La mayor parte de lo que el OS y los factores que la hacen accesible a su código se encuentra en la otra mitad, pero algunos bits de sentarse en su mitad, a lo largo de cada archivo DLL se carga y cualquier espacio que necesitan, y varias otras cosas. Que no aumente demasiado, pero no es cero.

    • Usted realmente no tiene que compilar el archivo exe en windows, el IMAGE_FILE_LARGE_ADDRESS_AWARE es simplemente un indicador en el encabezado de la imagen (no se que esta vez iba a ser oficialmente soportado pero bueno no estamos juzgando ;)). También dll no tienen voz en el asunto, para empezar, así que los que no tienen que ser cambiado de todos modos.
    • Pero todo el código, incluyendo los archivos Dll, tiene que ser seguro para con con la bandera. Si, por ejemplo, Python y su estándar de los módulos de extensión de comprobación en tiempo de compilación si desea grande-tenga en cuenta la dirección de apoyo y generar código diferente en los distintos casos, usted tendría que reconstruir todo, no solo el exe. Si son siempre grande-dirección-seguro, entonces usted no necesita hacer nada. Y si nunca grande-dirección-seguro, luego de la reconstrucción no será de ayuda. No sé de cualquier documentación que se le indica en cuál de los tres es…
    • Es cierto, aunque la única razón por la que el código no funcionará con IMAGE_FILE_LARGE_ADDRESS_AWARE es, si se rompe, para empezar (firmado puntero de matemáticas) o estúpidos trucos con los bits de orden superior de los punteros. Estoy muy sorprendido de que python no hace estas cosas – donde exactamente en el código? (GC supongo, es casi la única razón en que esto puede ser útil) encantaría echarle un vistazo.
    • No tengo absolutamente ni idea de si Python o cualquier módulos de Python que el OP depende de hacer tal cosa. Yo no creo que sea probable, pero no puedo garantizarlo. Evidentemente hay alguna razón por la que no se construye con IMAGE_FILE_LARGE_ADDRESS_AWARE fuera de la caja, supongo que la razón es que hasta el momento ninguno de los devs ha encontrado pruebas de ensayo y/o fregar la fuente, porque si realmente necesita más de 2GB que sólo tiene que utilizar una de 64 bits construir. Pero eso es sólo una conjetura, que es la razón de mi respuesta, dijo que hay una buena probabilidad de que va a funcionar, pero no puedo prometerlo.
    • Sí, pero si no hay ningún modificador de compilador para este que python depende luego ir a través de todo el trabajo de reconstrucción de python va a hacer exactamente nada en comparación con sólo el cambio de un solo bit en el encabezado, que era mi punto. Y yo realmente no puedo ver cómo python puede usar cualquier cosa que depende de los bits de orden superior de no haberlo utilizado – después de todos los *nix generalmente no da garantías y python se ejecuta bien ahí.
    • Yo no saber si hay un modificador de compilador para este que Python depende de (posiblemente incluso Python-específico /D de la bandera #si había en el código). Si usted lo hace, usted debería ser capaz de decir mirando… se me olvida el equivalente en Windows de python-config --cflags. De lo contrario, todo lo que puedes hacer es adivinar. He dicho repetidas veces que no es probable a ser un problema, pero no puedo promesa que> Así que no sé lo que usted está tratando de argumentar. Diciendo: «yo sé que usted dijo que no es probable, pero no es probable» no agrega nada. Si usted puede probar es seguro, genial; si no, ¿qué más hay que decir?

Dejar respuesta

Please enter your comment!
Please enter your name here