2009-09-17 12 views
5

Psyco es un compilador especializado para Python. El documentation states¿Por qué Psyco usa mucha memoria?

Psyco puede y va a utilizar grandes cantidades de memoria.

¿Cuáles son las principales razones para utilizar esta memoria? ¿La sobrecarga de memoria es una característica de los compiladores de JIT en general?

Edit: Gracias por las respuestas hasta el momento. Hay tres posibles contendientes.

  • escritura múltiples bloques especializados, cada uno de los cuales requieren de memoria
  • arriba debido a la compilación de la fuente sobre la marcha
  • arriba debido a la captura de datos suficientes para hacer perfiles dinámicos

La pregunta es, ¿cuál es el factor dominante en el uso de memoria? Tengo mi propia opinión ¡Pero estoy agregando un bounty, porque me gustaría aceptar la respuesta correcta! Si alguien puede demostrar o probar dónde se usa la mayoría de la memoria, la aceptaré. De lo contrario, quienquiera que vota la comunidad será aceptado automáticamente al final de la recompensa.

Respuesta

2

La sobrecarga de memoria de Psyco es actualmente grande. Me he reducido un poco con el tiempo, pero sigue siendo una sobrecarga. Esta sobrecarga es proporcional a la cantidad de código de Python que Psyco reescribe; por lo tanto, si su aplicación tiene algunas funciones algorítmicas de "núcleo", estas son las que usted querrá que Psyco acelere, no todo el programa.

Así que creo que los requisitos de memoria de gran tamaño se deben al hecho de que está cargando la fuente en la memoria y compilándola a medida que avanza. Cuanta más fuente intente y compile, más necesitará. Supongo que si trata de optimizarlo, buscará múltiples soluciones posibles para tratar de identificar el mejor caso.

10

De la web psyco "La diferencia con el enfoque tradicional de los compiladores JIT es que Psyco escribe varias versiones de los mismos bloques (un bloque es un poco de una función), que están optimizados por estar especializado para algunos tipos de las variables (un "tipo" puede significar un tipo, pero es más general) "

5

" Psyco utiliza los datos de tiempo de ejecución real de que su programa manipula para escribir potencialmente varias versiones del código de máquina, cada uno de manera diferente especializada para diferentes tipos de datos ". http://psyco.sourceforge.net/introduction.html

Muchos compiladores JIT trabajar con lenguajes de tipos estáticos, para que sepan lo que los tipos son tan puede crear código de máquina para sólo los tipos conocidos. Los mejores hacen perfiles dinámicos si los tipos son polimórficos y optimizan las rutas más comunes; esto también se hace comúnmente con idiomas que incluyen tipos dinámicos y daga; Parece que Psyco protege sus apuestas para evitar hacer un análisis completo del programa para decidir cuáles podrían ser los tipos, o perfilar para encontrar cuáles son los tipos en uso.

& dagger; Nunca he profundizado lo suficiente en Python para determinar si tiene o no tipos dinámicos (tipos cuya estructura puede modificarse en tiempo de ejecución después de que los objetos se hayan creado con ese tipo), o solo las implementaciones comunes solo revisan tipos en tiempo de ejecución; la mayoría de los artículos hablan sobre tipado dinámico sin definirlo realmente en el contexto de Python.

+4

¡Buen uso de & dagger para implementar una nota de pie de aspecto apropiado! – unwind

+0

Definitivamente puede agregar miembros y funciones a una instanciación de una clase sobre la marcha. Puede descargar, modificar y luego volver a cargar un módulo que contenga una clase y comenzar a usar el nuevo. –

+0

¿Eso cambia los objetos existentes con esa clase, o solo los nuevos creados después de la recarga? –

2

Definitivamente el uso de la memoria psyco proviene de bloques ensambladores compilados. Psyco sufre a veces de sobreespecialización de las funciones, lo que significa que hay múltiples versiones de los bloques de ensamblador . Además, que también es muy importante, psyco nunca libera una vez asignados los bloques de ensamblador , incluso si el código asociado con él está muerto.

Si ejecuta su programa en Linux, puede ver/proc/xxx/smaps para ver un creciente bloque de memoria anónima, que está en una región diferente de Heap. Esa es la parte anónimamente mmap'ed para anotar el ensamblador, que por supuesto desaparece cuando se ejecuta sin psyco.