No sé demasiado todavía sobre el asunto, aunque me interesa mucho y quería estudiarlo este verano que viene cuando acabe exámenes... en principio, al margen de los mecanismos que use python, el rendimiento que obtengais con éste será menor que el que habéis conseguido con Java.
Hay implementaciones especiales de Python que permiten mejoras drásticas de rendimiento, como stackless (que no usa pila). Por otro lado podéis programar librerías en C y hacer bindings muy fácilmente (se aprende a hacer los bindings en media tarde), respecto a los pools de objetos.. yo estoy usando un pool de objetos con memcached en el proyecto tabularium (que por el momento anda un poco parado por todo el trabajo de la universidad y las clases que doy para subsistir). Para acabar, añado que existe un módulo de python que permite analizar el bytecode generado de forma sencilla, supongo que ya lo debes conocer por lo que has comentado.. pero por si acaso, el módulo se llama dis. Hice una traducción de un artículo que hay en el planet de python.org, http://blog.viricmind.org/2009/08/26/python-bytecode-disassembler-dis/ en el que se analiza un caso práctico usando el módulo dis para conseguir optimizar código. Puede ser interesante que te pases por el planet de python, planet.python.org Un saludo! El 2 de marzo de 2010 20:45, Jesús Francisco <[email protected]> escribió: > Saludos. Un amigo mío preocupado por la posibilidad de que le obliguen > a cambiar el lenguaje de su proyecto de Java a Python ha pedido ayuda > publicamente para entender mejor a Python a bajo nivel. En concreto > escribió lo siguiente: > > """ > Bueno, no tengo nada en contra de Python (he programado pocas veces > en él, pero hasta donde he podido experimentar, es divertido), sin > embargo, a estas alturas cambiar el lenguaje seria iniciar el proyecto > de -1 (ni siquiera de 0) > > El algorimo critico del mounstruo es a juro O(n), donde n puede ser > hasta 4 Gb (en promedio archivos de 2 Gb) le hemos echado pierna a la > implementacion para evitar el uso de new: reciclamos objetos mediante > pools pre reservados, usamos primitivos para casi todo, creamos > nuestro propio StringBuilder, reescribimos partes de MutableBigInteger > y MutableBigDecimal para evitar que crearan objetos temporales > internamente, pre pre pre calculamos cualquier vaina pre calculable... > En fin, hemos hecho de tooodooo, nos faltaria donarle sangre a esa > broma > > Ahora si nos cambian a Python, la tipificación es dinamica, eso > implica que cada variable va a la tabla de simbolos del interprete, > no? En teoria (repito, en teoria) eso implica una entrada en el heap > en lugar de una entrada en el stack, por lo de la tabla, no?... > > Mi punto es probar que Python (por ser dinamicamente tipificado) usa > internamente entradas al heap que no podriamos controlar, que es lo > que evitamos en la implementacion del algoritmo (evitar hacer new, > pues con 4 Gb varios new por linea degradan el rendimiento por la > fragmentacion de la memoria etc, y hacer una freelist en Java es > absurdo) > > Ahora, al examinar el bytecode generado por python (link > http://docs.python.org/library/dis.html), este utiliza una pila igual > que el bytecode de la jvm... entonces? > > Python tiene tipificacion dinamica, pero como se implementa > internamente su tipificacion????? > > Enlaces, comentarios, sugerencias, opiniones, lo que sea! > > Help! SOS (Save Our Souls literalmente) > > Otra cosa, la maquina virtual de Python aplica algún algoritmo de > verificación al bytecode antes de ejecutarlo como lo hace la JVM de > Java? > """ > > Apenas estoy masticando el mensaje, y ya estoy googleando. Sin embargo > tengo que salir y continúo con el tema pronto, así que agradezco > cualquier ayuda. > > Saludos. > _______________________________________________ > GUPy mailing list > [email protected] > http://proyectociencia.org/cgi-bin/mailman/listinfo/gupy > -- - Per la llibertat del coneixement - - Per la llibertat de la ment... -
_______________________________________________ GUPy mailing list [email protected] http://proyectociencia.org/cgi-bin/mailman/listinfo/gupy
