[Python-es] Paython trabaja en memoria?

Vie Mayo 13 04:51:59 EDT 2016

2016-05-13 3:20 GMT+02:00 Chema Cortes <pych3m4 en gmail.com>:

>
>
> El jue., 12 may. 2016 a las 21:57, Francesc Alted (<faltet en gmail.com>)
> escribió:
>
>> 2016-05-12 18:10 GMT+02:00 Chema Cortes <pych3m4 en gmail.com>:
>>
>>> El jue., 12 may. 2016 a las 10:51, Javier Sangalo (<jjsangalo en gmail.com>)
>>> escribió:
>>>
>>>> muchas gracias!
>>>> No tengo ningun problema en particular, tan solo que me hen hecho esa
>>>> pregunta y no estaba seguro de que responder jeje.
>>>>
>>>
>>> La diferencia entre trabajar con datos en memoria en lugar de en disco
>>> supone un factor multiplicativo de x200000. Con los nuevos discos SSD
>>> mejora bastante bajando a unos x10000. Vamos, que es muy recomendable tener
>>> todos los datos en memoria, aunque sea como matrices dispersas (sparse
>>> matrices), con el fin de operar más rápido sin pasar por disco. Tanto R
>>> como numpy tienen técnicas para optimizar el espacio ocupado en memoria.
>>>
>>
>> Supongo que estás citando números de latencia.  Aunque la cifra para
>> discos duros es más o menos correcta, la que das para SSDs está bastante
>> desfasada.  Actualmente puedes comprar SSDs SATA con latencias de entre 40
>> y 100 us sin hacer un gran desenbolso.  Teniendo en cuenta que las
>> latencias típicas de la RAM son de 0.1 us, la diferencia es ('solo') de
>> entre 500x y 1000x.  Para los discos SSD de PCIe, las latencias son
>> bastante más bajas, y ya se pueden ver tarjetas a buen precio con latencias
>> de 2 y 10 us (e incluso de menos de 1 us, como las de
>> http://www.violin-memory.com/, aunque estas ya son *muy* caras).
>>
>> Respecto a las diferencias en ancho de banda las cosas van bastante más
>> ajustadas, y los discos SSD SATA que saturan el bus (~520 MB/s) son muy
>> habituales, mientras que los SSD PCIe pueden llegar hasta 2 GB/s.  Compara
>> esto con la RAM que va entre 10 GB/s a 20 GB/s (en ordenadores modernos).
>> Añade compresión ultra-rápida para mejorar el ancho de banda de I/O y se ve
>> claro que estamos asistiendo a una verdadera revolución que cambiará (está
>> cambiando) la manera de guardar y efectuar cálculos con datos.
>>
>> Hablé justamente de esto en mi charla de PyData Madrid del mes pasado:
>>
>> https://speakerdeck.com/francescalted/new-computer-trends
>>
>> Francesc
>>
>
> Tienes toda la razón, me había quedado desfasado. Hasta ahora sólo
> consideraba los SSDs para acelerar los sistemas críticos (eg: sistemas
> oracles), pero con lo que dices ya empiezan a ser muy interesantes para
> realizar cálculos masivos.
>
> Incluso me puedo imaginar ya realizable un viejo deseo: que la
> persistencia de los datos se independice de la vida de la aplicación. O
> visto de otro modo, los datos no se mueven, se mueven las aplicaciones
> (pensando siempre en programación funcional).
>

Si, mucha gente va detrás de eso.  Sin embargo, hay muchas aplicaciones y
cada una tiene sus necesidades.  Yo más bien abogo por empezar a utilizar
la jerarquía de memoria (y muy en particular los SSDs) de manera eficaz,
cosa que se podrá aprovechar para tu 'viejo deseo' de que los datos no se
muevan.

Pero no nos equivoquemos, las CPUs hacen càlculos con las caches (más que
con la RAM), y no hay más tu tía que los datos sean transmitidos a ellas de
manera eficiente a través de la jerarquía de memoria para que los cores de
las CPUs dejen de estar tanto tiempo haciendo nada más que esperar a los
datos.  La compresión puede ayudar a rebajar la cantidad de bytes
transmitidos (al tiempo que se usan ciclos de CPU que otra manera se
desaprovechan), pero aun así hay mucha labor por hacer en determinar
parámetros esenciales como los tamaños de bloque, los contenedores de datos
óptimos, etc...  Aquí hay otro ejemplo de contenedor multidimensional
totalmente general que se está desarrollando ahora mismo con todo esto en
mente:

http://zarr.readthedocs.io/en/refactor/index.html

y aquí unos benchmarks:

http://nbviewer.jupyter.org/github/alimanfoo/zarr/blob/refactor/notebooks/dask_copy.ipynb

Como se ve, usar todos nuestros cores (que usualmente están parados), así
como las capacidades SIMD de las CPUs modernas (que también están
infra-utilizadas), y en el futuro, las GPUs integradas, es fundamental para
hacer que los datos fluyan hacia la CPU lo más rápido posible.

Francesc

>
>
>
>>
>>
>>>
>>> Pero no siempre es la mejor opción. A veces tu datos vienen como streams
>>> de datos desde algún servidor web o desde algún nodo de la base de datos.
>>> En estos casos, los tiempos invertidos en traerte los datos pueden ser
>>> mucho mayor que el que inviertes escribiendo/leyendo del disco local, con
>>> lo que puedes usar el disco como almacenamiento secundario para liberar
>>> RAM. Es en parte lo que hace Hadoop para poder procesar colecciones de
>>> datos enormes (aunque luego venga Spark y pulverize los tiempos de proceso
>>> cacheándolo todo en RAM).
>>>
>>> Una comparativa tecnológica e histórica de los tiempos de latencia:
>>>
>>> https://gist.github.com/jboner/2841832
>>> http://www.eecs.berkeley.edu/~rcs/research/interactive_latency.html
>>>
>>>
>>>
>>>>
>>>> El 12 de mayo de 2016, 10:40, Kiko <kikocorreoso en gmail.com> escribió:
>>>>
>>>>>
>>>>> El 12 de mayo de 2016, 10:23, Javier Sangalo <jjsangalo en gmail.com>
>>>>> escribió:
>>>>>
>>>>>> Buenos días,
>>>>>>
>>>>>> Me surge una duda, R trabaja en memoria con el inconveniente que
>>>>>> tiene si no dispones de suficiente memoria ram, pero...y Python? trabaja de
>>>>>> la misma forma?
>>>>>>
>>>>>>
>>>>> Sí. R, Python y el resto del universo. Tendrás que encargarte de
>>>>> gestionar la memoria. Hay formas más o menos eficientes de hacerlo. Si
>>>>> describes un poco mejor tu problema relacionado con Python quizá te puedan
>>>>> ofrecer mejor ayuda.
>>>>>
>>>>>
>>>>>> Gracias!
>>>>>>
>>>>>> _______________________________________________
>>>>>> Python-es mailing list
>>>>>> Python-es en python.org
>>>>>> https://mail.python.org/mailman/listinfo/python-es
>>>>>> FAQ: http://python-es-faq.wikidot.com/
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Python-es mailing list
>>>>> Python-es en python.org
>>>>> https://mail.python.org/mailman/listinfo/python-es
>>>>> FAQ: http://python-es-faq.wikidot.com/
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Python-es mailing list
>>>> Python-es en python.org
>>>> https://mail.python.org/mailman/listinfo/python-es
>>>> FAQ: http://python-es-faq.wikidot.com/
>>>>
>>> --
>>> Hyperreals *R  "Quarks, bits y otras criaturas infinitesimales":
>>> http://ch3m4.org/blog
>>>
>>> _______________________________________________
>>> Python-es mailing list
>>> Python-es en python.org
>>> https://mail.python.org/mailman/listinfo/python-es
>>> FAQ: http://python-es-faq.wikidot.com/
>>>
>>>
>>
>>
>> --
>> Francesc Alted
>> _______________________________________________
>> Python-es mailing list
>> Python-es en python.org
>> https://mail.python.org/mailman/listinfo/python-es
>> FAQ: http://python-es-faq.wikidot.com/
>>
> --
> Hyperreals *R  "Quarks, bits y otras criaturas infinitesimales":
> http://ch3m4.org/blog
>

-- 
Francesc Alted
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.python.org/pipermail/python-es/attachments/20160513/28dc7811/attachment.html>