¿Qué iba a utilizar Python para Stackless?

Question

Hay muchas preguntas relacionadas con Stackless Python. Pero ninguno de responder a esta pregunta a mi, creo (me corrija si mal - por favor!). Hay algo de ruido en ello todo el tiempo, así que la curiosidad de saber. ¿Qué iba a utilizar para Stackless? ¿Cómo es mejor que CPython?

Si tiene hilos verdes (sin pérdida de velocidad) que permiten crear rápidamente muchos hilos ligeros, siempre y cuando no hay operaciones están bloqueando (algo así como los hilos de Ruby?). ¿Qué es esto grande para? ¿Qué otras características tiene que quiera usar más de CPython?

Answer 1

Se le permite trabajar con grandes cantidades de concurrencia. Nadie en su sano juicio podría crear cien mil subprocesos del sistema, pero se puede hacer esto utilizando sin pérdida de velocidad.

Este artículo pruebas que hacen 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 tout su aplicación co-rutinas, Python todavía gana.

Stackless sería bueno para la implementación de un mapa / reducir el algoritmo, donde se puede tener un gran número de reductores en función de los datos de entrada.

Answer 2

principal beneficio de Stackless Python es el soporte para corrutinas muy ligeros. CPython no soporta de forma nativa corrutinas (aunque espero que alguien para colocar un truco basado en el generador en los comentarios) para Stackless es una clara mejora con respecto a CPython cuando se tiene un problema que se beneficia de co-rutinas.

Creo que la zona principal donde sobresalen son cuando se tiene muchas tareas concurrentes que se ejecutan dentro de su programa. Algunos ejemplos pueden ser entidades de juegos que se ejecutan un script para su bucle de IA, o un servidor web que da servicio a muchos clientes con las páginas que tardan en crear.

Usted todavía tiene muchos de los problemas típicos con corrección de concurrencia sin embargo con respecto a los datos compartidos, pero la tarea de conmutación determinista hace que sea más fácil escribir código seguro, ya que sabe exactamente donde se transferirá el control y, por tanto, conocer los puntos exactos en los que Compartidos estado debe estar al día.

Answer 3

Thirler ya se ha mencionado que sin pérdida de velocidad se utiliza en Eve Online. Tenga en cuenta, que:

  

(..) sin pérdida de velocidad añade un nuevo giro a esto permitiendo que las tareas a ser separados en tareas más pequeñas, Tasklets, que luego se puede separar el programa principal para ejecutar por su cuenta. Esto puede ser usado para disparar y olvidar tareas, como el envío de un correo electrónico, o el envío de un evento, o para operaciones de IO, por ejemplo, envío y recepción de paquetes de red. Una tasklet espera a que un paquete de la red, mientras que otros siguen corriendo el bucle del juego.

     

Es en cierto modo como hilos, pero es no preferente y programados de forma explícita, por lo que hay menos problemas con la sincronización. Además, el cambio entre tasklets es mucho más rápido que la conmutación de hilo, y usted puede tener un gran número de tasklets activos mientras que el número de hilos está severamente limitado por el hardware del equipo.

(tengo esta cita de aquí )

En PyCon 2009 fue dado una charla muy interesante , describiendo por qué y cómo se utiliza en Stackless CCP Games.

Además, hay una muy buena material introductorio, que describe por qué sin pérdida de velocidad es una buena solución para sus aplicaciones. (Que puede ser un poco viejo, pero creo que vale la pena leer).

Answer 4

EVE Online está programado en gran medida en Stackless Python. Tienen varios dev blogs sobre el uso de la misma. Parece que es muy útil para la computación de alto rendimiento.

Answer 5

Aunque no he utilizado Stackless sí, he utilizado Greenlet para la implementación de aplicaciones de red altamente concurrentes. Algunos de los casos de uso Linden Lab ha puesto la directa hacia son: proxies de alto rendimiento inteligente, un sistema rápido para la distribución de órdenes más de un gran número de máquinas, y una aplicación que hace un montón de escrituras de base de datos y lee (en una proporción de aproximadamente 1 : 2, que está muy escribir-pesado, por lo que está pasando la mayor parte de su tiempo a la espera de la base de datos para volver), y una tela-correa-tipo-cosa para datos de la web internos. Básicamente, cualquier aplicación que está esperando tener que hacer un montón de red de E / S se beneficiarán de la posibilidad de crear un bajillion hilos ligeros. 10.000 clientes conectados no parece ser un gran problema para mí.

Stackless o Greenlet no son realmente una solución completa, sin embargo. Son de muy bajo nivel y vas a tener que hacer un montón de monkeywork para construir una aplicación con ellos que los utiliza al máximo. Lo sé porque mantengo una biblioteca que proporciona una capa de red y la programación en la parte superior de Greenlet, específicamente porque escribir aplicaciones es mucho más fácil con él. Hay un montón de estos ahora; Mantengo Eventlet, pero también hay concurrencia, quiral, y probablemente un poco más que yo no conozco.

Si el tipo de aplicación que desea escribir sonidos como lo que escribí sobre, 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 quiere hacer.

Answer 6

La utilidad básica de hilos verdes, la forma en que lo veo, es implementar un sistema en el que se tiene una gran cantidad de objetos que hacen 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 se puede utilizar incluso para hilos verdes en muy grandes cantidades. El request_information() anterior podría cambiar a algún programador en otro trabajo está a la espera y volver más tarde. Usted obtiene todos los beneficios de ser capaz de llamar "bloqueo" funciones como si regresan inmediatamente sin utilizar hilos.

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

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, hilos verdes se utilizan para mitigar el bloqueo, permitiendo que el código a ser escrito de forma natural y todavía funciona bien.