¿Para qué usaría Stackless Python?

Hay muchas preguntas relacionadas con Stackless Python. Pero ninguno responde mi pregunta, creo (¡corríjame si está mal, por favor!). Hay rumores al respecto todo el tiempo, así que tengo curiosidad por saberlo. ¿Para qué usaría Stackless? ¿Cómo es mejor que CPython?¿Para qué usaría Stackless Python?

Sí, tiene hilos verdes (sin apilamiento) que permiten crear rápidamente muchos hilos livianos, siempre que ninguna operación se bloquee (algo así como los hilos de Ruby?). ¿Para qué sirve esto? ¿Qué otras características tengo que usar sobre CPython?

Fuente

2010-02-08 zaharpopov

Esto suena como un candidato wiki de la comunidad. –

@Tim - make wiki – zaharpopov

Me gustaría señalar que CPython regular también tiene soporte para hilos verdes a través de un pequeño módulo de extensión llamado greenlet (http://pypi.python.org/pypi/greenlet). Stackless todavía puede hacer algunas cosas que CPython no puede, pero los hilos verdes básicos no son uno de ellos. – porgarmingduod

Le permite trabajar con cantidades masivas de concurrencia. Nadie en su sano juicio crearía cien mil hilos de sistema, pero puede hacerlo sin apilarse.

Esta prueba artículo haciendo precisamente eso, la creación de cien mil tasklets tanto en Python y Google Go (un nuevo lenguaje de programación): http://dalkescientific.com/writings/diary/archive/2009/11/15/100000_tasklets.html

Sorprendentemente, incluso si Google Go es compilado a código nativo, y que promocionan su implementación de co-rutinas, Python aún gana.

Stackless sería bueno para implementar un algoritmo de asignación/reducción, donde puede tener una gran cantidad de reductores según sus datos de entrada.

Fuente

2010-02-12 01:15:33 Meh

@Adal: pero no es una buena reducción del mapa para la paralelización, mientras que Stackless ejecuta todas las tareas en una sola CPU. – zaharpopov

Tiene razón, pero si la velocidad no es crítica o el conjunto de datos no es demasiado grande, puede implementar el mapa/reducir muy fácilmente en Stackless – Meh

+14

pero el mapa/reducir es para velocidad ¿por qué más lo necesito ????????? ? – zaharpopov

EVEOnline está programado en gran parte en Stackless Python. Tienen varios blogs de desarrolladores sobre el uso de este. Parece que es muy útil para la informática de alto rendimiento.

Fuente

2010-02-08 09:51:05 Thirler

+13

¿por qué sería mejor para la informática de alto rendimiento? – zaharpopov

Todos los componentes críticos para el rendimiento están escritos en C hasta donde yo sé. – 0x41414141

La motivación para esto tiene que ver con la parte sin apilamiento. Es muy barato crear un 'hilo' o tarea. – Thirler

El beneficio principal de Stackless Python es el soporte para corrutinas muy livianas. CPython no admite coroutines de forma nativa (aunque espero que alguien publique un hack basado en generador en los comentarios) así Stackless es una clara mejora en CPython cuando tienes un problema que se beneficia de corutinas.

Creo que el área principal donde sobresalen es cuando tiene muchas tareas simultáneas ejecutándose dentro de su programa. Los ejemplos pueden ser entidades de juego que ejecutan un script de bucle para su IA, o un servidor web que atiende a muchos clientes con páginas que tardan en crearse.

Todavía tiene muchos de los problemas típicos de exactitud de concurrencia con respecto a datos compartidos, pero la conmutación de tareas determinística hace que sea más fácil escribir código seguro ya que sabe exactamente dónde se transferirá el control y conocer los puntos exactos en los que estado compartido debe estar actualizado.

Fuente

2010-02-08 10:58:20 Kylotan

en qué sentido "concurrente"? después de todo, estos son solo hilos verdes, no proporcionan ninguna concurrencia, solo la ilusión de que – zaharpopov

oh, y también, coroutine con generadores no es un truco - esta es la razón por la cual el rendimiento recibe un argumento en Python y David Beazley tiene un gran artículo al respecto – zaharpopov

Las tareas son concurrentes, ya que varias están en progreso en cualquier momento. El hecho de que la ejecución solo esté ocurriendo en uno de ellos es irrelevante. Lo mismo se aplica a los hilos y procesos reales la mayor parte del tiempo también debido a la espera de E/S. Y decir que coroutines con generadores no es un truco es como decir corutinas en C++ con setjmp/longjmp no es un truco. : P El sistema puede haber sido diseñado para permitirlo, pero está lejos de ser una solución elegante. – Kylotan

Thirler ya mencionó que stackless se usó en Eve Online. Tenga en cuenta que:

(...) stackless le agrega un giro adicional al permitir que las tareas se separen en tareas más pequeñas, Tasklets, que luego pueden separarse del programa principal para ejecutarse por su cuenta. Esto se puede usar para tareas de "olvidar y olvidar", como enviar un correo electrónico o enviar un evento o para operaciones de E/S, p. enviar y recibir paquetes de red. Un tasklet espera un paquete de la red mientras que otros continúan ejecutando el bucle del juego.

En cierto modo es similar a los hilos, pero no es preventivo y está programado explícitamente, por lo que hay menos problemas con la sincronización. Además, el cambio entre tareas es mucho más rápido que el cambio de subprocesos, y puede tener una gran cantidad de tareas activas, mientras que el hardware de la computadora limita severamente el número de subprocesos.

(tiene esta cita de here)

En PyCon 2009 fue dado a very interesting talk, describiendo por qué y cómo se utiliza en Stackless CCP Games.

Además, hay una muy buena introductory material, que describe por qué stackless es una buena solución para sus aplicaciones. (Puede ser algo viejo, pero creo que vale la pena leerlo).

Fuente

2010-02-12 12:50:27 zeroDivisible

La utilidad básica para los hilos verdes, como yo lo veo, es implementar un sistema en el que tenga una gran cantidad de objetos que realicen operaciones de alta latencia. Un ejemplo concreto se comunica con otras máquinas:

def Run(): 
    # Do stuff 
    request_information() # This call might block 
    # Proceed doing more stuff

Hilos permiten escribir el código anterior, naturalmente, pero si el número de objetos es lo suficientemente grande, las discusiones no pueden realizar adecuadamente. Pero puede usar hilos verdes incluso en grandes cantidades. El request_information() anterior podría cambiar a algún programador donde otro trabajo está esperando y regresar más tarde. Obtiene todos los beneficios de poder llamar a las funciones de "bloqueo" como si regresaran inmediatamente al sin usar hilos.

Esto es obviamente muy útil para cualquier tipo de computación distribuida si desea escribir código de una manera directa.

También es interesante para múltiples núcleos para mitigar la espera de bloqueos:

def Run(): 
    # Do some calculations 
    green_lock(the_foo) 
    # Do some more calculations

La función green_lock sería básicamente intentar adquirir el bloqueo y simplemente cambiar a un planificador principal si falla debido a otros núcleos utilizando el objeto.

Una vez más, los hilos verdes se utilizan para mitigar el bloqueo, lo que permite que el código se escriba de forma natural y todavía funcione bien.

Fuente

2010-02-16 20:50:31 porgarmingduod

No creo que los hilos verdes puedan mitigar el bloqueo. Por el contrario, los hilos verdes NECESITAN un código que no sea de bloqueo para que sean efectivos. En su ejemplo, si request_informaton realmente está bloqueando como usted afirmó, entonces simplemente bloquearía todo el intérprete de Python y los hilos verdes no podrían lograr ninguna concurrencia. – Continuation

Usted simplemente está completamente equivocado. – porgarmingduod

En realidad, estás completamente equivocado. Los hilos verdes son hilos de userland. Llama a una llamada de bloqueo con un hilo verde y se bloqueará todo el intérprete. http://en.wikipedia.org/wiki/Green_threads "un hilo verde puede bloquear todos los otros hilos si se realiza una operación de bloqueo de E/S". Es por eso que necesita usar E/S no bloqueante cuando se usa hilo verde. El hilo verde no convierte mágicamente una llamada de bloqueo en una llamada sin bloqueo – Continuation

Si bien no he usado Stackless, he usado Greenlet para implementar aplicaciones de red altamente concurrentes. Algunos de los casos de uso a los que lo ha tendido Linden Lab son: proxies inteligentes de alto rendimiento, un sistema rápido para distribuir comandos sobre un gran número de máquinas y una aplicación que realiza toneladas de escrituras y lecturas de bases de datos (en una proporción de aproximadamente 1) : 2, que es muy pesado de escritura, por lo que está pasando la mayor parte del tiempo esperando a que la base de datos regrese), y una cosa tipo crawler web para datos web internos. Básicamente, cualquier aplicación que espere tener que hacer un montón de E/S de red se beneficiará al poder crear un bajillion de subprocesos ligeros. 10,000 clientes conectados no me parecen un gran negocio.

Sin embargo, Stackless o Greenlet no son realmente una solución completa. Son de muy bajo nivel y vas a tener que hacer mucho mono para construir una aplicación con ellos que los use al máximo. Lo sé porque tengo una biblioteca que proporciona una capa de red y programación sobre Greenlet, específicamente porque escribir aplicaciones es mucho más fácil con ella. Hay muchos de estos ahora; Mantengo Eventlet, pero también hay Concurrence, Chiral, y probablemente algunos más que no conozco.

Si el tipo de aplicación que desea escribir es similar a la que escribí, considere una de estas bibliotecas. La elección de Stackless vs Greenlet es algo menos importante que decidir qué biblioteca se adapta mejor a las necesidades de lo que desea hacer.

Fuente

2010-02-17 07:50:37 rdw

Tenga en cuenta que el nombre "Greenlet" es engañoso. En el sentido de cómo funciona Stackless, Greenlets no es verde, tal vez solo amarillo ;-) El punto es que Greenlets obliga al intérprete a cambiar de contexto modificando la pila C. Stackless puede hacer esto de forma colaborativa, de forma nativa, que es 5-10 veces más eficiente en tiempo y memoria. –

@ChristianTismer: Eso es interesante. ¿Te importaría vincular una fuente a estas afirmaciones? Me gustaría investigar más. –

@Noob ¿Qué quieres decir con eso? Reclamos de velocidad? Simplemente pruebe taskspeed.py en la carpeta Stackless/test, luego verá la diferencia entre hard-switching (greenlet) y soft-switching (stackless). –

¿Para qué usaría Stackless Python?

Respuesta

Cuestiones relacionadas