Desarrollo de Python
  1. Desarrollo de Python
  3. ¿Por qué se puede usar un ndarray NumPy de 352 GB en una computadora macOS con memoria de 8 GB?
Intereting Posts
¿Cómo recuperar la ruta de un módulo? Poner un `Cookie` en un` CookieJar` Cómo guardar la salida de python como tsv Personalizar (anular) el método de envío del administrador del matraz desde la vista de edición Viendo el nombre de la instancia de EC2 usando Boto 3 ¿Cómo consultar varias tablas a la vez? Lista de Python a XML y viceversa. Instale Python 3 en / usr / bin / en macOS Cómo escribir texto en una imagen en windows usando python opencv2 ¿Cómo almacenar de manera eficiente este documento XML analizado en la base de datos MySQL usando Python? for-if sin lista de comprensión en una sola línea Paramiko no puede descargar archivos de gran tamaño> 1 GB pycuda; nvcc fatal: No se pudo encontrar el archivo de configuración de Visual Studio ‘(null)’ ¿lxml / peticiones puede seleccionar las opciones desplegables y luego analizar ajax resultante? ¿Cuándo necesito usar la palabra clave global en Python?

¿Por qué se puede usar un ndarray NumPy de 352 GB en una computadora macOS con memoria de 8 GB?

 
import numpy as np array = np.zeros((210000, 210000)) # default numpy.float64 array.nbytes

Cuando ejecuto el código anterior en mi MacBook de memoria de 8GB con macOS, no se produce ningún error. Pero ejecutando el mismo código en una PC de memoria de 16GB con Windows 10 o una computadora portátil Ubuntu de 12GB de memoria, o incluso en una supercomputadora Linux de 128GB de memoria, el intérprete de Python generará un error de memoria. Todos los entornos de prueba tienen Python 3.6 o 3.7 de 64 bits instalado.

La respuesta de @Martijn Pieters está en el camino correcto, pero no del todo correcto: esto no tiene nada que ver con la compresión de la memoria, sino que tiene que ver con la memoria virtual .

Por ejemplo, intente ejecutar el siguiente código en su máquina: 

 arrays = [np.zeros((21000, 21000)) for _ in range(0, 10000)]

Este código asigna 32 TB de memoria, pero no obtendrá un error (al menos no lo hice, en Linux). Si reviso htop, veo lo siguiente: 

  PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command 31362 user 20 0 32.1T 69216 12712 S 0.0 0.4 0:00.22 python

Esto porque el sistema operativo está perfectamente dispuesto a cometer en exceso en la memoria virtual . En realidad, no asignará páginas a la memoria física hasta que sea necesario. La forma en que funciona es:

  • calloc le pide al sistema operativo algo de memoria para usar
  • el sistema operativo busca en las tablas de páginas del proceso y encuentra un trozo de memoria que está dispuesto a asignar. Esta es una operación rápida, el sistema operativo solo almacena el rango de direcciones de memoria en una estructura de datos interna.
  • El progtwig escribe a una de las direcciones.
  • el sistema operativo recibe un error de página , en cuyo punto se ve y en realidad asigna la página a la memoria física. Una página suele ser de unos pocos KiB de tamaño .
  • el sistema operativo pasa el control de nuevo al progtwig, que continúa sin darse cuenta de la interrupción.

La creación de una gran matriz única no funciona en Linux porque, de forma predeterminada, se aplica un “algoritmo heurístico para determinar si hay suficiente memoria disponible”. (¡ Gracias a @Martijn Pieters! ) Algunos experimentos en mi sistema muestran que para mí, el kernel no está dispuesto a proporcionar más de 0x3BAFFFFFF bytes. Sin embargo, si ejecuto echo 1 | sudo tee /proc/sys/vm/overcommit_memory echo 1 | sudo tee /proc/sys/vm/overcommit_memory , y luego vuelva a intentar el progtwig en el OP, funciona bien.

Para divertirse, intente ejecutar arrays = [np.ones((21000, 21000)) for _ in range(0, 10000)] . Definitivamente obtendrá un error de falta de memoria, incluso en MacOs o Linux con compresión de intercambio. Sí, ciertos sistemas operativos pueden comprimir la RAM, pero no pueden comprimirla al nivel que no se quedaría sin memoria.