[pyar] Cuanto cuesta el reference counting?

[Javier Burroni]

Buenas,
a mi también me parece interesante si alguien hace la prueba sobre el
"costo" del ref. counting. Algo inteersante es que se puede correr el "gc"
mientras el mutator esta andando, eso en general no es valido.

Con respecto a las referencias, bueno, todo el thread es sobre eso (cuack).
Tengo esto, por ejemplo: Wilson, P. `Wilson, P. “Uniprocessor Garbage
Collection Techniques.” Memory Management (1992): 1-42. que es un survey
 interesante.
Si te interesa, tengo un par de articulos mas sobre GC, pero casi ni hablan
sobre ref count.
En este que paso, en la pagina 3 empieza un analisis sobre ref counting muy
interesante

saludos
jb


2013/5/31 Daniel Moisset <dmoisset en machinalis.com>

> Gracias por toda la info!
>
> Si alguien mas tiene referencias (estaria buenisimo algo de bibliografia)
> se agradece
>
> D.
>
>
> 2013/5/29 Claudio Freire <klaussfreire en gmail.com>
>
>> 2013/5/29 Daniel Moisset <dmoisset en machinalis.com>:
>> > Alguien ha visto algún artículo/benchmark/rumor de cuanto cuesta el
>> > reference counting en python, en overhead de CPU?
>> >
>> > Es decir, si tuviera infinita memoria y cambiara los incref/decref por
>> nops,
>> > cuanto más rápido andarían mis programas en python?
>> >
>> > Puedo hacer el benchmark yo, pero me encantaría si alguien ya hubiera
>> hecho
>> > el trabajo antes.
>>
>>
>> Yo trabajé en un parche para mover los refcounts a un pool, en un
>> momento, porque el inc/dec genera una avalancha de COW luego de
>> forkear, así que tengo algo de datos al respecto.
>>
>> La respuesta es algo compleja.
>>
>> ¿Cuánto cuesta en ciclos?
>>
>> CPython está muy optimizado para no toquetear refcounts al pedo, pero
>> el eval loop no zafa, y te cuesta algo así como un 5 a 10% de los
>> ciclos en bucles muy pero muy ajustaditos (manejar ints o simplemente
>> pasar referencias de acá para allá). Obvio si hacés operaciones más
>> pesadas, el cambio es totalmente despreciable.
>>
>> El tema de COW sin embargo cambia las cosas. Luego de forkear, los
>> refcounts son pesadísimos de tocar (cada refcount que tocás
>> potencialmente requiere copiar una página entera), y te cuesta memoria
>> además de ciclos. Este punto para mí era el más importante.
>>
>> También está el tema de lo que cuestan en presión de escritura al
>> caché de datos, que no es moco de pavo. Con tareas mayoritariamente de
>> lectura, la diferencia es notable, en particular con threading (he
>> visto 30% de mejoría con el parche que contaba, bajo las condiciones
>> adecuadas, que son algo poco comunes).
>>
>> Pero, la mayoría del tiempo, la diferencia está más cerca del 5% que del
>> 30%.
>>
>> Esa es mi experiencia con python 2.6. 2.7 tiene bytecodes nuevos que
>> ayudan un poquín en los if, cortesía de unladen swallow, y podría
>> afectar la medición.
>> _______________________________________________
>> pyar mailing list pyar en python.org.ar
>> http://listas.python.org.ar/listinfo/pyar
>>
>> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>>
>> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
>> Argentina - http://www.usla.org.ar
>>
>
>
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>



-- 
" To be is to do " ( Socrates )
" To be or not to be " ( Shakespeare )
" To do is to be " ( Sartre )
" Do be do be do " ( Sinatra )
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20130531/9573ee36/attachment.html>