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

[Fernando Pelliccioni]

2014-03-04 10:38 GMT-03:00 Alejandro Santos <listas en alejolp.com>:

> 2014-03-04 2:29 GMT+01:00 Fernando Pelliccioni <fpelliccioni en gmail.com>:
> >
> > 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.
> >
>
> El GC fue inventado por la gente de LISP para resolver el problema de
> las dependencias circulares[1], y muchos de los algoritmos modernos ya
> sea de Java, .Net, etc, estan inspirados en este trabajo.
>
> De todas formas no creo que por decir que "tenga GC" sea razon
> suficiente para decir que no sea muy eficiente. Depende mucho de la
> vara de bambu que uses para medir, porque por ejemplo tenes estos
> micro benchmarks donde C++ es solo el doble de r'apido que (SBCL) LISP
> y Haskell:
>
>
> http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=sbcl&lang2=gpp&data=u64
>
> http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=ghc&lang2=gpp&data=u64
>
> Ambos con Garbage Collection.
>
>

En general, sobre los benchmarks:
A veces los benchmarks pueden ser manipulados para obtener uno u otro
resultado.
Para considerar cualquier benchmark como una prueba, en mi opinión, tendría
que confiar que la fuente y verificar que haya buena intensión.
A veces es imposible probarlo, así tendría ponerme a analizar el código
fuente de los lenguajes que están siendo comparados.
Hay veces que los benchmarks son escritos por expertos de un lenguaje X,
comparándose contra código ineficiente implementado en un lenguaje Y.
También hay que ser conscientes a veces no estamos comparando lenguajes,
sino implementaciones de los mismos. (No es lo mismo comparar Java contra
C++ compilado usando MSVC, por ejemplo)
(Fin de pensamientos acerca de Benchmarks)

Ahora específicamente sobre tus ejemplos, no vi los links pero decís que
"solo es el doble de rápido".
Para mí el doble de rápido es "un montón". El doble de rápido puede
significar el doble de energía consumida, la mitad de la batería de tu
celular, el doble de usuarios concurrentes, la mitad de $$$, etc...

Fíjense el video este video, a desde 00:02:45, hasta 00:03:30, menos de un
minuto (Seguramente ya lo viste)
El que habla es un investigador que actualmente trabaja en Facebook.
Y dice que midieron que una mejora de un 1% en el JIT Compiler significa
aprox. 10 años de sueldo del programador mejor pago.

http://channel9.msdn.com/Events/GoingNative/2013/Writing-Quick-Code-in-Cpp-Quickly

Así, ¿cuánto significaría 2x para Facebook? Mucha $$$



> Me gusto mucho la pregunta de Claudio Freire porque todo depende de lo
> que cada uno entienda "Expresivo", porque si por expresivo queres
> decir que queres usar hasta la ultima capacidad de expresion de tu
> CPU, deberias estar usando ASM ya que es la unica manera de usar cada
> posible optimizacion.
>
>
Es un muy buen punto, por eso me pareció piola hacer el PingPong Python /
C++ sobre "expresividad" ya que quizás podía cambiar su opinión.
Pero creo que es al revés, que expresivo significa "capacidad de
abstracción", cuando más expresivo más nos alejamos de assembly code.



> A mi personalmente me parece que, en general, un lenguaje de
> programacion es una forma para que los programadores nos comuniquemos
> ideas entre nosotros, y en menor medida como un mecanismo para
> comunicarse con una computadora.
>
> Es cierto que hay algunos problemas que se requiere eficiencia bruta y
> cruda, pero otros donde no es tan importante el tiempo "wall clock" de
> ejecucion sino la productividad de los programadores. Esto es asi
> cuando hay que tener en cuenta la economia completa del proyecto:
> ?qu\'e es m\'as barato, comprar m\'as procesamiento o pagarle a mas
> programadores?
>


Comparto totalmente!
2x en rendimiento puede ser mucha $$$ para Facebook, pero quizás para
nuestra simple aplicación rinde más ganar un 2x de velocidad de
codificación de mis programadores.
Sin embargo, siempre que pienso en esto, me surgen sentimientos
encontrados. Se me cruza por la cabeza: el trabajo científico vs la
administración de la economía de una empresa por reducción del tiempo de
programación. A veces pensar en eso me da escalofríos.




>
> Si en cambio estas trabajando en un proyecto donde estas vos por tu
> cuenta entonces usa el lenguaje que mas comodo te resulte.
>
> Aca donde trabajo usamos C++, Java y Python. C++ para codigo con
> fuertes limitaciones de tiempo que corran en el datacenter (10,000
> servidores), Python para programas que no importe la eficiencia de CPU
> o memoria, y Java para todo lo demas.
>
>

Me parece genial el esquema.


> [1] http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29
>
>
> --
> Alejandro Santos
> _______________________________________________
> 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
>


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