2009-12-17 14 views
16

Estamos planeando escribir una aplicación altamente concurrente en cualquiera de los lenguajes de programación de nivel muy alto.Python, Ruby, Haskell - ¿Ofrecen verdadero multihilo?

1) Do Python, Ruby, o soporte multihilo Haskell cierto?

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

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

False multiproceso = subprocesos emulan entornos multiproceso sin depender de las capacidades nativas del sistema operativo.

+5

"true" multihilo? Qué significa eso? Por favor, defina multihilo "verdadero". –

+3

true multithreading = múltiples hilos de ejecución independientes utilizan los recursos proporcionados por varios núcleos (no solo por 1 núcleo) – psihodelia

+0

@ S.Lott: hecho, he actualizado la publicación original – psihodelia

Respuesta

32

1) Do Python, Ruby, o Haskell apoyar verdadera multihilo?

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

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

Todos los idiomas que usted menciona, además de todos los idiomas que se han mencionado en las respuestas hasta el momento, tienen múltiples implementaciones, algunos de los cuales soportan cierto multihilo, otros no, y algunos se construyen en la parte superior de otros motores de ejecución que podrían o no soportar multihilo verdadero.

Tome Ruby, por ejemplo. Éstos son sólo algunos de sus implementaciones y sus modelos de roscado:

  • resonancia magnética: hilos verdes, no hay verdaderos multithreading
  • YARV: hebras de SO, sin verdaderos multithreading
  • Rubinius: hebras de SO, la verdadera multithreading
  • MacRuby: hebras de SO, verdaderos multithreading
  • JRuby, XRuby: las discusiones de JVM, depende de la JVM (si la JVM soporta cierto multihilo, entonces JRuby/XRuby hace, también, si la JVM no es así, entonces no hay nada que puede hacer al respecto)
  • IronRuby, Ruby.NET: al igual que JRuby, XRuby, pero en la línea de comandos en lugar de en la JVM

Véase también my answer to another similar question about Ruby. (Tenga en cuenta que esa respuesta tiene más de un año, y parte de la misma ya no es precisa. Rubinius, por ejemplo, usa hilos nativos verdaderamente simultáneos ahora, en lugar de hilos verdes verdaderamente concurrentes. Además, desde entonces, varios nuevos Ruby implementaciones han surgido, como BlueRuby, tinyrb, Rubí Ir a la ligera, Red Sun y SmallRuby)

similares para Python:.

  • CPython: subprocesos nativos, no hay verdaderos multithreading
  • PyPy: subprocesos nativos, depende del motor de ejecución (PyPy puede ejecutarse de forma nativa, o encima de una JVM, o en la parte superior de una CLI, o en la parte superior de otro motor de ejecución de Python. Cada vez que la plataforma subyacente soporta cierto multihilo, PyPy también lo hace)
  • golondrina sin carga:. Nativo de hilos, en la actualidad hay un verdadero multi-hilo, pero fijo está previsto
  • Jython: las discusiones de JVM, ver JRuby
  • IronPython: Hilos de la CLI, ver IronRuby

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

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

2) Si un programa contiene subprocesos, ¿una máquina virtual asignará automáticamente trabajo 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.

+2

La razón por la que CPython y YARV no tienen multiproceso verdadero, incluso cuando se ejecutan en un procesador multinúcleo, y aunque utilizan subprocesos nativos es porque tienen un bloqueo de intérprete global para evitar que un subproceso vea el entorno de ejecución (por ejemplo, el conjunto de definiciones de clase y llamadas a métodos disponibles) en un estado incoherente cuando algún otro subproceso intenta cambiarlo. –

+2

YARV lo llama Giant VM Lock (GVL), pero en principio tiene razón. Sin embargo, al menos en YARV, hay planes para eliminar el GIL. Si miras en 'thread.c' puedes ver una descripción de los tres diferentes modelos de subprocesos que YARV pasó o va a pasar: hilos verdes -> hilos nativos con GIL -> hilos nativos verdaderamente paralelos con un bloqueo de grano fino. Sin embargo, todavía no hay código. En CPython, es similar: Unladen Swallow planea eliminar el GIL y, si no es demasiado intrusivo, contribuir con esta eliminación a CPython. –

7

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

Sin embargo, tanto Jython y JRuby (maduro implementaciones de Java, tanto de Ruby y Python) proporcionan múltiples hilos nativa, no hay hilos verdes y sin GIL.

No sabe acerca de Haskell.

+0

¿Son Jython y JRuby muy diferentes de sus orígenes? – psihodelia

+0

¿Qué significa GIL? Google sugiere "Líneas aisladas de gas" que no es útil ... – tobsen

+2

http://docs.python.org/c-api/init.html#thread-state-and-the-global-interpreter-lock explica qué El bloqueo de intérprete global (GIL) sí lo es. – tobsen

1

Haskell es capaz de hilo, además se obtiene pure lenguaje funcional - no side effects

+0

¿Es compatible con multihilo verdadero? – psihodelia

+0

¿Y qué?Ser puro hace que el enhebrado sea fácil porque sabes que las funciones pueden ejecutarse en otros hilos y no modificarán el entorno. Haskell también tiene Mónadas que son una sección no segura del código, pero además esto no responde a la pregunta de OP en absoluto. Por favor, elimine esta respuesta. –

1

para la concurrencia de bienes, es probable que desee para tratar de Erlang.

+0

Parece que Erlanf tampoco es compatible con multihilo verdadero. De Wikipedia: los procesos son los principales medios para estructurar una aplicación Erlang. Los procesos de Erlang no son ni procesos del sistema operativo ni hilos del sistema operativo, sino procesos ligeros algo similares a los "hilos verdes" originales de Java. – psihodelia

+1

¿Qué tiene que ver esa cita de Wikipedia con verdadero multihilo? –

+3

Erlang es excelente en distribución, y tiene buenas abstracciones de concurrencia, pero la concurrencia no es lo mismo que el paralelismo, y el tiempo de ejecución de múltiples núcleos de Erlang es bastante nuevo, y algo más lento que, por ejemplo, Haskell. Aún así, es mucho mejor que Python o Ruby en comparación, y aprenderá mucho sobre la concurrencia, pero no el paralelismo multinúcleo. * http://ghcmutterings.wordpress.com/2009/10/06/parallelism-concurrency/ * http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=all –

16

El compilador GHC se ejecutará el programa en varios subprocesos OS (y por lo tanto múltiples núcleos) si se compila con la opción -threaded y luego pasa +RTS -N<x> -RTS en tiempo de ejecución, donde <x> = el número de hebras de SO que desea.

+1

O si omite el , intentará determinar el número más óptimo. – Palmik

-2

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

Pero mi opinión - la mejor manera de hacerlo es seleccionar el nivel más alto posible de idiomas con sistema de tipo estático para las cosas grandes y enormes. Hoy estos lenguajes son: ocaml, haskell, erlang.

Si se quiere desarrollar algo pequeño - Python es buena. Pero cuando las cosas se vuelven más grandes, todos los beneficios de Python son consumidos por miríadas de pruebas.

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

+2

Erlang está tipeado dinámicamente. –

+0

mm ... mi mal. mala oracion Mejor diré sobre erlang en otra oración. –

1

En segundo lugar la elección de Erlang. Erlang puede soportar programación distribuida altamente concurrente lista para usar. No importa si llama "multi-threading" o "multi-processing". 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.

22

La implementación de Haskell, GHC, admite múltiples mecanismos para la ejecución en paralelo en multinúcleo de memoria compartida. Estos mecanismos se describen en "Runtime Support for Multicore Haskell".

En concreto, el tiempo de ejecución de Haskell divide el trabajo en subprocesos N OS, distribuidos a través de los núcleos de cómputo disponibles. Estos hilos N OS a su vez ejecutan hilos ligeros Haskell M (a veces millones de ellos). A su vez, cada hilo de Haskell puede tomar el trabajo para una cola de chispas (puede haber miles de millones de chispas). De la misma manera: enter image description here

Los programas de tiempo de ejecución funcionan para ejecutarse en núcleos separados, migrar trabajo y cargar balances. El recolector de basura también es paralelo, usando cada núcleo para recolectar parte del montón.

A diferencia de Python o Ruby, no hay un bloqueo de intérprete global, por eso, y por otras razones, GHC es particularmente bueno en mulitcore en comparación, p. Haskell v Python on the multicore shootout