python ruby concurrency haskell multithreading

Python, Ruby, Haskell: ¿Proporcionan verdadero multiproceso?



concurrency multithreading (8)

1) ¿Python, Ruby o Haskell admiten el multihilo verdadero?

Esto no tiene nada que ver con el lenguaje. Se trata del hardware (si la máquina solo tiene 1 CPU, es físicamente imposible ejecutar dos instrucciones al mismo tiempo), el sistema operativo (de nuevo, si el sistema operativo no admite el multiproceso verdadero, no hay nada Usted puede hacer) y el motor de implementación / ejecución del lenguaje.

A menos que la especificación del lenguaje prohíba o aplique explícitamente el multihilo verdadero, esto no tiene absolutamente nada que ver con el lenguaje.

Todos los idiomas que menciona, además de todos los idiomas que se han mencionado en las respuestas hasta el momento, tienen implementaciones múltiples, algunas de las cuales son compatibles con multiprocesamiento múltiple, otras no, y otras están construidas sobre otros motores de ejecución que pueden o no podría no ser compatible con el multihilo verdadero.

Tomemos a Ruby, por ejemplo. Estas son solo algunas de sus implementaciones y sus modelos de subprocesos:

  • MRI: hilos verdes, sin multiproceso verdadero
  • YARV: subprocesos del sistema operativo, no hay verdadero multiproceso
  • Rubinius: hilos del sistema operativo, multiproceso verdadero.
  • MacRuby: hilos del sistema operativo, multiproceso verdadero
  • JRuby, XRuby: JVM threads, depende de la JVM (si la JVM admite multiprocesamiento verdadero, entonces JRuby / XRuby también lo hace, si la JVM no lo hace, entonces no hay nada que puedan hacer al respecto)
  • IronRuby, Ruby.NET: igual que JRuby, XRuby, pero en el CLI en lugar de en la JVM

Ver también mi respuesta a otra pregunta similar sobre Ruby . (Tenga en cuenta que esa respuesta tiene más de un año, y parte de ella ya no es precisa. Rubinius, por ejemplo, ahora usa subprocesos nativos realmente concurrentes, en lugar de subprocesos verdes realmente concurrentes. Además, desde entonces, varias implementaciones nuevas de Ruby han surgido, como BlueRuby, tinyrb, Ruby Go Lightly, Red Sun y SmallRuby.)

Similar para Python:

  • CPython: hilos nativos, sin multiproceso verdadero
  • PyPy: subprocesos nativos, depende del motor de ejecución (PyPy puede ejecutarse de forma nativa, o encima de una JVM, o encima de una CLI, o encima de otro motor de ejecución de Python. Siempre que la plataforma subyacente admita multihilo verdadero, PyPy sí también.)
  • Unladen Swallow: subprocesos nativos, actualmente no hay multihilo verdadero, pero se planea una solución
  • Jython: hilos de JVM, ver JRuby
  • IronPython: hilos CLI, ver IronRuby

Para Haskell, al menos el Compilador Haskell de Glorious Glasgow admite el multihilo verdadero con hilos nativos. No sé sobre UHC, LHC, JHC, YHC, HUGS o todos los demás.

Para Erlang, BEAM y HiPE admiten el multihilo verdadero con hilos verdes.

2) Si un programa contiene subprocesos, ¿una máquina virtual asignará trabajo automáticamente a múltiples núcleos (o a las CPU físicas si hay más de 1 CPU en la placa base)?

De nuevo: esto depende de la Máquina Virtual, el Sistema Operativo y el hardware. Además, algunas de las implementaciones mencionadas anteriormente, ni siquiera tienen máquinas virtuales.

Estamos planeando escribir una aplicación altamente concurrente en cualquiera de los lenguajes de programación de muy alto nivel.

1) ¿Python, Ruby o Haskell admiten el multihilo verdadero?

2) Si un programa contiene subprocesos, ¿una máquina virtual asignará trabajo automáticamente a múltiples núcleos (o a las CPU físicas si hay más de 1 CPU en la placa base)?

Verdadero multihilo = múltiples hilos de ejecución independientes utilizan los recursos proporcionados por múltiples núcleos (no solo por 1 núcleo).

Falsos subprocesos múltiples = los subprocesos emulan entornos de subprocesos múltiples sin depender de ninguna capacidad nativa del sistema operativo.

El compilador GHC ejecutará su programa en varios subprocesos del sistema operativo (y, por lo tanto, múltiples núcleos) si compila con la opción de -threaded y luego pasa +RTS -N<x> -RTS en tiempo de ejecución, donde <x> = el número de subprocesos del sistema operativo usted quiere.

Haskell es adecuado para cualquier cosa. Python tiene processing módulo de processing , que (creo que no estoy seguro) ayuda a evitar los problemas de GIL. (por lo que es adecuado para cualquier cosa también).

Pero mi opinión, la mejor manera de hacerlo es seleccionar el lenguaje de mayor nivel posible con un sistema de tipo estático para cosas grandes y enormes. Hoy en día estos idiomas son: ocaml, haskell, erlang.

Si quieres desarrollar algo pequeño, python es bueno. Pero cuando las cosas se vuelven más grandes, todos los beneficios de Python se consumen mediante miriads de pruebas.

No utilicé el rubí. Sigo pensando que el rubí es un lenguaje de juguete. (O al menos no hay razón para enseñar Ruby cuando sabes python, es mejor leer el libro SICP).

La implementación de Haskell, GHC, es compatible con múltiples mecanismos para la ejecución paralela en núcleos de memoria compartida. Estos mecanismos se describen en " Soporte en tiempo de ejecución para Haskell multinúcleo ".

Concretamente, el tiempo de ejecución de Haskell divide el trabajo en subprocesos N OS, distribuidos en los núcleos de cómputo disponibles. Estos hilos N OS a su vez ejecutan M hilos livianos de Haskell (a veces millones de ellos). A su vez, cada hilo de Haskell puede llevar trabajo a una cola de chispas (puede haber miles de millones de chispas). Al igual que:

Las programaciones de tiempo de ejecución se ejecutan en núcleos separados, migran el trabajo y los saldos de carga. El recolector de basura también es paralelo, y utiliza cada núcleo para recopilar parte del montón.

A diferencia de Python o Ruby, no hay un bloqueo global de intérpretes, así que por eso y por otras razones, GHC es particularmente bueno en mulitcore en comparación, por ejemplo, Haskell v Python en el tiroteo multinúcleo

La versión actual de Ruby 1.9 (versión basada en YARV-C) tiene subprocesos nativos pero tiene el problema de GIL. Como sé, Python también tiene el problema de GIL.

Sin embargo, tanto Jython como JRuby (implementaciones Java maduras de Ruby y Python) proporcionan multihilo nativo, sin hilos verdes y sin GIL.

No sé sobre Haskell.

Para una concurrencia real, probablemente quieras probar Erlang.

Yo segundo la elección de Erlang. Erlang puede admitir la programación distribuida altamente concurrente fuera de la caja. No importa si lo llamas "multiproceso" o "multiprocesamiento". Dos elementos importantes a considerar son el nivel de concurrencia y el hecho de que los procesos de Erlang no comparten el estado.

Ningún estado compartido entre procesos es algo bueno.