[pyar] [OT] sobre un "segundo" lenguaje...

[Angel Java Lopez]

Ah! Interesante discusion.

Algun comentario:

Los compiladores JIT hay mejorado con los anios. Y si el lenjuage original
es tipado, la compilacion a VM, y luego, la compilacion de VM a codigo de
maquina anfitriona (sea JIT o no), tambien ha ido mejorando.

El gran tema es como se implementa

a+b

a.m(b)

en el lenguaje. En un lenguaje tipado, con Virtual Machine por debajo, y
Garbage Collector, como Java/C#, el

a+b

es bastante eficiente, por lo que vi. No recuerdo ahora Java, pero .NET
tiene desde el vamos el concepto de compilar a codigo nativo cuando va a
ejecutar lo de su VM. Y las optimizaciones que se pueden hacer ahi (no se
hasta donde llegaron ahora), tanto en C# Microsoft, como Mono, harian que
a+b se acerque al codigo de assembler.

En lenguajes dinamicos como Python y Ruby, no hay otra que ir haciendo JIT
por tipo. Cuando ve que a+b son ambos enteros, genera un codigo de maquina
adecuado a ello. Eso lo vi tambien en la HipHop de PHP de Facebook, en
IronPython, en IronRuby y debe estar en otros. Pero hay un chequeo de tipos
cada vez que pasa por ahi. Lo que si puede hacerse es:

def add(a,b):
   a+b

chequear los tipos a la entrada del def, y generar todo un codigo
optimizado nativo para cuando se llama a add con enteros. Otra mas que
puede hacerse: descubrir que add solo se llama con enteros, hacer
inferencia de los tipos de llamada

Otra bestia a domar es:

a.m(b)

Como resolver el metodo m? En lenguajes como JavaScript, e imagino Python
tmb, el metodo puede ser del objeto, no de la clase. Hay que hacer lookup
cada vez que pasamos por ahi. En Java, los metodos son virtuales, y de
nuevo, no escapamos de lookup. En C#, los metodos puede no ser virtuales. y
el llamado es como en C clasico: resuelto a nivel de compilacion en esos
casos.

Pero si, lo que ha traido Lisp, Smalltalk, y en tiempos modernos, Java, C#,
es garbage collector. Pueden ver la influencia de GC en el enlace enviado
por Fernando Pelliccioni

http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

Hmmm... no se recuerdo como era el common lisp, pero
(+ a b)
puede ser compilado en algunas implementaciones a nativo

Clojure tiene type hints para mejorar la experiencia de compilacion, que
recuerde.

Lo que si tiene C, C++ es la capacidad de metodos inline. El caso

abs(a,b)

en vez de llamar a una funcion, puede expandirse en ese momento a codigo en
ese lugar. En .NET 4.5 empieza aparecer algo como inline, pero no se cuanto
se ha llegado a poner eso en la libreria core

Resumen:
- Tipado vs no tipado a tiempo de compilacion: lo tipado permite
implementacion nativa o a VM

- Compilacion de VM (bytecodes?) a nativo
  - sobre tipado, puede generar codigo nativo, la eficiencia depende de las
optimizaciones del compilador de esta fase
  - sobre no tipado, puede ver los tipos que llegan (a entero?, b entero?)
y determinar generar codigo para ese caso

- Llamada a metodo
  - se puede transformar a inline?
  - es metodo virtual, no zafamos de lookup?

- Garbage collector
  - el precio a pagar

Nos leemos!

Angel "Java" Lopez
@ajlopez



2014-03-04 1:32 GMT-03:00 Claudio Freire <klaussfreire en gmail.com>:

> 2014-03-03 22:29 GMT-03:00 Fernando Pelliccioni <fpelliccioni en gmail.com>:
> >
> > Me olvidaba,...
> > Otro tema importante es cuan compactas son las estructuras de datos
> típicas
> > del lenguaje.
> > Creo que un problema que tenían los primeros LISP's era que no existían
> > estructuras de memoria continua (arrays), sino que eran listas enlazadas,
> > quizás luego las incluyeron, no lo sé.
> > En las arquitecturas modernas, las estructuras de datos y objetos que
> > consumen poca memoria son fundamentales porque cuanto menos memoria,
> menos
> > probabilidad de "d-cache misses".
> >
> > Realmente no conozco nada de Common-Lisp, pero que sea un lenguaje
> dinámico
> > y tenga GC me hace creer que no es muy eficiente.
>
>
> Hay dos formas de lograr eficiencia ante la presencia de abstracción
> en el lenguaje (o, mejor dicho, voy a mencionar 2).
>
> Una, es optimización en tiempo de compilación. Que el compilador
> elimine la abstracción y genere código concreto y eficiente. Esto es
> C++.
>
> Pero un lenguaje dinámico y con GC no necesariamente está excluído,
> puesto que esta tarea también se puede hacer en tiempo de ejecución,
> como lo demuestran PyPy, Java, Smalltalk y tantos otras
> implementaciones de lenguajes dinámicos con JIT.
>
> A diferencia de una optimización estática, la optimización JIT se
> adecua al input del programa, y tiene el potencial de ser aún más
> eficiente.
>
> No es un tema sencillo ni es blanco ni negro, pero ciertamente
> considerar programas minimalistas para evaluar la "capacidad de
> abstracción eficiente" de un lenguaje es un esquema inadecuado, dado
> que lo que nos interesa es la habilidad de la *implementación* de
> *eliminar la abstracción*, cosa que realmente no se puede poner a
> prueba en programas pequeños con escasa arquitectura.
>
> Y ahora quiero llamar la atención a cómo fui cambiando el lenguaje
> para empezar a hablar de implementaciones y no lenguajes. Python es un
> ejemplo clarísimo de por qué hace falta considerarlos separados:
> cython, jython, pypy, CPython, todos implementan el mismo lenguaje
> pero con características de performance completamente diferentes.
>
> Aún así, creo que los lenguajes por excelencia en su capacidad de
> "abstraer eficientemente" son Java y C++. Java en menor medida que
> C++, pero sigue realizando un trabajo estelar en eliminar el costo
> computacional (aunque no en memoria) de la abstracción.
>
> PyPy se acerca a Java cada día, y lo mantengo vigilado, pues creo que
> puede llegar a superarlo, pero no puedo decir aún que esté a la altura
> de esos dos. Python como lenguaje me encanta, pero ninguna
> implementación te permite abstraer sin remoridimientos,
> lamentablemente. La abstracción en Python cuesta performance, siempre.
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20140304/43e5f351/attachment.html>