Lenguaje funcional más rápido

Recientemente he estado profundizando en la programación funcional, especialmente Haskell y F #, la anterior aún más. Después de buscar en Google, no pude encontrar una comparación de referencia de los lenguajes funcionales más destacados (Scala, F #, etc.).

Sé que no es necesariamente justo para algunos de los idiomas (me viene a la mente Scala) dado que son híbridos, pero solo quiero saber qué supera a cada uno en qué operaciones y en general.

— Farouk
fuente

Los idiomas no son rápidos ni lentos, las implementaciones sí.

— Starblue

Las implementaciones de lenguaje no son rápidas o lentas, los programas que se ejecutan usando esas implementaciones de lenguaje sí lo son (en comparación con otros programas). Sea caritativo: cuando alguien habla de que un lenguaje de programación es más rápido que otro, la forma obvia que tiene sentido es entender que están hablando de programas particulares que se ejecutan usando implementaciones de lenguaje particulares.

— igouy

@starblue: Esa es una respuesta muy simplista, y no muy útil. Si bien es ciertamente posible crear dos implementaciones del mismo idioma, una de las cuales es más lenta que la otra, la forma en que se coloca allí implica que no existen detalles de diseño del lenguaje que necesariamente requieren ciertas ineficiencias en la implementación que otros idiomas, por su Diseño, no requiere. Y eso simplemente no es cierto. (Especialmente en este tema en particular; ¡los lenguajes funcionales son conocidos por ellos!)

— Mason Wheeler

@igouy "Las implementaciones de lenguaje no son rápidas o lentas" Esto no es cierto. CPythonvs PyPyrápidamente viene a la mente.

— NlightNFotis

@NlightNFotis: ¿cuántos segundos tarda CPython? ¿Cuántos segundos tarda PyPy? Las implementaciones de lenguaje no son rápidas ni lentas. ¿Cuántos segundos tarda ese programa con CPython?

— igouy

Respuestas:

Según el Great Benchmarks Game , ATS es más rápido que el resto con Haskell, Scala y una de las variantes de Common Lisp en un empate por la velocidad cerca de eso. Después de eso, Ocaml y F # están aproximadamente en la misma categoría de velocidad con Racket y Clojure rezagados ...

Sin embargo, casi nada de esto significa nada realmente. Todo es una cuestión de problema, máquina, compilador, técnicas de codificación y, en algunos casos, pura suerte. En términos generales, los lenguajes codificados directamente por máquina como Haskell superarán a los lenguajes compilados por VM como F # y superarán ampliamente a los lenguajes puramente interpretados. Además, en general, los lenguajes de tipo estático son más rápidos que los de tipo dinámico debido al análisis estático que permite calcular todas las operaciones de tipo en la compilación en lugar del tiempo de ejecución. Nuevamente, estas son reglas generales, siempre habrá excepciones. Los "paradigmas" tienen poco que ver con eso.

— Ingeniero mundial
fuente

Sé que hay muchos factores a tener en cuenta e incluso si todas las cosas fueran perfectas podrían funcionar de manera diferente en diferentes datos, mi pregunta es bastante vaga. Gracias por el enlace, realmente útil - Nunca supe que ATS fue tan rápido

— Farouk

Bonito enlace con información de comparación detallada. Estoy un poco decepcionado de ver que Clojure usa mucha más memoria y tarda mucho más que Java. Recuerdo algunas afirmaciones sobre Clojure con un rendimiento similar, que no parece ser el caso.

— DPM

El sitio web de ATS afirma que ATS admite una variedad de paradigmas de programación, por lo que antes de afirmar que ATS es más rápido que el resto, debe demostrar que esos programas de hecho están escritos en un estilo funcional. Puede ser que el ATS funcional no sea más rápido que el resto.

— igouy

El sitio web de Scala afirma que Scala integra funciones orientadas a objetos y funcionales. ¿Ha verificado que los programas Scala están escritos como programas funcionales en lugar de programas orientados a objetos?

— igouy

También debe señalarse que no puede medir / cuantificar el rendimiento de un lenguaje de programación . Lo mejor que puede hacer es medir el rendimiento de una implementación específica del lenguaje en plataformas específicas, ejecutando programas específicos.

Entonces, cuando pregunta sobre "el lenguaje funcional más rápido", lo que realmente está preguntando acerca de la mejor de las implementaciones actuales de los idiomas.

El comentario de @ igouy plantea que existen otras medidas de rendimiento para la implementación del lenguaje; por ejemplo, tiempo de compilación. Pero eso no cambia el hecho de que el tiempo de ejecución del programa de aplicación es una medida (indirecta) de la implementación de un lenguaje, no una medida del lenguaje en sí.

Considere Java por ejemplo. Supongamos que escribo un punto de referencia de subproceso único utilizando únicamente características de lenguaje de Java clásico (Java 1.0). Si compilo y ejecuto usando JDK 1.0, obtendré un bajo rendimiento (porque JDK 1.0 no tenía un compilador de código nativo). Si paso de JDK 1.1 a ... JDK 1.7, probablemente obtendré mejores resultados progresivamente. Pero esto no se debe a cambios en el lenguaje Java ... porque mi punto de referencia está usando el mismo subconjunto de idiomas. Más bien, la aceleración se debe a mejoras en los compiladores, el sistema de tiempo de ejecución y / o la implementación de bibliotecas de clases. Todos estos son problemas de implementación .

El otro punto es que estas diferencias de implementación pueden ser realmente significativas (por ejemplo, órdenes de magnitud) para el mismo idioma. Por lo tanto, el hecho de que la mejor implementación para el lenguaje X sea más rápida que la mejor (o única) implementación del lenguaje Y no necesariamente le dice mucho sobre el lenguaje en sí.

— Stephen C
fuente

Lo mejor que puede hacer es medir el rendimiento de programas específicos. Cuando medimos el rendimiento de una implementación de lenguaje, queremos saber cuánto tiempo lleva compilar algún programa, no cuánto tiempo tarda ese programa en ejecutarse.

— igouy

El tiempo de ejecución del programa es una propiedad de ese programa en particular cuando se ejecuta usando esa implementación de lenguaje en particular en ese hardware en particular, etc. Dado que el tiempo de ejecución del programa no es una propiedad del idioma, es caritativo permitir que en este contexto el nombre del idioma se utiliza como abreviatura para las implementaciones de lenguaje habituales conocidas.

— igouy

@igouy: eso es cierto. Pero mucha gente no hace la distinción, como lo ilustran muchos sitios web antiguos que proclaman que "Java es lento. Desafortunadamente, esta tontería fue leída literalmente por toda una generación de programadores ... y dañó significativamente la reputación de Java. ESO es por eso que estoy haciendo este punto AQUÍ.

— Stephen C

Como quiere tener la libertad de decir: "una medida (indirecta) de la implementación de un idioma", explique por qué alguien más no debería ser libre de decir: una medida (indirecta) de un idioma .

— igouy

@igouy - 1) Eres libre de decir lo que quieras. Pero eso no te hace correcto. 2) Considere el caso donde la única implementación de un lenguaje es basura. Lo evaluamos. Luego actualizamos la implementación, la comparamos y el rendimiento ha mejorado dramáticamente. ¿Eso significa que el rendimiento del lenguaje ha mejorado? ¿Cómo tiene sentido eso ... dado que el idioma NO ha cambiado!

— Stephen C

Si está buscando idiomas solo en la velocidad de ejecución, se están perdiendo algunos puntos importantes. La velocidad es algo bueno, pero no es lo único.

Haskell usa un sistema de tipos muy robusto para crear programas que serán mucho más propensos a ser libres de errores y robustos.

Erlang utiliza su sistema de monitoreo incorporado para permitirle crear sistemas de fallas que pueden brindarle un gran nivel de confiabilidad frente a varios tipos de fallas. Además, Erlang puede brindarle un nivel de concurrencia difícil de igualar en otros idiomas.

En verdad, consideraría que la velocidad de ejecución en la actualidad está bastante abajo en la lista de lo que consideraría en la mayoría de los casos. (Bien, si estuviera haciendo un cálculo numérico masivo, probablemente querría usar fortran para la velocidad, pero de lo contrario, no es lo suficientemente importante como para importar)

— Zachary K
fuente