----- Original Message -----
> From: Joaquin Ferrero <[email protected]>
> To: [email protected]
> Cc:
> Sent: Wednesday, December 3, 2014 10:03 PM
> Subject: Re: [Madrid-pm] Nueva herramienta para procesar la ingente cantidad
> de textos de la web
>
> El 03/12/14 a las 09:12, Roberto Henriquez escribió:
>> On 12/03/2014 06:25 AM, Alex Muntada wrote:
>>> Para más inri está escrito en python, casi parece una broma...
>>>
>>> Lo de que sea más rápido en java parece ser por el modo de ejecución de
>>> hadoop para lenguajes no java.
>>>
>>
>> Eso es lo que yo entiendo, según el readme: «Even though Hadoop Streaming
> is a very useful tool, important degradations in the performance were
> detected
> using Hadoop Streaming with respect to Hadoop Java codes.»
>>
>> Parece que el problema viene de algún overhead de Hadoop Streaming.
>>
>> saludos!
>
> Estoy sospechando que el tema puede estar en el tiempo que Perl
> "pierde" en el proceso de compilación de los programas, antes de
> ejecutarlos, cosa que los de Java no tienen (se compilan una vez).
>
> O algo peor... que estén usando un Perl v5.8.8 en Red Hat 2008-2010...
> entonces
> sí que queda claro: el intérprete de Perl tenía un bug en la reserva de
> memoria,
> que lo hacía mucho más lento de lo normal.
>
> Es que, otra razón, no se me ocurre. Y eso que he visto cantidad de ejemplos
> en
> los que la ejecución de Perl es más rápida y con muchos menos recursos que
> Java,
> haciendo la misma tarea.
Perl es un lenguaje interpretado, por un interprete diseñado hace mas de 20
años y que en esos 20 años la mayoría de los cambios que le han echo han sido
chapuzas que no se adaptaban bien al diseño original (tie, prototipos, threads,
overload, etc.) y que aunque no han tenido un gran impacto en el rendimiento si
que han sido bloqueantes a la hora de mejorarlo.
Por el otro lado, cuando apareció Java hace también casi 20 años, el runtime,
la JVM, era una porquería, pero en este tiempo lo han reescrito varias veces,
aplicado todas las técnicas de optimización conocidas. El HotSpot actual que
viene a ser un JIT que optimiza de forma dinámica los puntos calientes, es una
pasada. Lo mismo pasa con los algoritmos de gestión de memoria, de lo mejorcito
que hay (¡y en Perl seguimos contando referencias!). Hoy en día, el rendimiento
en la JVM es similar al de programas en C o C++. Solo, en código de muy bajo
nivel puede quedarse Java un poco atrás.
La cuestión es que si hubiese una definición del lenguaje o este fuese más
simple, acabarían apareciendo nuevas implementaciones para otras tecnologías
como ha pasado con Python (PyPy, IronPython, Jython) o con Ruby... pero como el
lenguaje es lo que es, y la definición del lenguaje es la propia implementación
en C del mismo, nadie ha tenido las pelotas o el conocimiento para hacerlo.
Perl de todas formas aun tiene sus puntos fuertes, al proveer al usuario de
estructuras de datos y algoritmos (por ejemplo el motor de expresiones
regulares) de alto nivel implementados en C muy optimizado, se evitan "cagadas"
que en otros lenguajes de más bajo nivel programadores mediocres pueden cometer
de forma más o menos frecuente. Por ejemplo, es fácil que una operación simple
como push(@a) acabe teniendo un coste O(N) o incluso O(N^2) en vez de O(1) que
es el óptimo y el que tiene en Perl.
Perl solia salir bien parado en cuestiones de rendimiento cuando se comparaba
con otros lenguajes de scripting o dinamicos, hace tiempo que no investigo ese
tema, pero de todas formas es una disculpa burda, Python esta diseñado para ser
lento... y mirad como van ha día de hoy otros lenguajes en los que ha habido un
esfuerzo por acelerarlos, como por ejemplo JavaScript (con técnicas inventadas
la mayoría hace varias décadas, cuando el state-of-the-art era Smalltalk (como
hemos atrasado!!!))
Pero recordad que lo bueno que tiene Perl es que es rápido a la hora de
desarrollar!!
Fin del rant, os tengo que dejar que me reclama un demonio de 2 años que corre
por mi casa...
_______________________________________________
Madrid-pm mailing list
[email protected]
http://mail.pm.org/mailman/listinfo/madrid-pm
