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

[Claudio Freire]

2014-03-04 13:37 GMT-03:00 Fernando Pelliccioni <fpelliccioni en gmail.com>:
>> 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".

Acá[0] tenés algunos ejemplos (para citar de nuevo the benchmark game).

En síntesis, Java funciona *muy bien* para procesamiento numérico,
porque tiene la habilidad de eliminar por completo la abstracción,
pero sólo a nivel de instrucciones. Sigue manteniéndose un overhead
muy grande en las estructuras en memoria, y se ve en el benchmark.

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

Muchas de esas optimizaciones que mencionás involucran probar
propiedades del programa estáticamente, mirando sólo al código. Los
JIT no necesitan eso. Los JIT insertan "guardas" (testeos para
verificar que las asunciones se siguen cumpliendo) y listo, el resto
del código puede proceder como si se hubiera hecho todo ese análisis.

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

Ese artículo tan popular sobre JavaScript y por qué Java nunca va a
funcionar bien para celulares está lleno de falacias. Es cierto que
las implementaciones todavía no pueden correr perfectamente en
celulares, pero es "todavía".

Las técnicas clásicas de GC implementadas en las máquinas virtuales
modernas, por ejemplo, no requieren pausas. Son incrementales o
concurrentes, las primeras generan pausas pequeñas, las segundas no
generan pausa alguna. En multi-threading, usan guarderías, una
generación inicial local al thread, lo que hace que funcione mucho
(pero *mucho*) mejor que, por ejemplo, C++ con new o malloc.

Es común, cuando se quiere performance, en C++, empezar a eliminar el
uso de malloc y a codear nuestro propio "allocator". En sí, el manejo
de memoria sin GC no está libre de overhead, como cualquiera que haya
programado en C++ algún sistema de alta performance  debería saber.

Sin ir muy lejos, hay GC para C++. Uno muy común y muy usado, es el
contador de referencias. Que es mucho más propenso a leaks que los GC
que vienen ya embebidos en Java o Python. Yo personalmente aborrezco
el GC de Java. Tiene ciertas características que lo hacen una hoja de
doble filo muy peligrosa. Pero no por eso hay que creerse que C++ está
libre de problemas, incluso excluyendo el error humano.


[0] http://benchmarksgame.alioth.debian.org/u32/java.php