On Nov 16, 2007 1:16 PM, Franco Catrin L. <[EMAIL PROTECTED]> wrote:
>
> El segundo link casi me deja ciego ;)
Perdon. Me olvide de advertir que habia que ponerse lentes oscuros.
[sobre la diferencia entre maquina virtual e interprete]
Aun no me queda del todo clara la diferencia. Por ejemplo, hay alguna
diferencia de fondo entre un interprete Python ejecutando un archivo
.pyc o .pyo (no un .py) y una maquina virtual java ejecutando
bytecodes?
Alejandro.
From [EMAIL PROTECTED] Fri Nov 16 18:21:14 2007
From: [EMAIL PROTECTED] (Xavier Andrade)
Date: Fri Nov 16 19:04:23 2007
Subject: =?utf-8?q?Re=3A_Benchmarking_en_distintos_lenguajes_=5B_Era_a?=
=?utf-8?q?lgo_as=C3=AD_como_cliente_en_jabber=2E=2E=2E_=5D?=
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
On Fri, 16 Nov 2007, Franco Catrin L. wrote:
>
> Supongo que es porque rompen el principio de localidad [1].
>
Principalmente es el costo asociado a llamar una funcion, el paso de
argumentos, guardar registros, etc.
>
> Yo me referÃa a otros casos pero igual es interesante:
> La máquina virtual de Java puede aplicar inline en algunos métodos siempre
> y cuando estos métodos no sean sobreescritos, por ejemplo todos aquellos que
> sean static o final... pero... además en tiempo de ejecución puede deducir
> que un método puede ser "inlined" de forma segura, porque ya sabe que no
> esta sobreescrito. De esta forma el programador no necesita cambiar su
> código y es la máquina virtual quien se hace la astuta, lo malo es que hay
> programadores que declaran todo como public. [2]
>
> Si no me equivoco los compiladores de C tambien son capaces de reconocer
> código que conviene dejar como inline.
El problema es que en C, a diferencia de Java, la mayoria de las veces no se
tiene el codigo que se podria hacer inline. A veces no se sabra que funcion
es hasta el momento de la ejecucion (punteros a funciones o funciones
virtuales en C++)
De hecho, algunos compiladores de C/C++ o Fortran en los niveles de
optimizacion mas agresivos (normalmente con el flag -ipa), no compilan el
codigo al generar los .o, sino que al momento de enlazar juntan todas la
fuentes haciendo un analisis completo de la ejecucion para ver que se puede
hacer inline (entre otras optimizaciones), por supuesto esto toma mucho
tiempo y consume cantidades obscenas memoria.
> Y finalmente.. los problemas de rendimiento en aplicaciones de las que me
> toca ver a mi casi siempre son debido a latencias por I/O :(
>
Bueno, si. Lo que yo menciono se da mas en codigo numerico orientado al
objeto donde la optimizacion a nivel de ejecucion en el procesador cuenta.
Saludos,
Xavier
From [EMAIL PROTECTED] Fri Nov 16 19:10:10 2007
From: [EMAIL PROTECTED] (Alvaro Herrera)
Date: Fri Nov 16 19:12:58 2007
Subject: Benchmarking =?iso-8859-1?q?en_distintos_lenguajes_?=
=?iso-8859-1?q?=5B_Era_algo_as=ED?= como cliente en jabber... ]
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Rodrigo Fuentealba escribió:
> El 16/11/07, Xavier Andrade <[EMAIL PROTECTED]> escribió:
> >
> > Claro, pero eso no es programacion orientada al objeto ni ninguna tecnica de
> > programacion sofisticada. El punto es que con POO puedes llegar a tener
> > casos
> > equivalentes a ese.
>
> Un método en OOP es una mera función,
Solo si tu jerarquia de clases es de un solo nivel, que no es lo que se
"estila". Un sistema un poquito mas complejo requiere que en tiempo de
ejecucion se haga una busqueda del metodo invocado en una tabla de
metodos, y si no aparece entonces tienes que ir a la clase padre a ver
si esta implementado ahi, y asi hasta llegar al tope de la jerarquia de
clases.
--
Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC
"La primera ley de las demostraciones en vivo es: no trate de usar el sistema.
Escriba un guión que no toque nada para no causar daños." (Jakob Nielsen)
From [EMAIL PROTECTED] Sat Nov 17 00:13:37 2007
From: [EMAIL PROTECTED] (Franco Catrin L.)
Date: Fri Nov 16 21:16:21 2007
Subject: =?iso-8859-1?q?Re=3A_Benchmarking_en_distintos_lenguajes_=5B_Era?=
=?iso-8859-1?q?_algo_as=ED_como_cliente_en_jabber=2E=2E=2E_=5D?=
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Alejandro Weinstein escribió:
> On Nov 16, 2007 1:16 PM, Franco Catrin L. <[EMAIL PROTECTED]> wrote:
>
>> El segundo link casi me deja ciego ;)
>>
>
> Perdon. Me olvide de advertir que habia que ponerse lentes oscuros.
>
> [sobre la diferencia entre maquina virtual e interprete]
>
> Aun no me queda del todo clara la diferencia. Por ejemplo, hay alguna
> diferencia de fondo entre un interprete Python ejecutando un archivo
> .pyc o .pyo (no un .py) y una maquina virtual java ejecutando
> bytecodes?
>
Cuando hablamos de máquina virtual con JIT piensa en lo siguiente:
* fuente (.java) -> compilador -> bytecode(.class)
El bytecode es código de maquina
La máquina virtual toma el bytecode y lo transforma a código de maquina
nativo en memoria asi:
* bytecode (.class) -> JIT -> binario x86
Luego tu procesador ejecuta el binario x86 generado como si hubiera sido
hecho en C/ASM
Cuando tienes un interprete como python, javascript, etc tienes lo
siguiente:
* fuente (.py) -> compilador -> tokens (.pyc)
El .pyc son tokens, es decir, las instrucciones del código fuente se
convierten de texto a números que la representan, pero no hay código de
máquina involucrado.
Cuando ejecutas el codigo tienes:
* tokens (.pyc) -> interprete -> funciones del mismo interprete.
No hay generacion de codigo nativo, sino que el inteprete en base a los
tokens comienza a ejecutar distintas secciones de si mismo. Imaginate
un gigante "if" o un gigante "switch/case" que va consumiendo tokens.
Una de las gracias de los lenguajes intepretados como python es que son
dinámicos, pueden evaluar código al momento de ejecutarse y comportarse
dependiendo de un estado en tiempo de ejecución, esto gracias a que se
va viendo token a token.
Para el caso de python puedes mirar en Python/eval.c
http://svn.pythonmac.org/python24/python24-fat/Python/ceval.c
Para el caso de JIT hay una charla de Miguel de Icaza con ejemplos y
todo, incluso generando bytecode a partir de Python, una de las gracias
de Mono y .NET
Saludos
--
Franco
