software que programming programacion lenguaje language for eta java scala haskell jvm

java - que - scala language



Haskell vs rendimiento de JVM (6)

¿Alguien tiene algún punto de referencia de rendimiento / experiencia de uso de Haskell vs Scala vs Java para realizar tareas altamente simultáneas?

Su arquitectura de solución específica es importante . Tiene mucha importancia .

Quiero escribir un sistema de back-end para un sitio web (será un servicio de búsqueda personalizado). Necesita ser altamente concurrente y rápido. Dado mi deseo de concurrencia, estaba planeando usar un lenguaje funcional como Haskell o Scala.

Sin embargo, la velocidad también es una prioridad. Los resultados de http://benchmarksgame.alioth.debian.org parecen mostrar que Java es casi tan rápido como C / C ++, Scala en general es bastante bueno, pero Haskell varía de más lento a mucho más lento para la mayoría de las tareas.

¿Alguien tiene algún punto de referencia de rendimiento / experiencia de uso de Haskell vs Scala vs Java para realizar tareas altamente simultáneas?

Algunos sitios que he visto sugieren que Scala tiene pérdidas de memoria que podrían ser terribles para los servicios de larga ejecución como este.

¿En qué debería escribir mi servicio, o qué debería tener en cuenta antes de elegir (el rendimiento y la concurrencia son las principales prioridades)?

Gracias


Debe seleccionar el idioma que mejor conozca y que tenga el mejor soporte de biblioteca para lo que está tratando de lograr (tenga en cuenta que Scala puede usar bibliotecas Java). Es muy probable que Haskell sea adecuado para sus necesidades, si aprende lo suficiente para usarlo eficientemente, y lo mismo para Scala. Si no conoce el idioma razonablemente bien, puede ser difícil escribir un código de alto rendimiento.

Mi observación ha sido que uno puede escribir código paralelo de alto rendimiento moderadamente más rápido y más compacto en Scala que en Haskell. Sin embargo, no puedes usar lo que más te venga a la mente en ninguno de los dos idiomas, y esperar que sea extremadamente rápido.

Scala ya no tiene fugas de memoria relacionadas con los actores, excepto si usa los actores predeterminados en un caso en el que tiene un límite de CPU para que los mensajes se creen más rápido de lo que se consumen, o si olvida procesar todos sus mensajes. Esta es una opción de diseño en lugar de un error, pero puede ser la opción de diseño incorrecta para ciertos tipos de aplicaciones tolerantes a fallas. Akka supera estos problemas utilizando una implementación diferente de los actores.


Diría Scala, pero luego he estado experimentando con Scala, por lo que mi preferencia sería Scala. De todos modos, he visto bastantes aplicaciones multiproceso de alto rendimiento escritas en Java, por lo que no estoy seguro de por qué esta naturaleza de una aplicación obligaría a FP. Le sugiero que escriba un módulo muy pequeño basado en lo que su aplicación necesitaría tanto en scala como en haskell y mida el rendimiento en su configuración. Y, ¿también puedo agregar clojure a la mezcla? :-) Sospecho que querrá quedarse con Java, a menos que esté buscando beneficiarse de cualquier otra característica del idioma que elija.


Echa un vistazo a la comparación cara a cara. Para algunos problemas, ghc y java7-server están muy cerca. Para muchos, hay una diferencia de 2x, y para solo uno hay una diferencia de 5x. Ese problema es el k-nucleótido para el cual la versión GHC usa una tabla hash mutable enrollada a mano, ya que no hay una buena en las stdlibs. Estaría dispuesto a apostar que algunas de las nuevas estructuras de datos funcionan y proporcionan mejores tablas hash que ahora.

En cualquier caso, si su problema es más como el primer conjunto de problemas (computación pura), entonces no hay una gran diferencia de rendimiento y si se parece más al segundo (por lo general haciendo un uso esencial de la mutación), incluso con la mutación, probablemente notará algo de una diferencia de rendimiento.

Pero, de nuevo, realmente depende de lo que estás haciendo. Si busca un conjunto de datos grande, tenderá a estar vinculado a IO. Si estás optimizando el recorrido de una estructura inmutable, haskell estará bien. Si estás mutando una estructura compleja, entonces puedes (dependiendo) pagar un poco más.

Además, los hilos verdes livianos de GHC pueden hacer que ciertos tipos de aplicaciones de servidor sean extremadamente eficientes. Entonces, si el servicio / cambio en sí mismo tiende a ser un cuello de botella, entonces GHC puede tener la ventaja.

La velocidad es buena y buena para preocuparse, pero la diferencia real es entre el uso de cualquier lenguaje compilado y cualquier lenguaje de scripting. Más allá de eso, solo en ciertas situaciones de HPC el tipo de diferencias del que hablamos realmente va a importar.


El punto de referencia del tiroteo supone que se usa el mismo algoritmo en todas las implementaciones. Esto le da la mayor ventaja a C / C ++ (que es la implementación de referencia en la mayoría de los casos) y a idiomas como este. Si utilizara un enfoque diferente que se adaptara a un idioma diferente, esto queda descalificado.

Si comienzas con un problema que se describe de forma más natural en Haskell, funcionará mejor en ese idioma (o muy parecido)

A menudo, cuando las personas hablan sobre el uso de concurrencia, olvidan que la razón por la que lo hacen es para hacer que la aplicación sea más rápida. Hay muchos ejemplos donde el uso de múltiples hilos no es mucho más rápido o mucho más lento. Comenzaría con una implementación eficiente de un solo subproceso, tal como se perfilará / afinará según pueda y luego consideraré lo que podría realizarse al mismo tiempo. Si no es más rápido esta más de una CPU, no la haga concurrente.

En mi humilde opinión: el rendimiento es su principal prioridad (detrás de la corrección), la concurrencia es solo una prioridad en el ejercicio de la tarea.


Esta pregunta es superficialmente sobre el rendimiento del código compilado con GHC vs código que se ejecuta en la JVM. Pero hay muchos otros factores que entran en juego.

Gente

  • ¿Hay un equipo trabajando en esto, o solo tú?
    • ¿Qué tan familiar / cómodo es ese equipo con estos idiomas?
    • ¿Es este un idioma en el que (todos) desean invertir tiempo para aprender?
  • ¿Quién lo mantendrá?

Comportamiento

  • ¿Cuánto tiempo se espera que este proyecto viva?
  • ¿Cuándo, si alguna vez, el tiempo de inactividad es aceptable?
  • ¿Qué tipo de procesamiento va a hacer este programa?
    • ¿Hay bibliotecas bien conocidas que puedan ayudarte en esto?
    • ¿Estás dispuesto a rodar tu propia biblioteca? ¿Qué tan difícil sería esto en ese idioma?

Comunidad

  • ¿Cuánto planea sacar de código abierto?
  • ¿Cuánto planeas contribuir con el código abierto?
  • Qué vivaz y útil es la comunidad
    • en
    • en irc
    • en Reddit
    • trabajando en componentes de código abierto que puede utilizar

Herramientas

  • ¿Necesitas un IDE?
  • ¿Necesita perfiles de código?
  • ¿Qué tipo de prueba quieres hacer?
  • ¿Qué tan útil es la documentación del idioma? ¿Y para las bibliotecas que usarás?
  • ¿Hay herramientas para llenar necesidades que ni siquiera sabías que tenías?

Hay un millón y uno otros factores que debes considerar. Ya sea que elija Scala, Java o Haskell, casi puedo garantizarle que podrá cumplir con sus requisitos de rendimiento (es decir, probablemente requiera aproximadamente la misma cantidad de inteligencia para cumplir con sus requisitos de rendimiento en cualquiera de esos idiomas). La comunidad de Haskell es notoriamente útil, y mi experiencia limitada con la comunidad de Scala ha sido muy similar a la de Haskell. Personalmente, estoy empezando a encontrar que Java es más bien asqueroso en comparación con los idiomas que, al menos, tienen funciones de primera clase. Además, hay muchos más programadores de Java, lo que provoca una proliferación de información en Internet sobre Java, para mejor (más probablemente lo que necesita saber está ahí) o peor (mucho ruido para examinar).

tl; dr Estoy bastante seguro de que el rendimiento es más o menos el mismo. Considera otros criterios.