Python, Ruby, Haskell - Они обеспечивают истинную многопоточность?
Мы планируем записать очень параллельное приложение на любом из Очень-высокоуровневых-языков-программирования.
1) Python, Ruby или Haskell поддерживают истинную многопоточность?
2) Если программа будет содержать потоки, то Виртуальная машина автоматически поручит работу нескольким ядрам (или физическим центральным процессорам, если будет больше чем 1 ЦП на системной плате)?
Истинная многопоточность = несколько независимых потоков выполнения использует ресурсы, обеспеченные несколькими ядрами (не только 1 ядром).
Ложная многопоточность = потоки эмулирует многопоточные среды, не полагаясь ни на какие собственные возможности ОС.
8 ответов
1) Поддерживают ли Python, Ruby или Haskell настоящую многопоточность?
Это не имеет ничего общего с языком. Это вопрос аппаратного обеспечения (если на машине только 1 ЦП, просто физически невозможно выполнить две инструкции одновременно), операционной системы (опять же, если ОС не поддерживает настоящую многопоточность, нет ничего вы можете сделать) и механизм реализации / выполнения языка.
Если спецификация языка явно не запрещает или не предписывает истинную многопоточность, это не имеет абсолютно никакого отношения к языку.
Все языки, которые вы упомянули, плюс все языки, которые были упомянуты в ответах, имеют несколько реализаций, некоторые из которых поддерживают настоящую многопоточность, некоторые нет, а некоторые созданы на основе других исполнительных механизмов, которые могут поддерживать или не поддерживать настоящую многопоточность
Возьмем, к примеру, Ruby. Вот только некоторые его реализации и их модели потоковой передачи:
- MRI: зеленые потоки, нет настоящей многопоточности
- YARV: потоки ОС, нет настоящей многопоточности
- Rubinius: потоки ОС, настоящая многопоточность
- MacRuby: потоки ОС, истинная многопоточность
- JRuby, XRuby: потоки JVM, зависят от JVM (если JVM поддерживает истинную многопоточность, то JRuby / XRuby тоже поддерживает, если JVM не поддерживает, тогда ничего нет они могут с этим справиться)
- IronRuby, Ruby.NET: точно так же, как JRuby, XRuby, но в интерфейсе командной строки, а не в JVM
См. Также мой ответ на другой аналогичный вопрос о Ruby . (Обратите внимание, что этому ответу больше года, и некоторые из них уже не точны. Rubinius, например, теперь использует действительно параллельные нативные потоки вместо действительно параллельных зеленых потоков. Кроме того, с тех пор появилось несколько новых реализаций Ruby, таких как BlueRuby, tinyrb, Ruby Go Lightly, Red Sun и SmallRuby.)
Аналогично для Python:
- CPython: собственные потоки, нет истинная многопоточность
- PyPy: собственные потоки, зависит от механизма выполнения (PyPy может работать изначально или поверх JVM, или поверх интерфейса командной строки, или поверх другого механизма выполнения Python. Всякий раз, когда базовая платформа поддерживает настоящую многопоточность, PyPy тоже.)
- Unladen Swallow: собственные потоки, в настоящее время нет настоящей многопоточности, но планируется исправить
- Jython: потоки JVM, см. JRuby
- IronPython: потоки CLI, см. IronRuby
Для Haskell, по крайней мере, компилятор Glorious Glasgow Haskell поддерживает настоящую многопоточность с собственными потоками. Я не знаю о UHC, LHC, JHC, YHC, HUGS или всех остальных.
Для Erlang, и BEAM, и HiPE поддерживают настоящую многопоточность с зелеными потоками.
2) Если a Если программа содержит потоки, будет ли виртуальная машина автоматически назначать работу нескольким ядрам (или физическим процессорам, если на материнской плате более одного процессора)?
Опять же: это зависит от виртуальной машины, операционной системы и оборудования. Кроме того, в некоторых реализациях, упомянутых выше, даже нет виртуальных машин.
как BEAM, так и HiPE поддерживают настоящую многопоточность с зелеными потоками.2) Если программа содержит потоки, виртуальная машина автоматически назначит работу нескольким ядрам (или физическим ЦП, если ЦП более 1 на материнской плате)?
Опять же: это зависит от виртуальной машины, операционной системы и оборудования. Кроме того, в некоторых реализациях, упомянутых выше, даже нет виртуальных машин.
как BEAM, так и HiPE поддерживают настоящую многопоточность с зелеными потоками.2) Если программа содержит потоки, виртуальная машина автоматически назначит работу нескольким ядрам (или физическим ЦП, если ЦП более 1 на материнской плате)?
Опять же: это зависит от виртуальной машины, операционной системы и оборудования. Кроме того, в некоторых реализациях, упомянутых выше, даже нет виртуальных машин.
Я поддерживаю выбор Erlang. Erlang может прямо из коробки поддерживать распределенное параллельное программирование. Неважно, называете ли вы это «многопоточность» или «многопроцессорность». Следует учитывать два важных элемента: уровень параллелизма и тот факт, что процессы Erlang не имеют общего состояния .
Отсутствие общего состояния между процессами - это хорошо.
The GHC compiler will run your program on multiple OS threads (and thus multiple cores) if you compile with the -threaded option and then pass +RTS -N at runtime, where
Haskell подходит для чего угодно.
python имеет модуль обработки , который (я думаю - не уверен) помогает избежать проблем с GIL. (так что он тоже подходит ко всему).
Но мое мнение - лучший способ сделать это - выбрать язык самого высокого уровня со статической системой типов для больших и огромных вещей. Сегодня это языки: ocaml, haskell, erlang.
Если вы хотите разрабатывать что-то мелкое - Python подойдет. Но когда все становится больше - все преимущества Python съедаются множеством тестов.
Я не использовал ruby. Я все еще думаю, что рубин - это игрушечный язык. (Или, по крайней мере, нет причин учить Ruby, если вы знаете Python - лучше прочитать книгу SICP).
The Haskell implementation, GHC, supports multiple mechanisms for parallel execution on shared memory multicore. These mechanisms are described in "Runtime Support for Multicore Haskell".
Concretely, the Haskell runtime divides work be N OS threads, distributed over the available compute cores. These N OS threads in turn run M lightweight Haskell threads (sometimes millions of them). In turn, each Haskell thread can take work for a spark queue (there may be billions of sparks). Like so:
Среда выполнения планирует работу, которая должна выполняться на отдельных ядрах, переносит работу и балансирует нагрузку. Сборщик мусора также является параллельным, использующим каждое ядро для сбора части кучи.
В отличие от Python или Ruby, здесь нет глобальной блокировки интерпретатора, поэтому по этой и другим причинам GHC особенно хорош в сравнении с многоядерным процессором, например, Haskell v Python в серии многоядерных вычислений
Для реального параллелизма вы, вероятно, захотите попробовать Erlang.
Haskell поддерживает потоки, кроме того, вы получаете чистый функциональный язык - без побочных эффектов
Текущая версия Ruby 1.9 (версия на основе YARV-C) имеет собственные потоки, но имеет проблему GIL. Насколько я знаю, у Python также есть проблема GIL.
Однако и Jython, и JRuby (зрелые реализации Java как Ruby, так и Python) обеспечивают встроенную многопоточность, без зеленых потоков и без GIL.
Не знаю о Haskell.