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

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

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

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

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

Возьмите Ruby, например. Вот лишь некоторые из его реализаций и их модели потоков:

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

См. Также мой ответ на другой аналогичный вопрос о Ruby . (Обратите внимание, что этот ответ больше года, и некоторые из них уже не точны. Rubinius, например, теперь использует настоящие параллельные собственные потоки вместо настоящих параллельных зеленых потоков. Кроме того, с тех пор несколько новых реализаций 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 ЦП)?

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

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

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

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

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

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

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

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

Не знаю о Хаскелле.

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

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

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

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

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

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

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

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