Re: Re: Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

[Horst H. von Brand]

Aldrin Gonzalo Martoq Ahumada <amartoq en dcc.uchile.cl> wrote:
> On Dec 3, 2007 10:59 AM, Xavier Andrade <xavier en tddft.org> wrote:
> > On Sun, 2 Dec 2007, Aldrin Gonzalo Martoq Ahumada wrote:
> > > Discrepo. Lo que se llama "maquina" es la definicion de una
> > > arquitectura y su set de instrucciones. Cuando se habla de "maquina
> > > virtual", se quiere decir que ese set de instrucciones no es el mismo
> > > que el implementado en hardware; por lo tanto si quieres ejecutar ese
> > > set de instrucciones requeriras de un paso de traduccion.
> > > Un interprete es un programa que realiza la traduccion desde un set de
> > > instrucciones o lenguaje y las ejecuta, de manera que puedas correr el
> > > codigo en tu maquina "real". La distincion importante es que el paso
> > > de traduccion se hace en tiempo de ejecucion; es decir, cada vez que
> > > corras el programa tendras el costo adicional de traduccion lo que
> > > puede traer problemas de performance o uso de recursos (memoria por
> > > ej). Por eso la *implementacion* de la maquina virtual de java es un
> > > interprete.

> > El problema es que no es tan claro hacer la distincion, de acuerdo a tu
> > definicion, x86(_64) es una maquina virtual, ya los procesadores modernos
> > implementan un set de instrucciones a la RISC internamente y en el momento
> > de ejecucion se traducen las instrucciones x86 a instrucciones nativas,
> > algunas directamente y otras por microcodigo.

> Exactamente, ese es el punto: los procesadores x86 modernos poseen un
> interprete!

Y, al final del dia, si el interprete del caso esta escrito en C, en
assembler 6502, en el lenguaje marciano que usa el Transmeta, esta
implementado en microcodigo, es la configuracion de un PLA o directamente
"alambrado" en circuitos da como lo mismo...

> Dicho de otra forma, si pudieramos compilar (traducir "offline")
> directamente en el codigo "nativo" del procesador, nos ahorrariamos
> varios ciclos de cpu (y tal vez transistores si dejamos esa pega
> exclusivamente al ambiente); que se  gastan en el interprete (traducir
> "online").

Nopes. El procesador es /mucho/ mas rapido que la memoria hoy dia (por algo
el cuento de hyperthreading, dual-core, procesadores celulares, ...). En
parte por esa razon guatearon los RISC, y las arquitecturas nuevas son
CISC: Claro, procesar instrucciones simples es mas rapido, pero el codigo
es muchisimo menos denso (todas las instrucciones son "grandes", para hacer
alguna operacion un poquitin mas compleja es media docena de instrucciones;
lo mismo en CISC puede ser una sola, incluso de un solo byte); con el
resultado que lo que se gana en el procesador se pierde con creces en mover
instrucciones desde la memoria.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513