El jue., 12 may. 2016 a las 21:57, Francesc Alted (<fal...@gmail.com>)
escribió:
> 2016-05-12 18:10 GMT+02:00 Chema Cortes <pych...@gmail.com>:
>
>> El jue., 12 may. 2016 a las 10:51, Javier Sangalo (<jjsang...@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).
>
>
>>
>> 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 <kikocorre...@gmail.com> escribió:
>>>
>>>>
>>>> El 12 de mayo de 2016, 10:23, Javier Sangalo <jjsang...@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@python.org
>>>>> https://mail.python.org/mailman/listinfo/python-es
>>>>> FAQ: http://python-es-faq.wikidot.com/
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Python-es mailing list
>>>> Python-es@python.org
>>>> https://mail.python.org/mailman/listinfo/python-es
>>>> FAQ: http://python-es-faq.wikidot.com/
>>>>
>>>>
>>> _______________________________________________
>>> Python-es mailing list
>>> Python-es@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@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@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@python.org
https://mail.python.org/mailman/listinfo/python-es
FAQ: http://python-es-faq.wikidot.com/
