Relevante para los pythoneros:
“Grumpy has no global interpreter lock”
Relevante para los pythoneros:
“Grumpy has no global interpreter lock”
Me gusta Python para lo que hago, qye son básicamente scripts para resolver problemas aplicados y para programas sencillos.
jenkins
Que éxito sin GIL. Pypy tampoco tiene GIL, había un experimento con un JIT compiler sin GIL, y el branch gilectomy tampoco tiene GIL.
Pero el diablo está en los detalles
Uno de los problemas más importantes de Pypy es que no sirven las extensiones nativas (en C)
Que si funciona con CPython
Como Go soporta C creo que sería bastante natural adaptarlo
Claro, reimplementar Python.h para que funcione en ese runtime debe ser una tarea titánica, y ni siquiera estoy seguro que tenga sentido
Por ejemplo, en Python.h uno tiene que incrementar y decrementar el contador de referencias de un objeto manualmente.
Que es un detalle de implementación del intérprete
“First, we decided to forgo support for C extension modules.”
“The goal is for Grumpy to be a drop-in replacement runtime for any pure-Python project.”
Lo que lo coloca al mismo nivel que Pypy, tal vez más rápido, pero con los mismos inconvenientes :’(
“Grumpy has no global interpreter lock, and it leverages Go’s garbage collection for object lifetime management instead of counting references”
Es garbage collected, nice
Es una verdadera lástima que sea un transpiler para CPython 2.7 :’(
Entiendo por qué lo hicieron, pero 2.7 apesta.
Lo están haciendo para no tener que migrar a python3, pasar directo a go.
Está tuanis igual
jenkins
Si, de hecho Había varios comentarios diciendo que el código generado en Go era horrible, pero que aún así era más rápido en multithread, pero más lento en single thread.
Aunque más rápido o más lento es siempre relativo al problema.