2010-08-31 6 views
6

recientemente he tenido un amigo me¿El lenguaje Perl tiene como objetivo producir programas rápidos en tiempo de ejecución?

decirle "ven Perl nunca fue diseñado para ser rápido"

  • ¿Es eso cierto?

El dato relevante que puedo encontrar es esto desde Wikipedia:

se pretende que el lenguaje sea práctico (fácil de usar, eficaz, completa) en lugar de hermoso (pequeño, elegante, mínimo).

Pero no habla directamente sobre la velocidad. Creo que con todo el procesamiento de texto que necesita hacer, la velocidad de ejecución realmente importa para un lenguaje como Perl. Y con toda la sintaxis extraña, la elegancia nunca fue un objetivo, estoy de acuerdo.

  • ¿Fue la alta velocidad de ejecución uno de los objetivos del diseño de Perl?
+0

Práctico es muchísimo más fácil que hermoso. Perl es como: Jimmy Soul - Si quieres ser feliz http://www.youtube.com/watch?v=Qh9ZZgDqzAg –

+0

¿Por qué el negvote? Al menos cuidado de explicar. – Lazer

+1

para comprender la verdadera naturaleza de Perl, [lea esto] (http://www.perl.com/pub/1999/03/pm.html). De lo contrario, el rendimiento es ** siempre ** un objetivo de diseño de cualquier desarrollo del lenguaje. El "rendimiento" abstracto no significa nada, ya que existen innumerables métricas para medirlo. – Dummy00001

Respuesta

7

Perl siempre ha tenido como objetivo la practicidad, nada (incluso cerca de) algún tipo de pureza de torre de marfil, donde algunos objetivos tienen prioridad absoluta, y otros se ignoran (completamente o casi).

Como tal, creo que es razonable decir que el mantenimiento de una razonable velocidad de ejecución siempre ha sido visto como importante para Perl, pero hay otros factores (especialmente cosas como la flexibilidad y facilidad de uso) que son generalmente más importante, por lo que si se tiene que elegir entre uno de ellos y la velocidad de ejecución, el otro factor generalmente ganará a menos que el efecto en la velocidad de ejecución sea realmente grave.

1

Se convirtió en un objetivo de diseño a partir de Perl 5.0. Pero tenga en cuenta que todavía se interpreta, por lo que es rápido para un lenguaje interpretado.

+4

No se interpreta más que, por ejemplo, Java o C#. – reinierpost

+1

@reinierpost. C# y Java tienen JIT, Perl no. La naturaleza interpretada de Perl aparece rápidamente si se trata de hacer mucha aritmética. A pesar de que en gran medida es compensado por Perl mapear inteligentemente lo que programador escribe en la gran cantidad de funciones internas y algoritmos eficientes. Java/C# con su presentación intermedia (bytecode/CLI) pierde una gran parte de la imagen más grande en el proceso ... – Dummy00001

+1

@ Dummy00001, JIT no es polvo mágico que hace que Java o .NET sean más rápidos. La última vez que observé cómo la JVM estaba haciendo JIT, ni siquiera se molestó en JITear el código de bytes, solo lo hizo para el código que sabía que obtendría un impulso de velocidad significativo para compensar el costo de usar JIT. Si bien es cierto que Perl no puede hacer esto en tiempo de ejecución, logra mucho del mismo objetivo al proporcionar versiones de Perl y XS de algoritmos clave y herramientas en CPAN. –

3

Hubiera dicho que un lenguaje diseñado para un rendimiento de tiempo de ejecución óptimo no tendría construcciones que permitieran compilar durante la ejecución. Entonces no, tal vez.

9

Hay un aspecto importante a tener en cuenta: los algoritmos. Las armas secretas de Perl son los algoritmos que respaldan ciertas características del lenguaje y la biblioteca CPAN.

Los buenos algoritmos prevalecen sobre la velocidad de ejecución sin formato para problemas no triviales. Por lo general, requiere más esfuerzo seleccionar e implementar algoritmos en lenguajes tipo C que en Perl. Esto significa que durante medio día la codificación de una pequeña herramienta la versión perl a menudo supera a la versión C porque era más fácil hacer buenas estructuras de datos con hash y al usar las características proporcionadas en el lenguaje y las bibliotecas.

8

Una vez que se inicia la ejecución de un script Perl (es decir, después de cargar y compilar todo), puede ser muy rápido. Es esa compilación asquerosa, cada vez que es un poco desagradable.

Sin embargo, creo que las personas realmente no tienen que preocuparse de cuán rápido puede ser Perl.Pierden todo su tiempo implementando estúpidos diseños que hacen mucho más trabajo de lo que necesitan hacer, malinterpretan las tecnologías clave o simplemente se vuelven estúpidos. No es raro para mí ayudar a alguien a hacer que sus cosas vayan mucho más rápido solo con sintonizar en los lugares correctos. Sin embargo, eso no es particular de Perl. La gente tiene ese problema con todos los idiomas.

Cuestiones relacionadas