El día 2 de marzo de 2010 15:30, CaStarCo <[email protected]> escribió: > 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. >
Sí, esto es lo primero que le pude aportar al amigo... > 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. > Oye, está buena esa entrada de blog, le voy a echar un ojo con calma. Bueno en fin, hasta ahorita no he podido ayudar bien al amigo, esto es lo último que le respondí: ""' Bicho son varias cosas. He estado viendo algunas cosas, pero no es mucho. Sí, veo que usa la pila exhaustivamente. Por ejemplo: >>> def foo(a, b): return a + b + 1 >>> import dis >>> dis.dis(foo) 2 0 LOAD_FAST 0 (a) 3 LOAD_FAST 1 (b) 6 BINARY_ADD 7 LOAD_CONST 1 (1) 10 BINARY_ADD 11 RETURN_VALUE >>> co_varname es una tupla con los nombres de las variables locales. LOAD_FAST apila una referencia a la variable co_varname[var_num]. En el ejemplo de arriba, 0 LOAD_FAST apila una referencia a la variable co_varname[0] (que es igual a 'a'). Entonces, para esto supongo que busca en la tabla de simbolos donde está la 'a' local y esa dirección es la que apila. La cosa es que el acceso a una variable es super indirecto. Es decir, primero obtienes de una tupla compilada en el código llamada co_varname el nombre de la variable, luego buscas la referencia en la tabla de simbolos, y es esa la referencia que apilas. Supongo que en Java pudieras tener co_varref de una vez ya que es compilado. Lo de la tabla de símbolos en el heap o la pila no le veo mucho sentido. Sí, acceder a la pila es por lo general más rápido que al heap, pero no me parece algo muy influyente en el tema de la velocidad final de un programa. ¿cómo se implementan los tipos en Python? por ahora supongo que cada objeto lleva con sigo a su vez un descriptor del tipo, para indicar entre otras cosas cuánto está ocupando en memoria. Pero no lo puedo asegurar. Sigo buscando... """ Sin embargo, esto[1] puede ser de utilidad. > Puede ser interesante que te pases por el planet de python, > planet.python.org > Sí, es verdad. Gracias. > Un saludo! > Saludos. [1] http://www.python.org/doc/faq/general/#how-does-python-manage-memory > 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 > > _______________________________________________ GUPy mailing list [email protected] http://proyectociencia.org/cgi-bin/mailman/listinfo/gupy
