Python, Ruby, Haskell - обеспечивают ли они истинную многопоточность?

Question

Мы планируем написать приложение с высокой степенью параллелизма на любом из языков программирования очень высокого уровня.

1) Поддерживают ли Python, Ruby или Haskell истинную многопоточность?

2) Если программа содержит потоки, будет ли виртуальная машина автоматически назначать работу нескольким ядрам (или физическим процессорам, если на материнской плате более 1 процессора)?

Истинная многопоточность = несколько независимых потоков выполнения используют ресурсы, предоставляемые несколькими ядрами (не только одним ядром).

Ложная многопоточность = потоки эмулируют многопоточные среды без использования каких-либо собственных возможностей ОС.

Answer 1

1) Поддерживают ли Python, Ruby или Haskell истинную многопоточность?

Это не имеет ничего общего с языком. Это вопрос аппаратного обеспечения (если на машине только 1 процессор, просто физически невозможно выполнить две инструкции одновременно), операционной системы (опять же, если ОС не поддерживает истинную многопоточность, ничего не происходит вы можете сделать) и язык реализации / двигатель исполнения.

Если спецификация языка явно не запрещает или не обеспечивает истинную многопоточность, это не имеет абсолютно никакого отношения к языку.

Все языки, которые вы упомянули, а также все языки, которые были упомянуты в ответах, имеют несколько реализаций, некоторые из которых поддерживают истинную многопоточность, некоторые нет, а некоторые встроены поверх других механизмов исполнения, которые могут поддерживать или не поддерживать истинную многопоточность.

Взять, к примеру, Руби. Вот только некоторые его реализаций и моделей потоков:

• МРТ: зеленые нити, нет настоящей многопоточности
• YARV: потоки ОС, нет многопоточности
• Rubinius: потоки ОС, истинная многопоточность
• MacRuby: потоки ОС, истинная многопоточность
• JRuby, XRuby: потоки JVM, зависят от JVM (если JVM поддерживает истинную многопоточность, то JRuby / XRuby также делает, если JVM не поддерживает, тогда с этим ничего не поделать они не могут сделать она)
• IronRuby, Ruby.NET: точно так же, как JRuby, XRuby, но в CLI вместо JVM

См. Также мой ответ на другой похожий вопрос о Ruby . (Обратите внимание, что этому ответу больше года, а некоторые уже не точны. Например, Рубиниус теперь использует действительно параллельные собственные потоки, а не действительно одновременные зеленые потоки. Кроме того, с тех пор несколько новых Появились реализации Ruby, такие как BlueRuby, tinyrb, Ruby Go Lightly, Red Sun и SmallRuby.)

Аналогично для Python:

• CPython: собственные потоки, нет многопоточности
• PyPy: нативные потоки, в зависимости от механизма исполнения (PyPy может работать нативно, либо поверх JVM, либо над CLI, либо поверх другого механизма исполнения Python. Всякий раз, когда Базовая платформа поддерживает настоящую многопоточность, PyPy тоже.)
• Unladen Swallow: собственные потоки, в настоящее время нет многопоточности, но исправление планируется
• Jython: потоки JVM, см. JRuby
• IronPython: потоки CLI, см. IronRuby

Для Haskell, по крайней мере, Glorious Glasgow Haskell Compiler поддерживает настоящую многопоточность с собственными потоками. Я не знаю о UHC, LHC, JHC, YHC, HUGS или обо всех остальных.

Для Erlang и BEAM, и HiPE поддерживают истинную многопоточность с зелеными нитями.

2) Если программа содержит потоки, будет ли виртуальная машина автоматически назначать работу нескольким ядрам (или физическим процессорам, если на материнской плате более 1 процессора)?

Опять же: это зависит от виртуальной машины, операционной системы и оборудования. Кроме того, некоторые из реализаций, упомянутых выше, даже не имеют виртуальных машин .

Answer 2

Реализация Haskell, GHC, поддерживает несколько механизмов для параллельного выполнения на многоядерной разделяемой памяти. Эти механизмы описаны в « Поддержка времени выполнения для Multicore Haskell ».

Конкретно, среда выполнения Haskell делит работу на N потоков ОС, распределенных по доступным вычислительным ядрам. Эти потоки N OS, в свою очередь, запускают M облегченных потоков Haskell (иногда миллионы из них). В свою очередь, каждый поток Haskell может принять работу для очереди искр (может быть миллиарды искр). Вот так:

Графики времени выполнения должны выполняться на отдельных ядрах, переносить работу и балансировки нагрузки. Сборщик мусора также является параллельным, используя каждое ядро ​​для сбора части кучи.

В отличие от Python или Ruby, глобальная блокировка интерпретатора отсутствует, поэтому по этим и другим причинам GHC особенно хорош в многоядерной среде, например Haskell v Python о многоядерной перестрелке

Answer 3

Компилятор GHC запустит вашу программу в нескольких потоках ОС (и, следовательно, в нескольких ядрах), если вы скомпилируете с параметром -threaded, а затем передадите +RTS -N<x> -RTS во время выполнения, где <x> = количество потоков ОС, которое вы хотите .

Answer 4

Текущая версия Ruby 1.9 (версия на основе YARV-C) имеет собственные потоки, но имеет проблему с GIL. Как я знаю, в Python также есть проблема с GIL.

Однако и Jython, и JRuby (зрелые реализации Java как для Ruby, так и для Python) обеспечивают собственную многопоточность, без зеленых потоков и GIL.

Не знаю насчет Хаскелла.

Answer 5

Я второй выбор Эрланга. Erlang может поддерживать распределенное высококонкурентное программирование из коробки. Не имеет значения, называете ли вы его «многопоточность» или «многопоточность». Два важных элемента, которые следует учитывать, - это уровень параллелизма и тот факт, что процессы Эрланга не имеют общего состояния .

Нет общего состояния между процессами - это хорошо.

Answer 6

Для реального параллелизма вы, вероятно, захотите попробовать Erlang.

Answer 7

Haskell поддерживает потоки, кроме того, вы получаете pure функциональный язык - без побочных эффектов

Answer 8

Haskell подходит для всего. Python имеет модуль processing, который (я думаю - не уверен) помогает избежать проблем с GIL. (так что подходит для чего угодно).

Но, на мой взгляд, лучший способ сделать это - выбрать язык наивысшего уровня со статической системой типов для больших и больших вещей. Сегодня это следующие языки: ocaml, haskell, erlang.

Если вы хотите разработать маленькую вещь - Python это хорошо. Но когда все становится больше - все преимущества python съедаются мириадами тестов.

Я не использовал рубин. Я все еще думаю, что рубин - это игрушечный язык. (Или, по крайней мере, нет смысла учить ruby, когда вы знаете python - лучше читать книгу SICP).