Acabo de ver this section of Unladen Swallow's documentation en Hacker News. Básicamente, son los ingenieros de Google quienes dicen que no son optimistas acerca de eliminar el GIL. Sin embargo, parece que hay una discusión sobre el recolector de basura intercalada con esta charla sobre el GIL. ¿Podría alguien explicarme la relación?¿Qué tiene que ver el GIL de Python con el recolector de basura?
La versión realmente corta es que actualmente python maneja la memoria con un recuento de referencia + una marca & esquema de colector de ciclo de barrido, optimizado para latencia (en lugar de rendimiento).
Esto está bien cuando solo hay un único hilo de mutación, pero en un sistema de subprocesos múltiples, necesita sincronizar todas las veces que modifica los recuentos, o bien puede tener los valores "caídos a través de las grietas", y primitivas de sincronización son bastante caros en hardware contemporáneo.
Si las recolocaciones no se modificaron tan a menudo, esto no sería un problema, pero casi todas las operaciones que se realizan en cpython pueden hacer que un recuento cambie en alguna parte, por lo que las opciones son GIL, haciendo refunciones con algunas tipo de sincronización (y, literalmente, pasar casi todo el tiempo en la sincronización), o abandonar el sistema de refcounting para algún tipo de recolector de basura real.
La respuesta de Tuna-Fish básicamente lo cubre. Si quieres más detalles, hubo una discusión sobre cómo el GIL podría ser eliminado sin tener demasiado mucho de un efecto sobre la referencia contando aquí: http://mail.python.org/pipermail/python-ideas/2009-October/006264.html
La sugerencia en ese enlace era ingenua. Usar compare-and-swap para conteo de referencia es demasiado lento. –
me acaba de encontrar otro punto de vista sobre este tema aquí: http://renesd.blogspot.com/2009/12/python-gil-unladen-swallow-reference.html
Bien, lea sobre el GIL. http://wiki.python.org/moin/GlobalInterpreterLock Como puede ver, se trata de la administración de la memoria. –