Creando archivos binarios al azar

Estoy tratando de usar Python para crear un archivo binario aleatorio. Esto es lo que ya tengo:

f = open(filename,'wb') for i in xrange(size_kb): for ii in xrange(1024/4): f.write(struct.pack("=I",random.randint(0,sys.maxint*2+1))) f.close() 

Pero es terriblemente lento (0.82 segundos para size_kb = 1024 en mi máquina de disco SSD de 3.9GHz). Un gran cuello de botella parece ser la generación aleatoria int (reemplazar el randint () con un 0 reduce el tiempo de ejecución de 0.82s a 0.14s).

Ahora sé que hay formas más eficientes de crear archivos de datos aleatorios (a saber, dd if = / dev / urandom) pero estoy tratando de resolver esto por curiosidad … ¿hay alguna forma obvia de mejorar esto?

En mi humilde opinión, lo siguiente es completamente redundante:

 f.write(struct.pack("=I",random.randint(0,sys.maxint*2+1))) 

No hay absolutamente ninguna necesidad de usar struct.pack , solo haga algo como:

 import os with open('output_file', 'wb') as fout: fout.write(os.urandom(1024)) # replace 1024 with size_kb if not unreasonably large 

Luego, si necesita reutilizar el archivo para leer números enteros, entonces struct.unpack entonces.

(Mi caso de uso es generar un archivo para una prueba de unidad, así que solo necesito un archivo que no sea idéntico a otros archivos generados).

Otra opción es simplemente escribir un UUID4 en el archivo, pero como no sé el caso de uso exacto, no estoy seguro de que sea viable.

El código de Python que debe escribir completamente depende de la forma en que pretenda usar el archivo binario aleatorio. Si solo necesita una aleatoriedad “bastante buena” para múltiples propósitos, entonces el código de Jon Clements es probablemente el mejor.

Sin embargo, al menos en el sistema operativo Linux, os.urandom se basa en / dev / urandom, que se describe en el Kernel de Linux (drivers / char / random.c) de la siguiente manera:

El dispositivo / dev / urandom […] devolverá tantos bytes como sean solicitados. A medida que se solicitan más y más bytes aleatorios sin dar tiempo a que se recargue el grupo de entropía, esto resultará en números aleatorios que son meramente criptográficamente fuertes. Para muchas aplicaciones, sin embargo, esto es aceptable.

Entonces la pregunta es, ¿es esto aceptable para su aplicación? Si prefiere un RNG más seguro, podría leer bytes en / dev / random en su lugar. El principal inconveniente de este dispositivo: puede bloquearse indefinidamente si el kernel de Linux no puede reunir suficiente entropía. También hay otros RNGs criptográficamente seguros como EGD .

Alternativamente, si su principal preocupación es la velocidad de ejecución y si solo necesita un poco de “aleatoriedad de la luz” para un método de Monte-Carlo (es decir, la impredecibilidad no importa, la distribución uniforme sí lo hace), podría considerar generar una vez su archivo binario aleatorio y usar Muchas veces, al menos para el desarrollo.