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

[Fernando Pelliccioni]

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

> 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).
>
>
Perdón, me perdí, ¿ejemplos con respecto a que cosa?
Tengo pendiente chequear el código de algunos lenguajes y cuál es el
mecanismo de medición.
Después les digo.


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

En procesadores modernos Memoria está relacionado con Cache y Cache está
relacionado con eficiencia en ejecución.
Ni hablar de entornos con limitaciones de memoria, como embedded.
No confío en ese BM, luego de analizarlo les digo si estuve equivocado o no.


>
> > 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.
>
>
No creo haber nombrado ninguna técnica de optimización en particular de los
JIT's.
Pero ninguna es Zero-cost, ya que se hace en runtime.
En ejecuciones largas, quizás pueda ser beneficioso, pero, uno también
puede obtener los mismos beneficios usando PGO y evitar optimizar en
runtime.



> > 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".
>
>
¿Cuáles son las falacias? Las podemos analizar en detalle.
Hoy en día es una realidad y las aplicaciones escritas en ciertos
lenguajes, en celulares "se arrastran".



> 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.
>
>
En los GC incrementales las pausas no son pequeñas. (y las pausas pequeñas
son pausas al fin y al cabo)
Y los GC concurrentes no están libres de pausas, las pausas se reducen con
respecto al anterior, pero las hay en caso de necesitar Full-GC.
Igualmente, más allá de que el usuario note una pausa o no, ¿todo este
análisis es sin costo?, y reitero, ¿qué pasa con los sistemas que requieren
determinismo?
Me agrego otra tarea, hacer un programita que provoque una pausa en un GC
Java Moderno y medirla.

Me queda una pregunta, ¿cómo es eso de "generación inicial local al
thread"? ¿qué es lo que es local al thread?



> 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.
>
>
En C y C++ muchas veces ni siquiera es necesario "allocar" memoria en el
free-storage (heap).
Pero en el caso de ser necesario, como dijiste, están los Allocators, y
también hay implementaciones de malloc mucho más eficientes, como por
ejemplo:
jemalloc (usada por defecto en FreeBSD)[1] y TCMalloc de Google[2], entre
otras.
Uno puede reemplazar malloc por alguna de estas. ( y también new, que por
defecto usa malloc )
Tarea nro 3: medir la eficiencia en "allocación" de memoria dinámica de
Java con su moderno GC contra C++ con mallocs modernos.



> 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.
>
>
Sí, hay GC para C y C++, creo haberlo comentado, pero el GC es opcional.
Uno bien podría usar el "Boehm GC" (creado por Hans Boehm, miembro del C++
committee y colaborador de Alex Stepanov en Sillicon Graphics, por allá en
los 90's) o cualquier otro existente.
También existe el concepto de Ownership, Unique y Shared. Shared ownership
es implementado usando conteo de referencias.
Unique ownership es Zero-overhead con respecto a la implementación
"manual", es como hacer:

auto x = new X;
delete x;

El conteo de referencias tiene el problema de las referencias circulares,
pero es solucionado, en C++, usando Weak pointers. Igualmente no es muy
común casos como este.

Igual, de nuevo, todo esto es heap allocation, y en C++ no estamos obligado
a usarlo.

En C++ el concepto de ownership va más allá de la memoria, aplica a
recursos en general (files handles, sockets, conexiones a DB, etc...)

El error humano está en todos lados, un leak puede cometerse por olvidarse
eliminar un elemento de una Lista.

C++ realmente no está libre de problemas, para nada, pero uno que no tiene
es la eficiencia.

Saludos,
Fernando.

[1] http://www.canonware.com/jemalloc/
[2] http://goog-perftools.sourceforge.net/doc/tcmalloc.html



>
> [0] http://benchmarksgame.alioth.debian.org/u32/java.php
> _______________________________________________
> 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/08986f75/attachment-0001.html>