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

[Fernando Pelliccioni]

Atención: OFF-TOPIC creciendo exponencialmente!


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.
>


Aclaración: C++ no está atado a ser compilado estáticamente, hay
implementaciones que pueden hacer JIT compiling (Clang/LLVM) o incluso ser
interpretado (Cling), aunque no es común.

Lo del "potencial de ser más eficiente" se viene hablando desde los 90's,
hasta el momento no he visto ninguna implementación de un JIT que supere en
eficiencia a la compilación "tradicional".
Algunas optimizaciones son costosas y la diferencia entre un compilador
estático y un JIT es que el usuario está ahí, esperando a que la
optimización se lleve a cabo.
Así que la mayoría de los JIT compilers están forzados a omitir esas
optimizaciones, ya que el costo de optimizar es mayor que el beneficio.
Otra contra es que las optimizaciones de un JIT compiler son difíciles de
predecir y la documentación a veces es muy pobre (.Net / Java). Por esta
razón hay cierto tipo de aplicaciones donde no es posible usar JIT, porque
se necesita determinismo.

El GC es otro tema.
Con GC se requiere hacer un análisis en tiempo de ejecución para determinar
que memoria está siendo utilizada y cuál puede ser liberada. Y este
análisis puede ocurrir en cualquier momento y por una cantidad de tiempo
indefinida. Otro problema es cuando tenemos múltiples threads, cuando el GC
se ejecuta, todos los threads se pausan. Y por último, la mayoría de las
implementaciones no ejecutan el GC hasta que el sistema se queda sin
memoria.
Así que resumiendo: 1. nuestro sistema va a consumir cada vez más y más
memoria. 2. El programa se va a frizar aleatoriamente cuando el GC ejecute.

Ojo, el GC tiene grandes ventajas, ya que ahorra al programador
concentrarse en la administración de recursos, en realidad un recurso, el
más importante, la memoria.
Y hay casos, en donde los expertos aseguran que es imprescindible contar
con GC, como en algunas estructuras de datos lock-free.

En C++ contamos con otros mecanismos para administrar recursos y con la
posibilidad de *opcionalmente* usar un GC.
Esto es porque C++, al igual que C, son lo que se denomina "system
programming language". Esto es, lenguajes que sirven para escribir sistemas
(en vez de aplicaciones), ejemplos: Sistemas operativos, drivers,
compiladores, colisionadores de hadrones, sistemas de misión critica, Java
Virtual Machine, etc... :)
Los lenguajes para programación de sistemas no se pueden dar el lujo de
atarse a JIT o GC, por eso estos mecanismos son opcionales.

Por eso es que en ciertas áreas/industrias algunos lenguajes no son una
opción.
A eso iba mi pregunta a Alejandro... ¿qué necesitás hacer? ¿"cuanta"
eficiencia necesitás?



>
> 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.
>
>
Pienso justamente lo contrario.
Parafraseando un poco a Stepanov:
"Si un lenguaje/implementación es incapaz de optimizar cosas simples, es
muy poco probable que sea capaz de optimizar cosas más complicadas."

Pensamiento que comparto 100%.
La capacidad/incapacidad de un lenguaje/implementación de "eliminar la
abstracción" puede medirse con estos simples programas.
Pero bueno, entiendo que no todo el mundo piense igual, en ese caso,
hagamos el trabajo duro, implementemos el total de nuestra aplicación en N
cantidad de lenguajes/implementaciones y luego midamos. (Cuidado con las
mediciones tendenciosas).
Si quieren, estoy dispuesto a encarar el ejercicio, me gustan los desafíos
:)




> 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.
>
>
Comparto y tengo clara la diferencia. Por eso advertí en un email anterior
algunas implementaciones de C++ son menos eficientes que otras. Ídem en
otros lenguajes.
Pero más allá de las implementaciones, hay lenguajes que han sido diseñados
con la eficiencia como principio fundamental y hay otros que no. En C++ lo
llamamos Zero-Overhead.



> 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.
>
>

Creo que vamos a debatir eternamente :)
Yo creo que poner escribir "Java" y "eficiencia" en la misma oración podría
enojar a varios (a mi :)).
Ahora, fuera de broma, realmente creo que Java no es un lenguaje
caracterizado por su eficiencia, y más allá de los esfuerzos y mejoras
hechas, es un lenguaje que dista mucho de C o C++ y como dije antes, es un
lenguaje totalmente descartado para ciertas aplicaciones.
Creo que para comprobarlo tenemos que explorar un poco la realidad. Busquen
cuantos ejemplos de aplicaciones, de áreas donde la eficiencia es un MUST,
que hayan sido implementados eficientemente en Java (o lenguajes
similares). Creo que el porcentaje es mínimo comparado a los proyectos que
han "fracasado".
Analicen cual es la tendencia de los grandes de la industria (Google,
Microsoft, Apple, Amazon, Adobe, Facebook, ..., Electronic Arts, ...)


> 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
>


No existe un lenguaje perfecto, cada lenguaje es bueno en algo, ...pero, de
nuevo, si hablamos de eficiencia, la pregunta es: ¿cuánta necesitas?
Dependiendo de eso, el abanico de opciones se te acota a unos pocos
lenguajes, y no veo a Java incluido en ese conjunto.

Muchos de los temas que estamos hablando son de discusión eterna entre los
expertos, así que no creo nos pongamos de acuerdo nosotros los mortales.
Lo que me parece piola es encarar ciertos desafíos/programas en varios
lenguajes y medir la eficiencia, eso sirve como base para elegir que
lenguaje usar a la hora de encarar un proyecto.

Aquí datos sobre algunas aplicaciones "importantes" y el lenguaje en la que
están desarrolladas.
http://www.lextrait.com/vincent/implementations.html
http://www.stroustrup.com/applications.html

Un abrazo,
Fernando.
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20140304/27eb5852/attachment.html>